Subscribe: Google Podcasts | Stitcher | TuneIn | RSS

How to solve common dysfunctions in product management

Today’s guest is Ben Foster, the Co-Founder and Executive Chairman at Prodify. He is convinced that product is the single most important success driver for tech companies, which is why he founded Prodify to share what he learned from being an advisor to over 50 tech companies to realize their full potential. Ben has led successful technology products for the last 25 years. He is also the co-author of Build What Matters: Delivering Key Outcomes with Vision-Led Product Management.

He’s with us to share the advice he most frequently gives to the company leaders he advises regarding creating products.

Summary of some concepts discussed for product managers

[5:22] Can you take us through the primary challenges you encounter advising companies and what they need to overcome the challenges?

I founded Prodify so my team and I can help companies by sharing knowledge from our previous experiences. We have identified several different areas where companies typically struggle when it comes to product. The three areas in which we tend to help companies the most are:

• Direction—core metrics, product vision and strategy
• People—structure of the product team, coverage, empowerment, accountability
• Process and practice—ongoing development and learning, communicating with the rest of the company

Every company I’ve ever spoken with, no matter what stage they’re in, has some flaws across each of these areas. It’s not because they’re bad at what they do. It’s because it’s just really hard to get right.

[9:24] What issues do you see with strategy?

A lot of companies have a mission statement that they think is a strategy or vision. The reality is those two things are very different from one another. A mission statement is why you’re doing what you’re doing. The vision is where you intend to be in several years. The strategy is the plan of attack for how you’re going to get there.

A lot of work that goes into a vision. When I was the Chief Product Officer at Whoop, I left the company with a 70-page vision about the future state of the product and how were going to manage it. It provided a lot of clarity. There’s no way any mission statement could ever fulfill that need.

Often a CEO tells me something like, “Our vision is to get to $3 billion revenue in five years.” That’s the byproduct of you being successful and executing your vision. What’s the actual vision itself? What’s the customer value that you’re going to deliver? Too often the vision is not tied to customer outcomes and not focused on customer value that needs to be delivered. Product management is concentrated on the creation of customer value from which you’re then in a position to derive business value.

Even those companies that build a strong vision and strategy may have a complete disconnect between the work the PMs on the ground are doing and the vision and strategy documents that sit on a digital shelf collecting digital dust while no one is paying attention to them.

[12:41] How can leaders better communicate strategy?

Often the senior leadership team thinks they talk about strategy a lot, but the employees under them don’t understand the strategy. When I see that type of thing happening, I tell the senior leadership team to ask their CEO, “What’s your strategy?” and then ask the people doing the work, “What’s the strategy?” Either they don’t have an answer or they have a completely different answer from the CEO’s. That’s an indication that the CEO or senior leadership team may feel like they’ve communicated the strategy well or they may feel like it’s well understood within their organization, but their perception is not reality. The leaders are usually shocked by the results that they get when they ask their team members to explain the strategy to them.

Communicating strategy requires a lot of repetition. The leaders will think that they’ve communicated it, and maybe they have communicated, but new employees have joined since then and people have been having conversations around the water cooler about the strategy that have gone off on different tangents. You just need to be repeating those same messages. Don’t just talk about the things that are included in your strategy. So much of strategy is about all the things that you have to say no to and the way that you focus. If everybody can repeat what you’re saying back to you, then it’s usually a really good indication that you’ve done a good job as a product leader.

[16:05] What problems come from working on product work not aligned with the company strategy?

There’s only so much that you can do in product yourself. A lot of it has to do with pulling together a bunch of other groups. There needs to be coordination and alignment that spans across the different groups. There’s so much emphasis and focus in product management about prioritizing the perfect thing When you have a list of a hundred different things, you could probably choose any of the top 50 and it would be fine as long as there was alignment across the organization on delivering it. The mistake is where marketing prioritizes item number one, product prioritizes item number two, somebody else prioritizes item number three, and now suddenly everyone’s completely disconnected, and the person who’s really suffering from that is the customer.

[17:58] Tell us more about why the vision is important.

The vision facilitates decision making. It helps with top-level decisions like acquiring another company, and it is critical from a cultural perspective as a company continues to grow because it’s the only way an executive can feel confident pushing decisions down in the organization. Otherwise, the executive feels like they have to make all the calls because they’re the only one who actually understands where the company is going. Companies can be so much faster and better at their decision-making when they have a really well understood and aligned vision and strategy.

[19:09] Tell us more about challenges related to people.

Founders of early-stage startups ask questions like, “When should I hire my first product manager? Should I hire a VP of product first and then have that person hire product managers later or should I hire more junior product managers first?” There’s a lot of confusion for early-stage companies about the right timing. Often they make the mistake of hiring people who are too senior too fast. It’s nice to have somebody who can work at that level, but often the work that needs to be done is at the bottom of the product stack. That’s not what VPs of product are super excited about, and the product leader and founder will start stepping on each other’s toes. I usually recommend that startups hire a relatively junior product manager initially. Only when they have a small product is it the right time to hire somebody to lead this group.

