Build What Matters by Rajesh Nerlikar and Ben Foster – Free Chapter!

September 30, 2020

24 min read

Share on

Ben Foster

Chief Product Officer at WHOOP

Featured as a speaker at top industry events and on numerous podcasts, Ben Foster has more than 20 years of product management experience. He is chief product officer at WHOOP and was formerly a senior product manager at eBay, vice president of product at Opower, and chief product officer at GoCanvas.

Rajesh Nerlikar

CEO / Principal Product Advisor at Prodify

Rajesh Nerlikar has more than 15 years of product management experience. Prior to becoming chief product advisor at Rajesh Nerlikar , he was a technology consultant at Accenture, an entrepreneur, a product manager at Opower, a senior product manager at HelloWallet, and a director of product at Morningstar. He is also currently serving as vice president of product at Savonix, a Prodify client.

Chapter 1 Why Product Isn’t Working

Happy families are all alike; every unhappy family is unhappy in its own way. —Leo Tolstoy, Anna Karenina

We see hard-working product teams struggling all the time, even under the best of conditions. While there are many things that can go wrong, we’ve identified the most common dysfunctions in product management. If some of these seem familiar, then this is the book for you.

Top 10 Dysfunctions in Product Management

Here are the top ten dysfunctions in product management from our perspective:

We’ll delve into each of these dysfunctions so you can see if they are representative of the challenges you’re dealing with in your company. You may find you’ve experienced most or even all of them at one time or another. Rest assured that doesn’t signal incompetence or imply your product team is deficient or unskilled. On the contrary, these issues are so prevalent that almost everyone who has worked in product management will have struggled with them at one point or another. As you read each of them, mark which ones ring true at your company.

Pattern #1: The Hamster Wheel

On a hamster wheel, all that matters is continuing to run, even though you’re not getting anywhere. Similarly, we find that sometimes product teams are almost entirely focused on hitting deadlines with little regard for the outcome. When desired outcomes are unclear or difficult to measure, leadership tends to concentrate on output instead, but what’s the use of spending months developing a product that no customer wants or is willing to pay for, whether you hit the deadline or not?

If you’re delivering the wrong thing, it doesn’t matter how efficiently or quickly you deliver it, and your output isn’t necessarily meaningful or beneficial unless you’re creating value for the customer or the business.

Compare these two questions, and you’ll see the difference in perspective.

Did you ship that feature on time? (output-oriented)
Did that feature deliver value to customers and grow revenue? (outcome-oriented)

Ben’s Story

MEASURING LINES OF PRD

During my time at eBay, from 2001 to 2005, product management was run by a few different leaders. When I first joined as an entry-level product manager, Marty Cagan was leading product management and design, and there was a true appreciation for the innovative role that product management played. After he left, the engineering leader stepped in to fill his shoes. Her perspective was that product management’s job was to feed the engineering beast, producing volumes of product requirements documents (PRDs) that would keep thousands of developers busy. The joint product and engineering team became extremely efficient at delivering lots of code, less so at delivering consistent results.

With no clear way of holding product managers accountable for outcomes, she defaulted to pure productivity metrics. Product managers were actually issued a quota for lines of PRD written per quarter, and that quota was increased each quarter to demonstrate productivity gains to the COO.

The consequences were predictable. Product managers worked excessively long hours to produce monster PRDs for overdesigned features. I personally wrote a 240-page PRD that required an entire week of meetings to hand off to the engineering team. Looking back, I’m confident the same results could have been delivered with a simplified product design and less documentation, which would have saved engineering capacity and allowed us to address the next business opportunity. Believe it or not, at the time, I was actually proud of myself. In what should have been a “teaching moment,” I was applauded for the time I put in and the amount of work I created for others.

Pattern #2: The Counting House

In the counting house, the focus is entirely on internal metrics with no regard for customer success. Many product teams become obsessed with internal metrics like revenue growth, monthly active users (MAUs), and customer retention. Sometimes, they even fabricate new metrics because they’re convinced that if some internal number looks good, it must mean the product is a success.

