Those of you, who did not read my previous article, should know that we are building a product. Well, a hypothetical one, to illustrate the different stages of lean product development.
This product is a gadget equipped with different sensors, which can be mounted on micromobility devices, like a bicycle, an e-scooter or even a skateboard. When approaching an obstacle or when detecting danger (such as a vehicle, pedestrian, crossing, etc.), our gadget will emit sound and vibration alerts, helping us travel in safety.
In the previous article, we already determined what assumptions (problem hypothesis) we need to answer in the problem validation stage and I also showed you the available tools to test these assumptions.
Our next step will be proving the problem-solution fit. When entering this stage, in the Learn phase of our loop we’ll be looking to prove the following assumptions:
We call these assumption value hypotheses. As the name implies, the value hypothesis proved that our solution brings added value for our users.
In the problem validation stage we probably discovered lots of user pain points, and hopefully just as many opportunities to improve the daily lives of our users. If our product manages to soothe these pain points and deliver these improvements, then our value propositions will be valid, and our problem-solution fit proven. Let us see what steps we can take to achieve this.
One of the most useful tools to prove problem-solution fit is the value proposition canvas, introduced by Alex Osterwalder and co., in their book titled Value Proposition Design. The canvas is as simple as it gets: it’s made of 1 square and 1 circle.
We begin filling our canvas with the circle, which contains our observations of our target audience. The circle (user profile) is sliced into 3 subsections:
We can source this information from the user personas we created in the problem validation stage, as the assumptions we set when creating the personas have been already confirmed (or contradicted) by the user interviews. You did update your personas after the interviews, did you?
If we have several personas, we are going to have multiple value proposition canvases since, naturally, we have a different value proposition for each user group. Write down each job, pain point and gain on a post-it note and stick it in the correct space on the canvas. If you wish to create a digital canvas, I would recommend using Miro.
When done with the circle, we can move on to the square, called the value map in the Value Proposition Design, which is also split into 3 subsections:
Scribble them on a post-it and paste them onto the canvas. Compare the pain points and gains under the user profile (circle) with the pain relievers and gain creators under the value map (square). Do they match? If so, then we (probably) have a product-solution fit.
If they don’t match, then we should look at the canvas more closely. Pain relievers and gain creators that don’t have a corresponding item under user profile, are probably answers to user needs that don’t exist, hence they are superfluous.
On the other hand, if some pain points or gains don’t have any correlation on the value map, then it’s a good indicator that the service or product needs more thought.
Pain points and gains can also be prioritised. We should by now, based on the interviews, have a pretty good understanding of which are the most important to our users. If some pains or gains are repeated across multiple user groups (personas), then that is a good reason to give them a higher priority. Concentrating on the essentials and we should iterate until a correlation is achieved between the user profile and value map.
A value proposition canvas can be filled by us, as a team, but as with journey maps, it’s much more exciting to co-create it together with potential users.
Another canvas… I think it’s getting pretty obvious by now, that I love canvases.
I first learned of the user-centered business canvas from Csaba Házi’s UX Kitchen podcast, and immediately started using it, albeit with a couple of tweaks. The structure of the canvas closely resembles that of Alex Osterwalder’s other famous canvas, the business model canvas, and Ash Maurya’s lean canvas. This isn’t by accident, as the UCBC was heavily influenced by them. But while the former is much more business focused, and the latter problem and product focused, the UCBC puts the relation between user needs and solution front and center.
But let us see what this canvas is all about. We can see 11 cells, split into 3 distinct sections. The leftmost 2 cells describe our problem, the middle 6 describe the relationship between user and solution, while the rightmost 3 are all about the business aspects. These 3 sections create an easy to follow product development curve, all the way from problem validation to product-market fit.
We already know the answers to the problem section from the user interviews in the problem validation stage. We input the user problems, pain points and challenges in the top cell, and the existing solutions in the bottom cell. These can be competitors, but also methods our users currently employ to solve their problems. In our case, these can be other safety gadgets, but we could also note wearing a helmet here.
The middle section will also be familiar. The user types are basically our personas. The user needs/goals and user fears cells can also be found in our personas.
I must however talk a bit about early adopters. The term early adopter was popularized by Geoffrey Moore, in his book title Crossing the Chasm. Moore identified 5 distinct user types, based on how likely they are to start using new technologies (or products).
These are the innovators, early adopters, early majority, late majority and the laggards. Moore observed, that for most new technologies (especially disruptive technologies) it’s exponentially harder to reach (or to market to) the early majority compared to the early adopters. Hence the chasm.
To be able to test our product, we must first convince our early adopters. They are going to be the key to reaching the majority, and that is the reason why they have an important space on our canvas.
Going forward with our canvas, we reach the solutions and value proposition cells. Luckily, we already have these filled in our value proposition canvas!
The final 3 cells describe business aspects, which we won’t cover in the problem-solution stage. But they should be pretty self-explanatory.
The UCBC, just as the personas or the user interviews, is a tool that can be used throughout the different stages of product development. Sometimes I start with the UCBC and use it to build my personas and value proposition. But most often, I first use it in the problem-solution fit stage.
By tinkering with our value proposition until we correlate the user profile and value map, we haven’t yet proven our value hypothesis, and we cannot yet talk about a problem-solution fit. We have to test this correlation. Note that, if we co-created the value proposition with potential users, we have already made a small step in the right direction.
You could ask yourself the question, and rightly so, how we can test our assumptions, without a product? Luckily enough, there are some more tools in our arsenal, that can help.
Probably the most widely used validation tool is the survey. While the user interviews count as a qualitative tool, surveys and quantitative.
Lots of product teams wrongly use surveys in the problem validation stage, as a substitute for interviews. The problem with this is that it assumes we know the questions we need to ask of our users. Furthermore, because you also need to offer response options, it assumes we already know the answers. As we learned from the last article, the problem validation stage focuses on discovering about the unbeknown. And for that purpose, interviews are a much more suitable tool since we can ask follow up questions and dig deeper.
But while surveys are not suitable in the early stages, they are much more effective in confirming the knowledge we have already acquired. Dan Olsen, in his book titled The Lean Product Playbook, calls this doing quant on qual, that is doing quantitative research and qualitative data.
Let’s create a survey which tests our value proposition. Do our pain relievers really soothe the pain points? Do the gain creators deliver the expected results?
In the case of our product, we might ask respondents to rate on a scale of 5, how likely they would be to trust such a gadget, or how important they consider they’re safety to be in relation to that of others (like pedestrians). We could also ask, if you would use our gadget together or instead of other protective equipment like helmets and knee pads, and which one would they trust more. We could even ask which functions would they rather control via the gadget’s touch screen or buttons, and which could be hidden inside the companion app.
Debunking all the secrets of the art of surveying is beyond the scope of this article, but if I had to point out the one thing everyone should take into consideration, is including filter questions at the beginning of your survey. These questions allow us to filter out non-relevant responders.
In the case of our product, responders who never use micromobility devices, will not be relevant to us. Similarly, opinions of those who only use them in controlled, safe environments like skate parks, will be less applicable. We should ask them preliminary questions like how often do they use micromobility devices? Where do they use them (in what context)?
When compiling preliminary questions, we can turn to personas again (I told you they’ll become useful later on as well). If we have multiple personas, consider creating several personalized surveys.
Another technique to test our value proposition is the concierge experiment. This experiment involves selecting a couple of users, for whom we provide a similar user experience as the end product would do, while implementing the functions manually in the background. Basically, we replace a complex technical solution with humans.
Obviously, this experiment doesn’t work for every type of product. Let’s take our product idea for example. Unless we want to run after an electric scooter, shouting at the operator when we spot some danger, it’s hard to see how this experiment can be implemented. More importantly, it’s also pretty far from the expected user experience.
Probably the best known concierge experiment is that of Manuel Rosso and his Food on the Table project, which Eric Ries also mentioned in his The Lean Startup book. Manuel’s vision was a digital product that would take into account the eating habits of users and the different discounts at local stores, and compile a weekly meal plan and grocery list.
Instead of jumping in and starting to develop the software, Manuel chose to experiment first. He picked 1 user (!) and spent some time understanding her eating habits and favourite recipes. After this, he delivered her every week with the groceries and a recipe list which can be created from those groceries. He asked the lady’s opinion of the recipes which allowed him to improve his service, and more importantly he took a check for $9.95.
Of course this was not profitable and nowhere near a scalable business. But Manuel did gain valuable new information week in, week out. Soon, he expanded his customer base with a couple of new users. The simple fact, that these users were willing to pay for this service every time they knocked on their door, proved their value proposition.
When starting our search for the problem-solution fit, we were looking to prove the following assumptions:
Our first step was to define our value proposition. This can be done by (co-)creating a value proposition canvas. A user-centered business canvas can help visualise the user needs and possible solutions.
These tools help us define, structure and visualize, but they are not enough to prove our assumptions. To do that, we can use surveys or a concierge experiment, if the nature of our product allows it.
Once we manage to prove our assumptions, we can proceed to our solution-product fit stage, otherwise we can always pivot.