As companies mature, they start to run into the question, How do we make sure that there is that connection between the strategy and the work that’s getting done? They need to focus on communication within the team and dividing responsibilities among product managers.

In really large organizations, a lot of the people issues turn into how to maintain culture across the team, what the ratios should be between product and engineering and how they ensure that they’re not duplicating efforts across different team members.

There are also questions like, “How do you maintain or create diversity within your team?” There’s certainly demographic diversity, but there’s also just diversity of thought and diversity of experience. Do you have a combination of B2B people, B2C people, and marketplace people? Team members should be able to share some of their learnings from the prior places that they’ve been.

Hopefully every time you’re hiring that next product manager, you’re solving what I call the n + 1 problem. You’re not just hiring somebody into a role. You’re taking a team of n people, and you’re turning it into a team of n + 1 people. Who’s the right hire who’s going to make your team of n +1 as strong as it could possibly be?

[23:17] What team structures do you recommend?

Many companies use a pod concept. A pod is a dedicated team that is working on a particular set of problems, has a certain set of goals, and has some level of autonomy to figure out the best way of reaching the goals on their own. They are responsible for their own roadmaps. When I was the head of product, it was my job to ensure there was alignment across the pods and that the puzzle pieces fit together. But it wasn’t my job to be dictatorial and tell everybody what they were supposed to do. A pod would consist of a product manager, a designer, an engineering lead, a pool of about five to seven engineers, and maybe other functions as well. We gave the pod some metrics that they were accountable for moving. They have decision-making authority of what they work on for the most part.

The pod concept has become the de facto way of doing software development these days. There are a lot of different ways of breaking pods up to have different areas of ownership. You could break it down by different areas of the product, personas you’re trying to focus on, metrics you’re trying to move, geographic location, market segments, different products, etc. There is no one best answer.

However, there is this issue that you need to resolve: Whatever seams you have in your organizational structure are likely to be propagated as seams in the product that gets delivered by that group. That’s known as Conway’s Law, which basically says your organizational structure is reflected in what gets delivered by that organizational structure. So the question is, where do you want those seams to live? Where is the best or the worst place for those to be? I recommend you think about your organizational structure in such a way that you minimize the negative impact of those seams in the experience for the end customer. Think about the customer journey and how it is impacted by siloes in your organization.

[28:00] Tell us more about dysfunctions in process and practice.

We talked about autonomy, and it’s really important to set up your process so product teams are empowered to make their own decisions. That means sometimes the product leader has to step back a little bit. As a product leader, in order to give your team the ability to be autonomous while simultaneously recognizing that you’re still responsible for the collective work they do, it’s important to define the vision and the strategy, define the personas, define the product metrics and the dashboards, set up the right kind of metrics reviews to ensure that focus is in the right areas at the right times, and define the product and design principles.

In general, I’m a believer in agile more so than in Agile. Anytime you try to get dogmatic with process, you neglect to recognize the differences that exist across companies.

For example, I read an article from somebody at Facebook who suggested you don’t really need to have a direction or strategy. You just throw things out there and see what sticks. When you’re at Facebook, you can run an experiment in an hour and probably get enough data points to tell whether the idea is going to be effective. When I read that article, I was working at a company delivering a B2C product. We were delivering home energy reports to consumers, but utilities were actually our customer, and they were using our product to try to help drive down energy usage within people’s homes. We generated the home energy report as a PDF. We found out that the most effective way of delivering the PDF to consumers was not in the form of email because they just deleted it. The most effect way was to send a letter in an unmarked envelope from the utility company, which everyone would open and read. However, it took one year of collecting data to tell that there was an interaction between the customers receiving this piece of paper and them changing their behaviors in their home to use less power. We ran hundreds of experiments with that kind of stuff, but the turnaround time to see the impact of what we were doing was a year. Testing different ideas didn’t come from just throwing them out into the wild and seeing what happened. We had this whole process built up of doing huge amounts of usability studies because we could get feedback more immediately to refine our designs. Some companies need that; some companies don’t. It depends on the nature of your business.

Action Guide: Put the information Ben shared into action now. Click here to download the Action Guide.

Useful links:

• Connect with Ben on LinkedIn
• Learn more about Prodify
• Check out Build What Matters

Innovation Quote

“Plans are worthless. Planning is everything.” – Dwight Eisenhower

Thanks!

Thank you for taking the journey to product mastery and learning with me from the successes and failures of product innovators, managers, and developers. If you enjoyed the discussion, help out a fellow product manager by sharing it using the social media buttons you see below.