The truth is, most internal metrics are trailing indicators of a product’s success, and therefore shouldn’t be the primary focus of product management. It’s far better to answer the question, “How can we effectively deliver greater value to our customers?” If you can answer that question and create a good business model around the answer, your internal metrics will almost always follow suit.

Pattern #3: The Ivory Tower

In the ivory tower, product teams become so removed, so far above the customers that they start thinking they know their customers better than the customers know themselves. Consequently, they never really talk to their customers, which means they risk building a product no one wants or needs. Just because a product team falls in love with its own solution doesn’t mean customers will.

Furthermore, a lack of customer-driven insights can lead to a spiral of mistrust between product management and other stakeholder groups in the company. Product management feels like they are building the right product (though they may not be), so when the product doesn’t perform well in the market, they assume the fault lies elsewhere. Go-to-market teams believe product management is to blame for not being responsive enough to their feedback. Engineering loses confidence that their efforts are worthwhile, and they question every new priority that’s presented. From the CEO’s perspective, it’s unclear why the budget allocated to research and development (R&D) isn’t delivering results, and every attempt to figure it out yields more finger-pointing and excuses.

Rajesh’s Story

ASSUMING WHAT USERS WANT

Spring 2014 was an exciting time for me. Not only was our first son due, but I also saw two exits from the startups I worked for. Opower went public in April, and HelloWallet was acquired by a strategic investor, Morningstar, in May. Nervous about working for a “big” enterprise like Morningstar, I immediately decided to launch a dating app my buddy and I had been talking about for years. The idea was simple: matching people based on the actual places they go because people are more likely to be interested in someone who goes to the same bars, restaurants, parks, museums, and ballparks. Location-based check-ins on Facebook and Foursquare (Swarm) were rising, so we pulled data from those platforms. I called the app Wentroductions, and to this day, I cringe at the awkward name choice.

While deciding on the scope of the minimum viable product (MVP), I used dating app feedback from my friends and my own experiences, but I didn’t conduct enough customer discovery to validate our experiences or to understand why someone would use our product over more popular apps like Tinder. Instead, I spent my nights and weekends writing user stories and putting together wireframes so my cousin’s software development firm in India could build the MVP. My buddy and I formed a company and put in our own money (I decided to “let it ride” with my two recent exit earnings). About five months later, the app was nearly ready, and I started running Twitter ads to get users.

And then I realized my mistake. We had ten to twelve users in the first two weeks, but dating apps don’t succeed if they can’t match you with someone soon after you sign up. So I asked friends and family to join because I didn’t want to use the common “seed and weed” strategy of creating fake profiles and then removing them when enough users sign up.

I probably don’t have to tell you how this ended. Wentroductions never took off with users, and while the app looked and worked great, the product failed as I sat in my ivory tower. It had been years since I’d last used a dating app, yet I still thought I knew what users wanted. To this day, my best piece of advice to anyone who thinks a new product should exist in the world is to build a simple landing page and create an email waitlist based on a few simple feature descriptions to learn what resonates with real customers.

Pattern #4: The Science Lab

In the science lab, product teams tend to focus all of their efforts on highly measurable yet superficial improvements to their product. Collectively, these small-scale A/B tests don’t do much to innovate or add customer value.

Here’s a version of this problem we often see. A company has a sign-up process on their website, and they want to encourage more people to use it. To do that, they start making a variety of minor optimizations to the sign-up process—changing button colors, tweaking the text, changing the graphics—hoping that something will drive up the level of engagement. In general, these kinds of changes provide no actual value to customers and have very little to do with engagement.

In the last few years, we’ve seen optimization become the be-all and end-all for more and more companies rather than a facet of a balanced product development roadmap. The assumption is that making improvements to existing solutions is the one thing that will drive results, but even effective optimizations can’t take the place of real innovation. Companies that are constantly trying to eke out more value from their existing solutions run the risk of stagnating. It’s almost impossible to A/B test your way to real innovation.

Pattern #5: The Feature Factory

