A Useful Framework for Thinking About Product Management
An introduction to the Problem Space & Solution Space model for visualizing product management.
You Need a Product Framework
It seems pretty intuitive to think of product management as managing the product. But the best product managers think on a higher-level. They focus on a framework for making product decisions. If you have the right framework you’ll be able to avoid all of your biases and make product decisions that help you get the most out of your engineering time and money.
Below I walk through a framework I came across recently that I think really helps you prioritizing what you have to do to first to make progress. In the end good product management is more about saying “no” to suboptimal product ideas, rather than just coming up with an endless stream of ways you could improve.
Problem Space & Solution Space
A great way to tell how well your product is progressing towards product market fit is by visualizing things in terms of a problem space and solution space. The problem space shows what problem you are trying to solve. The solution space shows how well your product is solving that problem.
I am going to use our mobile app Playbook as an example. Our app lets you follow startup bloggers like Tim Ferriss, Andrew Chen, Marc Andreesen from your mobile phone. The two problems our app is trying to solve is making it easier to find really high quality startup blogs, and making a better way than an email newsletter to follow their posts. I labeled these below as “finding” and “following”.
The goal with your product is to move your solution space towards your problem space. The lines extending from the dot at the center of your solution space measure your progress towards solving your problems. The shorter the distance of those lines (when stretched out) the less time it takes to create a product that is actually solving those problems for its users. This is what you should be optimizing for. The shortest route to creating a viable product that people like. The final solution space will look a bit like this.
This will all become more clear as we move through the example.
An interesting note is that the more problems you are trying to solve the harder it is to get your solution to the point where you are actually solving them.
Keep in mind that just like with all models, this one is not perfect. It is merely a general framework to keep you focused on the problems you’re solving, not a reference for all of your product decisions.
Minimum Viable Product
When you’re just in the idea phase your problem space will be fully filled out (if you know what problem you’re solving) and your solution space will be empty. You have no solution yet.
The goal of your MVP should be to move as far as you can towards the problems you are trying to solve as possible with the absolute minimum amount of development time spent. So your problem and solution space will look a bit like this.
Then from your MVP you need to get user feedback so you can tell if your solution is actually on the way to solving the problem. You can think of user feedback as regular course corrections towards getting to what you are solving. It took us about 3 weeks to create our best approximation of the problems we were solving. The product was very buggy, didn’t look great, and a we were manually uploading the content to it so it took a long time for the posts to refresh. A bad product like this is a great way to test if the problem you are solving is big enough that people are willing to use a poor solution.
Your user feedback will also let you know if the problems that you have identified are big enough problems for people to use your product. We had a great product hunt launch that let us know we were on the right track. We then talked to a bunch of our users to get more specific feedback.
From that feedback we made a bunch of changes and stability improvements. For example we thought an important part of the app was tagging all the posts with categories. Without an AI that meant we had to manually tag them and this ended up taking a significant portion of our development time. We learned from our users that this was not important to them, so the next version we removed them. This was a crucial course correction for us. Our next update was a big course correction towards solving the problems we set out to solve.
From here you’re going to just continue this cycle. Get user feedback, make improvements based on what they say, and repeat.
You do have to make sure that you aren’t just blindly doing whatever your users say. That could lead you astray from the original problems you were trying to solve. This is where this framework is helpful. Only listen to user feedback that helps you course correct towards your original goal. You shouldn’t be pivoting every few weeks because one of you users thought it would be cool if your product could do something else. Stay focused on your end goals and let your users guide you there.
While you’re working towards solving your problem, it’s likely that you will find out your initial assumptions about your problem space wasn’t perfect. In other words you need to adjust the problem you are trying to solve. This is what’s popularly known as a pivot. It looks something like this.
Because you had already made progress towards one outer edge of the circle it will be a longer path to move to another outer edge. However, the smaller your pivot, the shorter the increase in distance of that path.
Another thing that’s important is that you will only realize you need to make a pivot from user feedback. The less user feedback you are getting the further along your original path you will get before realizing you need to pivot. This means that the less user feedback you are getting the longer the potential path will be if you need to pivot (which you probably will, the original problem you wanted to solve was just a guess).
Keep Scope Small
This visualization will also help you see why working iteratively on your product, creating very small updates, and getting regular feedback is crucial.
Remember, with this framework the goal is to decrease the overall length of the path towards solving your problem. You can visualize this as trying to make the path as straight as possible towards your goal. A straight line would be the absolute shortest path.
If you are waiting a few weeks or a month to ship a big update to get feedback on, it’s very possible that you are moving off on a path going the wrong direction. That would look something like this.
The longer you go without getting feedback on your product the higher the chance that you are going off in a direction non-optimal for solving your problem. On the flip side the more often you get feedback the more regular course corrections, the shorter your average path.
You want to decrease the amplitude of each zag, and the only way to do this is to keep scope small for updates and get regular feedback on how you are doing.
One last thing to remember when it comes to this visualization. It’s very easy for you to be biased in terms of how close you are to solving the problem. You’re probably looking at your product in terms of whatever you pictured before you started working on it. Your users are looking at your product with a lot more skepticism. They only see it for what it is now, you see it for what it eventually could be.
This means that you need to use something like the Net Promoter Score to validate from your users whether or not you’ve created a solution that they would actually use long term. Don’t just go by your intuition and prematurely scale a product that isn’t ready yet.
Before you go…
If you want to get more startup advice like this check out our mobile app Playbook. With Playbook you can follow all of your favorite startup authors like Y Combinator, Marc Andreessen, Andrew Chen, & more. We’re still working on product market fit so we’d love to know what you think!