Product Management in Practice

Chapter 4. The Worst Thing About “Best Practices”

When I train product managers at large and small organizations alike, the first thing they usually ask for is “best practices.” “How does Facebook do product management?” “How does Google define the difference between a product manager and a program manager?” “What are the things we can do to make sure we’re running product like a best-in-class organization?”

These are great questions to ask, and the answers to these questions are great to know. But implicit in these questions is often an unspoken and counterproductive addendum: “How does Facebook do product management…because we want to do exactly the same thing.”

The appeal of this thinking is not difficult to understand. Given the ambiguity around the work of product management, it makes perfect sense to look for guidance from the companies that in many ways defined product management in its current form.

But the dangers of this thinking are a bit more insidious. There are three particular ways in which I’ve found that a focus on best practices can actually make it more difficult for working product managers to succeed:

Focusing on best practices leads to an incurious mindset

Reducing product management to a set of repeatable best practices means wishing away all of the messy, elusive, and absolutely critical human complexity that must be navigated in the role. Product managers who rely too much on best practices become deeply incurious about the people they work with—and sometimes even the product they’re working on. Anyone and anything that does not conform to the best practice becomes a threat to the one-size-fits-all approach that they are hoping will lead them to success.

Best practices often focus on operational stories, not stories of user value

Most stories about product management best practices end with happy and efficient product managers, designers, and developers, but not (necessarily) with happy users. This focus on the operational success of product management best practices can inadvertently shift goalposts within organizations from “Are we successfully delivering value to our users?” to “Are we successfully doing product management the same way that another company does?”

Magical thinking around best practices inevitably leads to sadness and disappointment

Initial conversations about best practices are often full of optimism and hope. But as these best practices inevitably run up against an organization’s existing habits and rhythms, this quickly gives way to fatalism and frustration. Why aren’t these best practices working for us? Whose fault is this? Who doesn’t “get it”? These questions usually end with a grim and decidedly unhelpful conclusion such as “Our organization is just too hierarchical to be good at product management,” or “The rest of the organization just didn’t give us the support we needed to make these changes.” The very things that make an organization unique wind up being an unstoppable impediment to change, rather than guiding the ways in which change is implemented.

None of this is to say that conversations about best practices should be avoided altogether—after all, this book is full of them! Let’s look at a few important things to keep in mind when learning and communicating about best practices to make sure that they become valuable resources and not broken promises.

Don’t Believe the Hype

Sometimes, when I’m fielding a volley of questions about how Company X manages to be so good at product management, I’ll ask people to do a simple two-step exercise:

1. Write down all the things you’ve heard about how Company X is great at product management.

2. Spend five minutes using Company X’s product, and write down all the product issues and problems that seem obvious to you—the ones you would want to fix on day one if you wound up working there.

The goal here is not to leave people feeling disillusioned and defeated, or even to suggest that “best in class” companies are missing obvious flaws in their products. Instead, the goal is simply to point out that the world looks very different from inside these companies than it does from the outside. Every company has political struggles, resource constraints, deeply held assumptions, and organizational inertia. No matter how many stories you’ve heard about how product managers at Google are locked in a constant free-snack-driven high-five with their developer counterparts, or how product managers at Facebook are given free rein to literally push any code change to a billion users whenever they feel like it because startups, maaaaaaan, the day-to-day challenges that product managers at these organizations face probably look a lot like the day-to-day challenges that product managers in your organization face.

To be blunt, most published case studies and articles about best practices are largely recruiting propaganda. Companies that are competing for product and engineering talent have very little reason to paint an accurate picture of their workplace situations, let alone an even remotely negative-leaning one. Rather than looking for a formal case study from a best-in-class company, talk to the working product managers in your network. Their stories and insights will likely align much more closely with the challenges you will face in your organization, and they will be much more realistic about the limitations and potential drawbacks of the approaches they’ve chosen.

“But This Worked at the Last Place!”