What does a feature factory build? Features. When is a feature factory done building features? Never. The problem with being a feature factory is that there’s always the next one to build. Product teams fall into this trap because they are led to believe by customers or internal stakeholders that if they just had this one next feature, they will close incremental deals or keep customers who might otherwise leave.

Sometimes, it works out that a specific missing feature is holding the business back, but more often than not, the team discovers that yet another feature is also needed. Even when the newest addition does, in fact, fully resolve a customer’s issue such that it saves an account or lands a new deal, it’s only one. All the while, entire market opportunities are missed because the product doesn’t deliver sufficient value to prospective customers who lack a voice (or won’t bother speaking). In fact, the addition of too many features can weigh down the user experience (UX) so much that new customers can no longer comprehend the product, which results in a net negative outcome for the company.

Ben’s Story

THE COLOR-CODED ROADMAP

I vividly remember joining Opower as the VP of product in early 2010. In my second week, the board requested to see a product roadmap. Scrambling to deliver, the obvious starting point was learning from the team what had already been planned. In doing so, I discovered two surprising facts: 1) there was no roadmap, and 2) the company had already contractually committed nearly all of the engineering capacity for the next six months to building a hodgepodge of one-off features for newly-closed accounts.

These weren’t the priorities I wanted, and in fact, no one else in the company wanted them prioritized either, but in an effort to close business, they had acquiesced. I needed to communicate to the board and our employees not only what our priorities were but why, so I created a roadmap document that showed all of the features we were required to build over the next six months colour-coded in yellow and all the more meaningful improvements we were excited to deliver afterward colour-coded in blue. That way everyone saw the reality but also had a glimmer of hope: after heads- down work for six months, we would be in a position to really innovate.

Sadly, that’s not what happened. Six months later, we had indeed delivered against the client commitments, but the colour-coded roadmap still looked exactly the same. In that time, we had continued to make new client commitments, defer- ring our intended priorities another six months. This would have continued into perpetuity if we hadn’t solved the underlying problem. We were a feature factory! With some great cross-functional teamwork, we were finally able to break away from this pattern. Later in the book, we’ll discuss the resolution and finish this story.

Pattern #6: The Business School

Business school is where you go to analyze business but not to actually do business. Similarly, product teams can get so wrapped up in overanalyzing everything that they avoid making tough but essential judgment calls. When it comes to prioritization, some product managers are tempted to get so technical and mathematical that they lose perspective.

There’s a process that seems to make sense to product teams. They sit down and draw up a list of all the features and improvements they want to make to their product. Then they work with the finance team to generate estimates about the specific business impact of these features. Finally, they meet with the engineering team to figure out how much effort it’s going to take to develop them.

Having done that, they typically conduct net present value (NPV) or return on investment (ROI) analyses for every feature or improvement, do scenario-planning, and create spreadsheets that reveal the estimated monetary impact of each potential feature divided by the amount of effort it will take to develop. Whatever winds up with the biggest number gets top priority, and they declare, “The mathematics have spoken! Our product decisions have revealed themselves!”

It sounds great in theory, but in reality, no product decisions are being made at all. The initiatives that show the highest estimated impact are the ones that were modeled using the most outrageous assumptions, and usually only the lowest-effort improvements end up above the cutline. All the while, customers and the larger business strategy are completely ignored. Arming oneself with specious ROI estimates at a committee meeting is a poor substitute for making the right strategic decisions to maximize the impact of product development.

Pattern #7: The Roller Coaster

A roller coaster is all about fast thrills and wild, whiplashing movements. They can be a lot of fun, but they aren’t a good model for effective product management. Investors and executives like to see immediate results, and when those results don’t materialize right away, they can be tempted to pivot suddenly, resulting in whiplash for the product team.

This problem comes from setting a time horizon that is too short. For startups, a lack of patience is often the result of having a very short runway. They have to get something up and running fast so they can raise the next round of funding, or they need to start producing revenue right away. Of course, everyone wants to make fast and efficient progress, but providing insufficient opportunity for success will result in false negatives that can lead product managers astray. When an otherwise healthy “fail-fast” mentality is taken to the extreme, it can stifle innovation.

