Truly Great Products Are Built by People Who Say Yes
Photo via Flickr user Visionello

Truly Great Products Are Built by People Who Say Yes

When I got my first job in product management, a developer friend told me what he admired most about the product manager he worked with. "He's really good at saying no," my friend said.

I asked what he meant.

My friend explained that his PM was really good at finding ways to acknowledge new feature ideas while keeping the team focused on the most impactful work. "Great idea; let's do it in v2," "let's cost it out and evaluate the tradeoffs," and "let's revisit this after the MVP"--these are all ways to say no to feature creep without minimizing the contributions of others.

Over the years, I took this mantra to heart, and passed the advice on to new PMs. "Get good at figuring out how to say no to things," I'd tell them. (Coincidentally, this was also a skill that I learned from my days as a bicycle trip leader, but that's a story for a different post.) After all, one of the key responsibilities of a product manager is to keep the team focused on building the right things. Prioritization becomes a key tool for making tough decisions about where to focus. And it's something PMs spend a lot of time on, whether managing a backlog and planning sprints, or, in the case of larger public companies, doing quarterly and annual planning as well.

But lately I've come to question the centrality of prioritization in product management--both in my own approach, and in that of others. Because it is among the hardest and most time-consuming tasks PMs do, we make the often mistake of thinking it's the most important. And I've come to believe this is dangerous.

Because prioritization is among product managers' hardest and most time-consuming tasks, we make the mistake of thinking it's the most important.

Ultimately, a product manager is responsible for making sure the right thing gets built--something that creates value for customers and for the company. Prioritization is but one of the tools available to her to do so. Equally important are brainstorming, communicating vision, user research, empathy, cross-team collaboration, and measuring results, to name a few. Prioritization might prevent you from expending energy building the wrong thing, but it is not a guarantee that you actually build the right thing.

The problem with putting prioritization on a pedestal is that it draws focus to costs rather than value. We start out with a set amount of resources (engineers, designers, etc.), and thus a decision to invest in feature A is a decision not to invest in feature B. But framing choices primarily in terms of their cost has a profound effect on our decisions. Done right, prioritization considers costs against outcomes, but too often, it ends up being an exercise primarily concerned with costs. After all, it's easy to know exactly the size of the resource pool we can draw from (even if we are notoriously bad at estimating engineering effort), but much harder to predict the likely outcome of an initiative, especially if it's something that hasn't been done before (that is: new or innovative). So at best, prioritization causes us to think very carefully about tradeoffs. At worst, it pushes us towards the flawed assumption that making tough choices is a zero-sum game.

At best, prioritization causes us to think carefully about tradeoffs. At worst, it pushes us to the flawed assumption that making tough choices is a zero-sum game.

And that--the devolution of prioritization into a mindset of scarcity--is why I increasingly believe that ruthlessness about prioritization is dangerous. When resources are scarce, we over-index on saying no: we focus on low-risk bets; we protect what little we have and view outside requests as particularly threatening to our hard-won prioritization. (I have found myself succumbing to this tendency more frequently than I'd like, which is part of why I decided to write this post.) On an organizational level, this is particularly insidious. When teams try to protect their roadmaps and resources, they are less likely to work together. They assume that allocating resources towards helping another team towards its goals means sacrificing attention towards their own objectives. They foreclose on the possibility of discovering mutually beneficial partnerships that can drive outsize value for both customers and the company as a whole.

There's economic logic to cross-team collaboration, too: if two teams with unaligned objectives take the time to agree upon an initiative that both are happy with, that outcome will reflect an increase in pareto-efficiency relative to the existing prioritization. Of course, this can't happen if our knee-jerk first reaction is to say no to new ideas that threaten our existing priorities.

One of the most important classes I took in business school wasn't a business school class at all: it was an improv comedy class in Stanford's theater department. On the very first day of class, we were introduced to improv's key maxim: "Say Yes." In our daily lives, our instinct is to say no to ideas that contradict our plans and expectations. In improv, you learn to trust your partners and accept what they might throw at you. By relinquishing some control, you open yourself up to possibilities that would otherwise never have been available. And it is from those explorations that truly serendipitous scenarios--the outrageous, unexpected lines that have the audience rolling in the aisles and recounting to their friends days later--become possible.

The same is true in product management. Truly great products, and truly great product organizations, are built by product managers who say yes--yes to collaboration with each other; yes to new and unexpected ideas; yes to flexibility about their existing prioritization in the service of the greater good--and who remember that prioritization is but one arrow in their quiver.

Mohit Anand

Principal PM Manager at Microsoft | Ex Grofers (BlinkIt), Adobe

3y

This is Gold !

Like
Reply
A.Gayle Treece

Coach: Change Acceleration

6y

YES, I found this AND i loved it! Thank you.

Like
Reply

Too good

Like
Reply
Benjamin Poyet

Senior Engineering Manager at LinkedIn

7y

Great post.

Like
Reply
Aditya Gupta

Founder @ Sachiv.ai | Ex - Google, Amazon, LinkedIn | Product and Engineering

7y

I really agree with this. #BHAGProjects taught me all the development I know today.

Like
Reply

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics