We continue our work on the mutated Pythagoras tree product framework:
In the past blog, we went through the first refinement of our product idea, and we defined well the next entities:
Value space (existing value chain and our place in it)
Problem space (target customer and underserved needs)
These spaces above helped us to build Euler’s Circles with TAM/SOM/SAM numbers
Every next step is an excellent chance to make a kill decision about our idea.
I know it sounds creepy, but the primary purpose of this framework is to kill most of our ideas. But, at the same time, those survived ideas will have more likelihood to takeoff in the future. A good strategy is knowing what not to do and which ideas not to try, isn't it?
Green is about solution space
The solution is always an answer to specific problems. So it is easier to build the product and position it when you already defined problems the product will solve.
Although I, like most people, did it oppositely - I built the product first and then tried to figure out which problems it solves. I am not saying that this was wrong. I am just saying that it is easier to sell the product which solves real customers' problems.
We should consider software products/services in the same way as any other product.
Let's say we have an idea to build the factory which will produce CLT panels. However, we don't want to build it until we know the existing CLT panels demand in the market. If there is no demand, it doesn't make any sense to build a factory. The same story applied to the software products/services.
Let's go through the problems we defined in the previous blog post:
Responding to RFP takes a lot of time and efforts
Every new design iteration require cost/energy recalculations
The number of calculations is limited due to time constraints, so the best option cannot be found
Whatever I do, I always try to find or create frames/canvases/schemes, which helps me better structure my thoughts. For example, one of my many boards:
There are many possible canvases for problem-solution fit - for instance, this one or this one. Also, I usually use templates from Miro (check it here).
But let's no overcomplicate and create a simple table 'problem - solution - potential business benefits'.
The third part, potential business benefits, is essential when you deliver B2B products. 'Solution' is something you sell to the end-users. 'Business benefits' is something you sell to the buyers (decision-makers).
As we defined the problem-solution fit for ourselves, it is time to validate it.
The slowest and the most expensive way to validate problem-solution fit is to build a product immediately. But we don't want to choose the path where 'slowest' and 'most expensive' words stand together, right?
What other ways we have when validating problems our product will solve?
Conducting user interviews
Creating and testing landing pages
Developing and testing PPC / Paid Social campaigns
In this particular article, we will consider the first approach - conducting user interviews.
User Interviews
The main goals for these talks are:
To figure out if the problems we defined are real
To figure out the frequency of problems
To figure out the severity of problems
The tricky point about interviews that you cannot ask the questions like: "On a scale of one to ten, how important the problem for you?". Only the Russian people will answer honestly on such questions, or they will suggest asking someone else. 😉
There is a good book about talking to customers 'The Mom Test: How to talk to customers & learn if your business is a good idea when everyone is lying to you'. I highly recommend this book to anyone who needs to speak with customers.
Again, you cannot jump on a call and ask your potential customer something like "Does responding to RFP takes a lot of time and effort?" or "Would you buy our software if we will build the best Utility PV Configurator in the world?".
If you don't get why, read the book above. In this blog, we focused on principle steps.
So, before talking to customers, we need to build our hypotheses. Here is a simple framework how to do that:
We believe that the type of person Needs to solve the problem Which happens while the situation And prevents value or capabilities
Most of our hypotheses will be related to the problems we defined above:
We believe that Solar Precon Engineer.
Needs to solve the problem with tedious cost/energy recalculations because of constant layout changes.
Which happens while answering clients' RFPs.
And prevents handling more requsts to avoid loss-making projects. We believe that Solar Precon Engineer.
Needs to solve the problem with preparing not efficing solar farms layouts.
Which happens while pursuit phase because of time limitations.
And prevents winning tenders and getting more projects to build. We believe that Solar Precon Engineer.
Needs to solve the problem with not efficient installations and logistic schemes.
Which happens while preconstruction planning process.
And prevents avoiding loss-making projects. And so forth...
After defining hypotheses, we need to create an interview script (document, spreadsheet) and organise chats with potential customers.
Let's cover a few more points about user interviews.
How many interviews do we need?
There is no definite answer to this question. Let's put it in that way - when you started to hear the same answers again and again, it is time to stop.
What if, during the interview, we realised that problems are not relevant for the interviewer?
In that case, we need to take the opportunity, and we need to turn this conversation into a kind of exploratory interview. It is always good to figure out the other set of problems for our chosen customer type. So if you see that your problems are irrelevant for the interviewer, try to figure out:
What problems is the user trying to solve right now?
How does the user solve them right now?
What are the obstacles to the solution?
Do we need to have interviews with end-users only?
It is a tricky point, primarily when you work with B2B products. It is always good to talk not only to the end-users but also to the buyers or decision-makers. End-users will give you insights about the product, and buyers will provide you with insights about the business model, pricing strategy, decision-making process, etc. We should adjust the hypotheses accordingly.
How to understand when what the user says equal to what the user really thinks?
Welcome to the empathy map. The best way to understand it is to consider a specific example.
Solar Precon Engineer SAYS: Our current software is not good enough. I would like to use something different.
THINKS: I don't care. I will use what the company choose. DOES: Uses the current software not perfectly and does not want to learn how to improve its use. FEELS: Apathetic.
Value proposition
Let's assume we did interviews, and we proved the problems, their frequency and severity.
It is time for us to build the value proposition and connect it with product features.
As I said, I love schemes and frameworks. So let's think up one which connects problem-solution with feature-benefit-value and our proven hypotheses.
This scheme above can be read as:
Now let's plug in the values of the variables and see what we get:
We believe that Solar Precon Engineer needs to solve the problem with tedious cost/energy recalculations because of constant layout changes, which happens while answering clients' RFP, and prevents handling more requests to avoid loss-making projects (the best quality of decision-making process when picking which projects to bid on).
We believe that automated cost/energy calculations will result in producing more physical/electrical layout options in the same time for Solar Precon Engineer. Because of producing more physical/electrical layout options in the same time, Solar Precon Engineer will achieve the best quality of decision-making process when chosing which projects to bid on.
We believe that Solar Configurator Software will result in the best quality of decision-making process when chosing which projects to bid on because we know Solar Precon Engineer needs to solve the problem with tedious cost/energy recalculations because of constant layout changes, which happens while answering clients' RFP.We puzzle it out and got the 'target user' connected to the 'problems', and 'problems' connected to the 'features', 'features' connected to the 'benefits', and everything is under the 'value' umbrella.
We can explain the value differently. However, it is still an excellent framework not only for product positioning but also for product development to not lose the guiding star when produce features.
To read more about product positioning and value proposition, I recommend the book 'Obviously Awesome: How to Nail Product Positioning so Customers Get It, Buy It, Love It' by April Dunford.
Conclusion
In this particular article, we covered solution space from a non-technical standpoint of view.
When building products/services, it is crucial to prove that we are solving the right problems.
It is equally essential to tie these 'right problems' with the product features, positioning and value proposition because all these vectors will define the product takeoff.
In the next blog, we will discuss Go To Market strategy and its connection with Value Space, Problem Space and Solution Space.
Thanks for reading to the end. 😉