“We think this new feature is a good idea,” a product manager might say. “To avoid overinvesting, we’ll first launch a lackluster version of it. If it doesn’t get overwhelmingly positive results immediately, then we’ll know it’s not the right direction for our product.” Daisy-chained together, these false negatives result in a headache-inducing roller coaster ride for product development that ends up in exactly the same place it started.

Pattern #8: The Bridge to Nowhere

Engineers love solving future problems with technology. That can be a good thing when taken to the right level, but it can also be taken too far. They get excited about developing the infrastructure to get the product just right, but sometimes, they can end up overengineering a product, trying to account for future needs that aren’t relevant—and may never be. As a result, product development can get so bogged down that a great product that would have delivered meaningful customer value never sees the light of day.

Sometimes, it’s better for engineers to tolerate some reworking of the product down the road, as long as the foundational elements are in place, rather than solving numerous theoretical and potential problems. Imagine if a team of engineers designed and constructed a bridge over a river to connect a city to a wilderness area where another city might someday exist. They invest a tremendous amount of time, money, and resources to construct a bridge sturdy enough to support a multilane highway under the assumption that eventually there will be a lot of traffic, but what would be the point if the second city never got built? Why not wait until at least a small town has developed on the other side of the river, and then build a small, one-lane bridge to connect it, with the understanding that if the town grows into a large city, the bridge can be expanded and reinforced?

Every tech company has to invest in the underlying technology of its product, but there must be sufficient confidence that it will offer tangible value to the business or the customer within a reasonable time frame to warrant investment now. Scaling for a future that never materializes is a futile exercise no tech company can afford.

Pattern #9: The Negotiating Table

Sometimes, product meetings can turn into a negotiating table, as the product manager tries to give everyone what they want. Product managers often believe that success means keeping all of their stakeholders happy—or, at least, minimizing their unhappiness—but when teams and individuals throughout the organization collectively want more than engineering can potentially deliver, this becomes practically impossible. A list of inbound demands might look like this:

The CEO has a pet product idea.
Sales wants five other features.
Engineering feels it’s critical to tackle some technical debt.
Customer support needs a bug fix.

How can the product manager satisfy all of these requests in a timely manner, so they get that all-important pat on the back from everyone?

It’s a bit like playing a game of high-stakes Tetris, as product managers try to fit all of the incongruent requests together. In a sense, they wind up prioritizing to avoid discomfort with the people they see every day in the office. Of course, nobody wants their colleagues mad at them.

However, it’s not a leader’s job to give everyone what they want, and, in fact, true leadership requires making some unpop- ular decisions. Product teams find themselves in the negotiating table situation when the organization misunderstands product management’s chief purpose. It’s not the primary role of prod- uct management to help sales hit their quota this quarter. It’s the role of product management to make it possible for sales to sign up for higher quotas than anyone thought possible farther in the future. When product management prioritizes the right things for the customer, they help every team, whether those teams realize it or not.

Pattern #10: The Throne Room

Sometimes, the founder or CEO just can’t let go. They feel compelled to make decisions about anything and everything important in the company, and they give their team very little ability to call their own shots. Because their instincts got them to where they are, they think it will continue to carry them for- ward, but at a certain point, instinct doesn’t scale. Their job title becomes a trump card any time they want to override a creative decision, and they might not even bother to clarify the rationale when they throw their weight around.

They fail to drive alignment around the product direction, so no one really understands what they’re doing or why. In these kinds of situations, the CEO typically changes their mind frequently, sometimes with little notice, and usually with no real explanation or justification. Every request is treated as priority number one, and the product manager is expected to give them 100 percent of their attention.

It’s an impossible situation for a product team that prevents the scaling of the company beyond a single decision-maker. There must be a clear framework around prioritization that everyone in the company understands, so every initiative can be properly evaluated to determine if it contributes to the end- state customer vision and ultimate success of the company.

Ben’s Story

CONSTANTLY CHANGING PRIORITIES

When I joined Adchemy, a twenty-five-person startup, in 2006 the company had already built ingenious machine learning technology capable of generating and optimizing billions of ads and landing pages every day. The promise of that technology led to multiple funding rounds and a $400 million valuation in 2009.

