From Problem to Experiment: A Framework to Validate Your Next Software Product Idea
On how to go from the fuzzy to the concrete, with a practical example
Introduction
One thing I’ve struggled with in the past is connecting the dots between coming up with a useful process that threads from idea generation to execution and the development of that idea into a software product.
This is a common problem in today’s software development-oriented world, and a common issue whether you are:
an employee (e.g. Product Manager) looking to execute a problem statement brought to you by your customers or fellow employees
an entrepreneur looking to develop software-based solutions for a software problem
Most importantly, the usefulness of the process lies in the ability to take you from a random and nebulous territory (the land of ideas and problems) to the concrete world of product, software, and most importantly user feedback.
In this article, I break down the process of breaking down (no pun intended) the steps from the loosely defined former to the latter.
Note: I’ve experimented with this process myself while chatting with some friends about it and getting to about page number 37 (not great progress, I’ll admit) of the following book, which I greatly recommend if you want to dive deeper into the topic.
I am by no means a Product Management expert or Guru. I just want to show you what worked for me when it comes to thinking about these concepts in the hopes that this resonates with you if you’re stuck on where to even start. Let’s dive in.
Major credit to Agostino Calamia for the great and insightful conversations on this topic and for sharing the key resources I’ve then gone back to analyze for this piece.
Idea stage: or is it better to have a Problem?
I used to think coming up with killer ideas was the holy grail for these types of situations. It’s much better to run into problems that are widespread and that you likely keep encountering in your day-to-day.
You can start collecting problems simply by observing what obstacles you run into the most when using software, or what processes you find yourself wishing for a solution that seems to incredibly not exist online.
Practical Application: Let’s use, for example, the problem of wanting to avoid one’s calendar becoming too crazy, either because back-to-back meetings keep coming up or because you find yourself constantly interrupted while trying to get in focus mode.
There are likely many recurring problems you have, and the ease you can come up with problems is likely inversely proportional to the one that you one that you need to come up with a killer idea.
Once you have either of the two, let’s figure out how to break it down into a potential product.
Problem to Experiment: the Opportunity Solution tree
Once we have clarity on the problem, we can start leaning on a key framework developed by Teresa Torres, called Product Discovery, which breaks down the problem into a feasible experiment we can test and run.
Let’s review the key steps of the framework, which is organized around the Opportunity Solution Tree.
The key elements of the framework are:
Desired Outcome: the main goal you’re trying to hit, or the solution to the problem you have generated, ideally expressed in a single quantitative metric.
Opportunity: the major pain points or needs you run into that are directly tied to the outcome. These can be further broken down into multiple layers as needed to increase the granularity of the pain point/need.
Solution: potential solutions to those pain points
Experiment: practical, tangible tests that stress the solution to determine if it’s fit to address the opportunity and overall outcome
An Illustrative Example: Personal Calendar Quality
Using our prior example, you can check out an illustrative Opportunity Solution Tree developed in Figma (Illustrative Example only)
This structure keeps a degree of flexibility. You can see how there are multiple opportunities tied to a major opportunity, and multiple solutions tied to an opportunity.
Finally, a subset of all the solutions gets selected as “Winners” and you can proceed with running your generated Experiments in the real world.
Experiment to feedback
Once you’ve selected your winner solution to start testing with, you can start building an actual prototype to get feedback on the solution and see whether it solves your opportunity tied to your desired outcome or not.
Back to our example, a simple landing page such as the one below can be spun up to start gathering feedback on whether a smarter personal calendar assistant could be used to solve the original calendar problem.
In this case, a simple landing page with an embedded Google form may be all you need to get started.
Then, depending on the level of feedback you get, you can either validate the experiment and dig deeper with it by scaling it up (if you receive positive feedback), or abandon it and move on to the next experiment, or challenge your original Opportunity to Solution assumptions altogether.
Summary
Overall, I hope this article gives you a useful framework to get unstuck when looking to execute on the ideas and problems you are probably surrounded by, in your professional as well as in your personal life.
Best of luck, enjoy the ride, and thanks for reading!
Find me at @thedatanewsletter.io