Don’t build features, solve problems
All too often when you look at a roadmap, it’s a pretty chart with a list of features and dates oriented around answering “what features/things are we building next?”
Similarly, too many user feedback forms are focused on asking “what features are we missing?” or “what feature would you like to see?”
It’s as if one additional feature is going to be the difference between someone using your product or not.
I believe the better question we all should be asking is: “What problem should we solve next?”
Your roadmap shouldn’t be a list of all the features you’re going to build next. It should be problem-driven and oriented around which problems you’re going to solve next.
Sidenote: AtDispatch, we maintain three roadmaps:
1. One is a list of features for external communication to our users and customers.
2. The second roadmap is an internal Trello board used to guide product prioritization with a list of problems and ordered by what problem we’re going to solving next.
3. The anti-roadmap of what we are NOT going to build.
The benefits of framing & communicating everything as problems
1/ Above all else, it gets the entire team rallying around finding the best solution(s) to your users’ problems instead of just building features and shipping code. The hope is that many minds are better than one when it comes to solving the problem, and ideas from people in your organization that may typically be dismissed when framed as feature requests are suddenly embraced as potential solutions to the problem.
Your customer development focus is then switched from trying to figure out “are we building a feature our customers will use?” to “is this a problem that all of our users have?” or “how much pain does this problem give our users?”
2/ One of the most common question(s) from engineers, executives, etc. in your organization is “why are doing this?” or “why are we building feature X instead of features Y?”. This is now replaced with discussion and debate around “Is this the most important problem to be solving right now?” and “Are there other ways our users can solve this problem without writing code or building this into our core product?” (e.g. could solve needing to get paid for completed work by whipping out a Square card reader to be able to handle credit card payments outside of your product?)
3/ You are forced to think beyond just building product and writing code to solve problems. If the problem I am trying to solve is: _my users have customer information in multiple places and can’t find a customer’s history when he/she calls in_, the product solution may be building global search with Algolia.
However, to fully solve the problem for users you only have data from day one he/she started to use your product. If the user has been running their business for 10+ years, solving the problem also involves figuring out where that historical data is stored today, building a way to import all of that historical information in your system and then teaching the user to use what you built.
Shifting to problem driven product development
Here are some things that have worked for me when adopting a problem-driven approach.
1/ The first question anyone asks now when receiving feedback or a feature request is always “what problem is this solving?” Most feature requests are proposed solutions without articulating what the actual problem to be solved is.
2/ One of the side effects of feature-based roadmaps is the urge to add more surface area to the product versus focusing on how well you are solving the one or two core problems that your product solves and improving it. Shiny new feature X is much sexier on a roadmap than improvement to existing feature Y that will better solve a problem for users.
3/ One of the most common reactions to “competitor X just announced sexy feature Y in a TechCrunch press release” is: OMG, we need to completely reprioritize our roadmap to build this feature now too — it’s table stakes and expected from our users. However, it’s easy to lose sight of the fact you’re not really competing against “competitor” X.
What you’re actually competing against is how your (potential) customers are currently solving their problem(s) and those customers continuing to solve that problem in the same way they currently are. They don’t care if their problem is solved through software or not. They just want their problem solved.
At the end of the day, it’s important to remember that a PM’s job (building product) is about solving problems — not building features or having dictatorial control over the direction of the product.