Product management is the art and craft of shipping software. That’s why the two most dangerous words for a Product Manager to hear are “Why Not?”
Good product work depends on controlling scope, consistently, for every feature. It means saying no to a bunch of ideas that are pretty good—and yes only to the great ones, the ones that truly solve the problem.
Often stakeholders assume that if their ideas aren’t bad, they should be on the roadmap. “This isn’t hard; let’s get it in front of the engineers.” But the burden of proof is the other way around—ideas should get turned down unless they clear a high hurdle.
Let me give you an example: the temptation to add settings. Someone really wants a dark theme, or the ability to change their default sort order. On its face it seems like you’re empowering the user to make the app their own! But in reality, the majority of your users won’t change the defaults, and adding settings adds more code complexity and possible configuration permutations (therefore testing scenarios, and surface areas for bugs), that will only benefit a small part of the user base.
Another typical pitfall is the right idea, wrong time scenario. I see this all the time when a team is talking about introducing something new that could maybe be even bigger in the future. “Why don’t we just add this now too?” is another surefire way to push out your ship date. “Let’s focus on the core idea and we’ll gradually iterate on it” is better.
Here’s another example: building a custom UI for a complicated piece of administration work, like assigning user permissions. This is a good idea and something that should be on the roadmap to make admin users more efficient. But the first release can be something ugly so that the feature ships, and the team can double back to build the custom UI once real usage is happening. As a bonus, you can use actual user feedback to inform the design of the UI instead of guessing.
Why Not? leads to menus that are only used by a handful of users, buttons that are never clicked, designs that are slapped together instead of thoughtfully applied.
The reason Why Not? is dangerous is that there is always another Why Not?. Which means your software is never done. Which means you’ll spend all your time telling everyone why you can’t ship instead of getting things done and out.
It’s one of the reasons clients work with a product studio, even when they have their own product teams. We are purely incentivized to ship a product. If we don’t ship we don’t get paid. Our greatest enemy as a business is Why Not?.
Flip the script. Trust your Product Manager to be constantly questioning why features can’t be removed instead of adding them in. The more that our teams can resist Why Not? thinking, the faster things go.
Chris LoSacco is a Managing Partner at Postlight and the head of product. If you’re someone who could use our help resisting Why Not? thinking in your organization, shoot me a note: email@example.com.