As product managers move between different organizations, they tend to amass their own set of “best practices” from past companies. These best practices are often the stories that product managers tell in job interviews: “We implemented this new Agile process, and were able to hit all of our release targets for the next year,” or “We started setting rigorously quarterly goals, and were able to increase revenue faster than projections.” And when a product manager starts at a new organization, there is often an expectation that whatever worked at the last place will yield similar results at the new place.

What often gets lost in these conversations is that the “best practices” that product managers pick up at a particular organization usually succeed for reasons that are specific to that particular organization. Odds are, a lot of trial and error went into getting those best practices to a place where they could even be described or imagined as “best practices” at all. And, like it or not, that same process of trial and error, testing and learning, failing and adjusting needs to take place at every organization.

One of the biggest mistakes I’ve seen product managers make is showing up and immediately trying to make their new organization work exactly like their last organization. They implement so many changes at the same time that it becomes effectively impossible to observe and measure the effect of each individual change. And when the changes that worked for another organization inevitably fail to solve the specific problems of this new organization, a product manager can very quickly lose the trust of their team.

The best product managers always take time to learn about what makes an organization unique before they start implementing—or even suggesting—specific best practices. And when they do start implementing those best practices, they start small and build incrementally. By contrast, the worst product managers usually wind up blaming their colleagues when a fast and furious deluge of “best practices” fails to deliver the promised results. Here’s a fun fact: the product managers who wind up getting frustrated because “The idiots at this new company just couldn’t understand these better ways of working” are often the same product managers who talked about the idiots at their last company when they were being interviewed. Product managers who put abstract best practices above the people with whom they work tend to repeat this pattern over and over again.

A Slow and Steady Approach to Building Team Process

Ashley S.

Director of product management, ad tech company

When I started my job at a growing ad tech company, I was eager to apply the best practices I had used at my previous job. I showed up full of enthusiasm, ready to hit the ground running and to transform a disorganized group of high-performing individual contributors into a true software product team. And yet the team didn’t seem to share my excitement. They acknowledged that they had a lot of room to improve, but they seemed deeply skeptical of the changes I was suggesting—changes that I had just seen work at another company. What was going on?

I was very lucky to have somebody on my team sit me down and say, “Think about it this way: maybe we want to start small, see what works, and then go from there.” It stopped me in my tracks and I realized, “Wow, I know better than this.” I was so full of genuine enthusiasm and wanting to make things better that I was ready to roll out everything I had seen work at my last company. But everything was different now; the team was different, the needs were different, company communication was different.

So instead of trying to rebuild the approach I used at my last job, I stepped back and tried to learn where the communication problems were at my new company. I worked with my team to figure out what needed fixing, and what steps we could take to make things better. We introduced changes slowly and steadily, constantly refining our approach based on what worked and what didn’t work. One sprint, we would introduce daily standups. The next sprint, we would tweak the way we do our release notes. Slowly but surely, we built up a process that helped the product team collaborate and deliver better products.

So much of being a product manager is about going through the pieces that you think will work, and then feeling the pain of them when they don’t work as intended. Once you know where the pain points are, you can start making adjustments. It’s not about changing everything all at once, and it’s not about forcing a team to work in a certain framework or adopt a certain set of rituals. It’s about really just iterating on your process constantly. When it doesn’t work, you figure out why it doesn’t work, and you try something else. It’s always a process to get to your process.

Goals First, Then Practices

One way to make sure you are implementing best practices in a manner that respects and aligns with the needs of your organization is to start with the specific needs and goals of your organization, and then think about practices that might help you achieve these goals. In the absence of this approach, you run the significant risk of implementing a change that is poorly understood, met with skepticism and resistance, and ultimately destined to fail.

Suppose, for example, that you just joined a team that is struggling to create space for communication between two geographically far-flung offices (a challenge you will read more about in Chapter 5). At your last company, you had a yearly offsite “product summit” that helped colleagues get to know one another in a more informal setting and align around a plan for the coming year. In your first meeting with the CEO at your new gig, you share this experience and say, “I know how hard it can be to get a distributed team aligned around product vision. I think that this ‘product summit’ could have truly transformative results.” Your CEO is pretty far removed from the day-to-day challenges around collaboration—and who doesn’t want transformative results?—so she agrees.

Two weeks later, you send out an email announcing COMPANYCO’S PRODUCT SUMMIT OFFSITE, to be held for a week at a swanky hotel in a location halfway between the two offices. You are expecting a hero’s welcome from your colleagues, who you’ve heard grumbling about communication challenges since your first round of interviews. To your great surprise, the responses you receive range from muted to passive-aggressive. “My team has a deadline the following week; we’ll sit this one out, thanks.” “Is this the best use of our budget? I was asked to let one of my best developers go last year.” Some people seem vaguely excited, some people seem frustrated, and most people seem confused and wary. You begin to hear some rumblings that this entire thing is just a pretext to announce company-wide layoffs. An executive from another part of the organization writes a furious email to the CEO asking why “product” is trying to further consolidate its power and influence at the expense of marketing and sales, both of which are already frozen out of critical roadmap decisions. The situation is, simply put, a big mess.

So, what went wrong? You recognized a problem, and you suggested a solution that you have seen work at another organization. But between two organizations, the same symptom can be caused by a very different disease—and the cure for one disease might make the other much worse. Maybe the reason that remote teams are struggling to work together at this organization has nothing to do with the lack of face-to-face time, but rather stems from a fundamental misalignment of goals and incentives. Maybe there are a few people in each of the offices who just don’t like one another—and the idea of meeting up for an offsite is just about the very worst thing that any of them could imagine. Maybe the word product is interpreted by some people in this particular organization as, pointedly, “not marketing or sales.”

If you don’t take the time to truly understand the problem you are trying to solve, and how the organization’s current beliefs and practices are contributing to that problem, then any best practice you implement is effectively a shot in the dark. Here is a basic template you can use to begin understanding a specific challenge your organization is facing, before thinking about potential solutions:

My organization is facing the following challenge: This challenge is affecting our ability to deliver value to our users in these ways: I believe that this challenge is caused by the following current beliefs and practices:

This kind of structured thinking will help keep you focused on what challenge you’re actually trying to solve, and can reframe operational problems as a question of lost user value. In some cases, taking this approach might help you realize you gravitated toward a particular problem not because it was directly affecting your users, but rather because you recognized it as a problem you’ve seen and solved before.

The Best Thing About Best Practices

With all that said, there is one particularly great thing about best practices that can serve as a crucial first step toward making positive change in an organization: because best practices often come with the halo of authority from a well-respected organization, it is much easier to get people to give them a try. Saying, “Let’s try this weird thing where we write out three to five goals for the quarter and then also measure some things and call the things we measure ‘results’ even though they’re actually more like ‘indicators,’” will probably not get you far. But saying, “Let us adopt the Objectives and Key Results framework, just as they have done with great success at Google” sounds like a pretty reasonable thing to suggest.

Summary: A Place to Start, Not a Guarantee

Just remember: best practices are a place to start, not a guarantee of success. Keep a close eye on what is working for your organization and what can be improved and refined. And, above all else, keep the goals of any best practice you use in mind, so that you have a clear sense of what “working” means in the first place.

Your Checklist:

• Approach best practices as a place to start, not a prescriptive one-size-fits-all solution.

• Ask yourself how a particular best practice might help your team deliver user value, instead of just how it will change the way you work.

• If you’re curious about how a particular company approaches product management, try to find some people who have actually worked there and ask them.

• When you are bringing a best practice from one organization into another organization, acknowledge and appreciate that every organization is different.

• Take the time to truly understand the goals and needs of your organization before rushing to implement any specific practices.

• Use a “slow and steady” approach to implementing best practices, so that you can test and measure the impact of every incremental change.

• Avoid the temptation to solve the problems that seem the most familiar to you, as opposed to the problems that are having the most impact on your users.

• Utilize the “organizational halo” effect of best practices to get buy-in toward trying new things, but be prepared to continuously adjust course based on what is working and what is not working.