The Power of Building Less
Product Management is most times a thankless job. Being a cross functional role, you are uniformly exposed to all the functions in the organizations — sales, support, customer success, marketing etc. And no matter how hard you try, you cant prevent disappointing everyone. And the reason why PMs disappoint everyone is because we have to say no to most feature requests from all of them. And hence, you receive a lot of gripe. Amongst all the functions that hate Product Management, Sales tops the list especially in Enterprise products. Most sales people have a few accounts that are waiting to be converted if the product includes a certain feature requested by these accounts.
One of the profound lessons for me has been realising the virtue of building less. I gathered this while reading Jeff Patton's User Story Mapping. When I understood the idea for the first time, it hit me like a ton of bricks. The magic is in the pursuit of the minimum and the vital. Here is the summary of what I gathered from the book.
There is an uncomfortable truth about the software world. It is this:
There is always more to build than we have time and resources to build - always!
One of the misconceptions in software development is that we’re trying to get more output faster. Because it would make sense that if there was too much to do, doing it faster would help, right? But if you get the game right, you will realize that your job is not to build more—it’s to build less
Your job is not to build more - it is to build less.
At the end of the day, your job is to minimize output, and maximize outcome and impact.
Minimize output, and maximize outcome and impact
The trick is that you've got to pay close attention to the people whose problems you are trying to solve.
No business has the resources to make everyone happy - it's just not possible.
How do you build less?
Focusing on specific target outcomes is the secret to prioritizing development work.
Building outcomes that have the maximum impact is the solution.
Dont prioritize features, prioritize outcomes.
For any feature, there are going to be multiple outcomes. We list out the outcomes in priority and then slice a release out.
Dont prioritize features, prioritize outcomes.
Once we have identified the prioritized outcomes, it is a product release that can be called as Minimum Viable Solution.
The minimum viable solution is the smallest solution release that successfully achieves its desired outcomes.
I had explained the difference between outcome and output and how to prioritize outcomes in a separate post:
https://productlessonsravi.substack.com/p/prioritise-outcomes-not-features