The difficulty was in converting that technology into a viable product in the competitive ad tech space. Do you sell it to publishers? To advertisers? To agencies? Should it be applied to paid search or display ads or landing pages? Do you package the technology or use it yourself to outperform other affiliate partners delivering online leads? As I moved up the ranks to eventually lead product management and design at Adchemy, I needed clarity, or at least agreement, from the co-founder/ CEO on which of these paths we should choose.

The CEO was exceptionally good at setting a single priority and aligning everyone to it. The only problem was that the singular priority changed like clockwork every quarter. Rather than committing to a path, he vented frustrations down the chain about the (unsurprising) lack of progress on the paths not taken. My team was forced to shift gears frequently, and with very little rationale offered for the hard pivots he demanded, rallying the troops proved an impossible task. Seeing the writing on the wall, I eventually left and the company was ultimately sold to Walmart Labs with no return for investors.

SCORECARD

As you’ve read through these ten dysfunctions of product management, at least a few have probably hit close to home. It can be a useful exercise to assess your organization against each one, so we’ve created this table to help you do just that. Give yourself a point for each problem that you are struggling with in your company, then add up the total and see where things stand.

Ten Dysfunctions of Product Management: Self-Assessment

The Hamster Wheel: output over outcomes
The Counting House: obsession with internal metrics o The Ivory Tower: lack of customer research
The Science Lab: optimization to the exclusion of everything else
The Feature Factory: an assembly line of features
The Business School: overdependence on data and spreadsheets
The Roller Coaster: fast-paced twists and turns
The Bridge to Nowhere: overengineering for future unknowns
The Negotiating Table: trying to keep everyone happy
The Throne Room: whipsaw decision-making from the person in charge

SCORING

0 points: Wow! Maybe you should write a book on product management.

1 point: Amazing! You’d be valedictorian of your product class.

2 points: Not bad. You’re keeping up with other product teams.

3 points: Hmm. You’ve got some work to do.

4+ points: Oof! You’ve got your work cut out for you. Take detailed notes as you read this book and make specific plans for how you’ll fix these dysfunctions at your company.

Think about the impact it would make if you resolved all of those dysfunctions in your organization. Consider all of the engineering potential and creative energy it would free up. Now, consider the unmeasured cost of not dealing with them. Your engineers are probably some of your highest paid, highest value employees, so if their effort isn’t aligned to the right activities, it’s probably costing you more than you realize.

THE COMMONALITIES

While these dysfunctions may seem like ten completely different problems, they fall under just three basic themes:

Internal focus is drawing too much attention away from delivering meaningful customer value.
The product team is so busy playing defense or has so little authority, there is no time left for ideation and innovation.
The desire for short-term directly measurable business outcomes results in only superficial changes being prioritized.

In essence, these themes are all ways that a company naturally fills gaps that could be filled with a clear direction and path for the product. When we spoke with Gibson Biddle, former VP of product management at Netflix and highly regarded product management thought leader, he explained this succinctly: “Product leadership is defined as inspired communication of a vision. The majority of problems faced by most product teams are solved through strong leadership.”

Creating an end-state customer vision for your product is how to resolve each of these ten patterns of dysfunction, both by uprooting them and by preventing them from taking hold in the first place. It also prevents product manager burnout. These problems exact a heavy toll, and when they mount up, even a hardened product manager can become so worn out and discouraged that they quit. We’ve seen this happen firsthand, so we always love it when we can help a product manager overcome these challenges and ease the burden.

ACTION CHECKLIST AND RESOURCES

We want this book to be actionable and helpful to everyone who reads it, so at the end of each chapter, we’ve included a link to an action checklist and resources that will make it easy to take those actions. That way, you can apply the concepts from each chapter to your own product(s).

Visit buildwhatmattersbook.com for an action checklist and additional resources, such as a team-level scorecard for the ten dysfunctions in your organization.

To continue reading, you can buy Build What Matters on Amazon. And, if you’re a Mind the Product member, you can read chapter 2 here.

Explore all topic content