Product roadmaps often present as a time-based list of feature deliveries. We’ll build A by X, then B by Y, then C by Z, …, on and on we go.
More advanced companies call them solutions. You might even have a Solutions Roadmap. These companies at least orient around the problem, recognizing the difference between a feature and a solution.
Features are outputs, solutions have outcomes.
After understanding this difference, the next step is to embrace the goal of building as little as possible to solve the problem at hand. Intuitively, this makes sense. You’d obviously rather invest $1M solving a problem than $5M.
But we’re product managers, designers, and engineers. We produce. So intuition be damned, we’re going to ideate, design, and build some amazing stuff.
Once we realize the goal of building as little as possible, we can orient our planning process around building less. To my mind, this aligns well with the Build-Measure-Learn model presented in The Lean Startup.
Engineering managers and product managers pride ourselves on delivery. Did the thing get built on time, on budget, on spec? That’s how we judge our own performance and also how our managers typically judge us.
Instead, we should be measuring ourselves against user and customer behavior changes. Email open rates, user interactions, account creations, and the like.
Orienting a team of producers around outcomes is difficult. Equally difficult is retraining yourself to be outcomes focused.
When feature requests come in from users, there isn’t much we can do about it. Users will be users.
But from internal staff (notably Support), I recommend shifting conversations about features to conversations about problems. I helped facilitate this change a few years ago within my organization and have seen these benefits:
Company-wide, we are orienting around solutions, not features. We can ask what the desired outcomes are, not just the desired outputs.
How strongly do I recommend Outcomes Over Output?
8 / 10
You can read Outcomes Over Output in an hour or two. I read it waiting on my car’s oil change.
I particularly recommend this book for anyone (and their manager!) who feels stuck in a feature-building rat race.