In one of my 0-1 initiatives my leadership wanted to add a specific workflow that would shave a few steps for the user but significantly increase the complexity of the whole feature. Even the very widely adopted competitor didn’t have it, and for an MVP it felt like overkill. I made every effort to strip it down or simplify it, but I couldn’t cut it entirely. The cost was months of iterations spent untangling a convoluted user experience.
Every product team I’ve worked with has this same quiet pull. A developer wants to slot in the shiny new framework. A designer wants to chase the UI trend the industry is moving toward. A PM wants to ship the clever feature they thought of in the shower. To be human is to want to create — and product builders are especially human.
But saying yes to everything as a product manager comes at heavy cost. Martin Fowler explains the costs really well when talking about the YAGNI principle:
- Cost of build - the cost of building something that users may not appreciate or use as much as we assumed
- Cost of delay - the cost of delay of not being able to release a feature that the user badly needed, but got blocked by this feature
- Cost of carry - every unnecessarily added complexity pulls extra effort at every stage to get out the door, right from solution ideation, design, development, testing and even marketing
- Cost of repair - unnecessary set of features that go stale result in Technical Debt which needs to be repaired
In a recent feature, something similar happened. But this time, I learned from my hard-earned mistakes and stood my ground. There was pushback, as expected, but I was persistent. I explained the pros and cons. I reiterated our goals and vision, and how the requested workflow would add only complexity at this stage of the product.
So how do you get good at saying no? Not by practicing the no itself. You get there by being good at what a PM already does:
- Use every resource at your disposal to completely understand the problem your users face
- Know what the best possible solution looks like
- Know what makes that solution profitable
Do those three well and you’ll know a bad idea the moment it lands on your desk — it simply won’t fit the circles you’ve drawn. Recognising the no was never the hard part.
The hard part is everything after. It takes conviction to hold the line when it’s your leadership, your favourite engineer, or your own shower-thought on the other side. And it takes the skill of a storyteller to say no in a way that leaves people nodding instead of resentful. And that part doesn’t come from a framework. It comes from getting it wrong and figuring out what works in your setup.