Holistic Product Discovery Framework

I held a session for a client about the Holistic Product Discovery Framework that I came up with way back and that our book is based around. Then I realised that the session could be available to anyone, as a primer to the framework and as a glimpse into the book. Enjoy!

Below follows a transcript including the slides.

---

Transcription of the video

Hello and welcome! In this session I’ll speak about a framework I came up with six or seven years ago that I call the Holistic Product Discovery framework. 

For you who do not know me, I am a product discovery coach and I’ve been doing discovery stuff for for a bit more than 20 years now. And I have realised along the way that some kind of framework that’s helping and supporting without being too demanding or too forcing, is needed, because people are struggling with doing Product Discovery. So that’s the reason for this.

I’m going to start off with a definition of discovery, so that we are on the same page. Discovery is about making sure that we’re building the right product. And we usually do that by finding the most worthy problem to solve and finding the best solution that solves that problem. We do that through learning as much as possible about the world, about what problems people have and how the solution might fit into the world. And we do all this to lower the risk as much as possible. We do not want to build something that nobody wants in the end.

You can see that this is very complex. There’s a lot of things to keep in mind on this principle level, which leads to way more to keep in mind on a method level. It would be helpful to have some sort of structure for all this. 

Way back in 2004 or so, I learned about this relationship between perspectives. Back then it was called the IDEO Trifecta. It showed up more in the product community under the term ”balanced team” some years later. The essence of this is that if we find the good intersection of user value, business value, and practical feasibility, we will get the right outcome for our product. But these three circles need to be in balance. So we need to look at these three perspectives kind of all the time during product development and even structure our teams around, such as Teresa Torres product trio suggestion.

So, what do the circles mean? The general definition of user value is that it’s something that actually gives something useful to a user which might be different from a customer. Note that the only one who can decide if it is useful or valuable is the actual user. So we need to go talk to the them. 

The business value we usually define as something that gives something for the organization business, something that fulfils a goal, a strategy or something similar. Usually it boils down to money. As a product manager or designer or developer, we do not really know about this either. So we need to go find that out as well. But we don’t have to go that far. Usually it’s enough walking around in the building to find the relevant stakeholders or the finance department.

The third circle, Practical feasibility, can be many things, but mainly we talk about it as can we build something sustainably which boils down to do we have the staffing now and over a longer period, do we have the technical competencies, is it a good time to do things right now, will it be okay to maintain, etc. And that we can usually find out quickly because we have a lot of tech people around who knows these things or maybe HR or engineering managers can help us understand staffing. 

And as I mentioned, the intersection between these circles will give us an outcome that is good for business, good for the user and good for the organisation and the continued development of the product. 

Hold that in mind for now. 🙂

Moving on, this is the double diamond by the British Design Council which is basically just another iteration on how we do user centricity or user experience. This covers the user value aspect very well.

The double diamond represents a good way of thinking when finding the real value. It is divided up into two parts, two diamonds. One is to make sure that we find the right problem, the worthy problem to solve, and one is to make sure that we find the right solution, the best solution for that worthy problem. And what we do is that we explore alternatives in both diamonds, divergence, and we decide upon alternatives in both diamonds, convergence. In the first diamond we understand the problem space and prioritise down to the one worthy problem to solve. In the second we explore the solution space, for instance brainstorming many solutions, and then validating them so that we get the best solution for our problem in the end. We should start with the problem, because people are very good at coming up with solutions to problems that are not actually worth solving for more people than maybe only themselves. 

This is a very iterative process. It is not first you do this and then you do that, it is really going back and forth to make sure we’ve understood the situation properly. Such as interviewing many different users and creating several different prototypes that might help these users as well as iterating over different levels of fidelity of those prototypes to not only make sure we solve the right problem but also solve it in an efficient way and making the users happy. 

So we do start somewhere, it’s good to start with the problem. People usually start with the solution and then we want to iterate over a lot of information and have lots of analysis and stuff to boil it down to.

This may sound like a gigantic amount of time and to that I’d like to point out a couple of things. Building quickly a solution that nobody wants often places you in the sunk cost fallacy, you’ve build something that you have invested money and time in, so if we only invest a little more, another feature or two, it will be something the users want. This is of course not the case, but it is very hard to see that in the heat of the battle. Investing in product discovery is worth the time. With that said, there are ways to prioritise what we actually need to do discovery on and also more easily decide how much time we should spend on it. These things are what my framework can help you with. But before digging into that, I need to explain one more aspect. 

I have modified the double diamond a little bit for my purposes. I believe British design council went a little too far with their alliterations. The half-parts of the diamonds are called, in order, Discover, Define, Develop, Deliver. It was never the intention from the design council to mean that the two parts of the solution space diamond should be to produce the product and deliver it to customers. Develop in their sense means to ideate, innovate, put forward solution ideas, and Delivery means to check with the customer if we’ve built the right thing. 

To actually build the product right after doing problem space discovery and then realise it doesn’t solve the problem well, that would be very costly. So, I’ve changed the names to Explore problems, Structure problems, Innovate solutions and Validate solutions, because I believe that tells a truer story. 

So, that was the double diamond from the UX domain. I worked as a UX person for many years and often wondered what kind of processes and structures that existed in the business domain and in the tech domain. I found a few, but not as mature and structured as the UX processes. So, why not use our processes to cover the other aspects as well. That made me combine the double diamond with the three perspectives, the balanced team approach, that I spoke about before. 

Then we get the Holistic Product Discovery framework. A framework in the original sense of the meaning that this is like guardrails on a motorway or in a staircase. Nothing that forces us to do a specific thing. It just saves us from falling to certain death. 

This framework, a matrix with twelve empty cells in it. This is it. This is the framework I’ve been using for many years now, together with colleagues. And we’ve found that it helps a lot. It helps giving a structure to what to do, making Product Discovery a little bit less messy, focusing your efforts, and it helps lowering the risk sufficiently. It also helps giving the people doing product discovery a bit more confidence that they’re actually doing something that is worth doing. 

This framework is domain agnostic, phase agnostic and method agnostic. You can use it in many different ways, and I’m going to go through a few of them.

I usually hear questions like, okay, now we’ve done this, what are we going to do next? It is hard to know what to do next, so people would use a more strict framework, like for instance a design sprint. It tells you minute by minute what you’re supposed to be doing. And that’s very good in many situations, but it’s not flexible enough and you need flexibility in this as well as structure. 

So this is the first way to use the framework, what we call stating the risk angle. If we just look at this framework as a prompt and go, have we done any discovery in general? Do we know what the problem is actually? Do we know what this good solution is? Do we know it from a business value perspective? Do we know it from a user value perspective? Do we know it from a feasibility perspective? Just thinking about it, just discussing it, will help us understand the risk we’re taking if we decide not to dig deeper into the parts of this framework. We usually recommend using the framework exactly like this as a start. Looking at each cell and think about the level of risk we might be at at the moment and where we might be if we do not try to lower the risk by learning something. And I’m not pushing anyone to do discovery, if people think that they do not need to do discovery, then that’s fine. I’m just trying to make them think a little bit before taking that decision and also taking that decision explicitly, such as hey, we do not need to interview users because we’ve done that a lot in the past and it shouldn’t have changed.

Maybe we say, okay, that’s fine, we’ll take that risk because we have discussed it and we have realised that the risk is maybe not super high. And we can do this for every cell in the framework.

So that’s the stating the risk angle. If you highlight these risks up front, you have done a huge part of discovery already, because this is what discovery is, lowering the risk, deciding on what’s most risky. So that’s one way to use this. 

Another way to use this is to write a question in each cell what is important for our company? Here are some example questions from a Swedish pharmacy viewpoint. The Swedish pharmacy market was opened up a few years back, before it was state-run. Now it’s private sector, so we have a lot of competition and the pharmacies really need to find their unique value propositions. So business value is very important for them. What is our market landscape? What might be a valuable gap in that market? How do we exploit this market gap? And will this exploit give the intended outcome? That’s where they focus a lot, but since we want to do this holistically, that’s not the only thing that they think about. They also think about user value, what are our actual users’ context and needs, which user needs are important, et cetera, et cetera, and then of course also bring in feasibility. What can we create and sustain at the moment? In this case, this is an example I go back to quite a lot. This pharmacy that I created these questions with, they actually didn’t have any app developers. So they realized, oh, this is the capability we have right now, what can we do with that? Or should we maybe get app developers in? They got app developers in and then they realised there are these new possibilities we just opened up. So this is the powerful questions angle, the things that you might ask yourself what’s important for you in your product development right now? What should you bring into this? 

Another angle that you can use this framework for is the historic angle. Here I’ve detailed out in dark grey, things I did in a project way back. In short, we got a business outcome from the business owner. We did user interviews, we did personas that detailed out the user needs to explain to everyone what the problem was. We prototyped and tested a solution with users. The developers used a known framework and architecture they’d worked with before. They tested out, spiking, different technical details, and then we delivered Agile style Iterative and Incremental together and we got happy users. But when we were going to sell this, no one wanted to buy it because in this case the customers were the users’ managers, and we hadn’t actually done that much in the business value track. So we tracked back and realised, oh, we didn’t do any validation with customers if they wanted to buy it. We only had one business model that we decided upon, which was a subscription service. We haven’t actually done any customer research, so that is probably the key problem. But we can also see that we only tested one solution for the users. It worked though. We were lucky. That was not skill. 🙂 Maybe it wasn’t the best solution either and we didn’t actually check the technical landscape for the framework and architecture that we decided upon. This did come back and bite us a little bit later because it was a JavaScript framework that went obsolete, so developers had to rebuild those parts. But the big problem was that no customers wanted to buy the solution. So we can look at our previous projects and see the gaps and get explanations. 

We can use a similar angle on what we are currently doing, the present angle. What tools have we used, which risks have we lowered, and where might we be lacking? So, in this project, people have been doing stakeholder interviews, competitive benchmarks, some surveys, used Opportunity solution tree to structure the problem, used the value proposition canvas to find possible good gaps in the market, used prototyping, testing with users and then later some A B testing when they have a product running. But there’s a lot of white space in this. There’s obviously things that these people haven’t done. Maybe that’s okay, maybe that’s a risk they were willing to take, but it’s pretty good to visualise it in this way to realise that. For instance, in this case, this actual example is where people thought that the market research survey would cover the things you get from user interviews or user observations or something like that, and it didn’t. So this is how you can use it where you are right now. Just fill it in and see where it’s still blank.  And if you feel that you are a little bit lost, then it is easier to see what you might need to do where. 

There’s no set recipe for exactly what to do where. You can even use some of these methods both for the solution space and the problem space for instance. But here’s a list of example tools, we simply call it the toolbox angle. So when you are using the previous present angle, when you find a gap, you can go like, okay, we have a gap in explore user value problems, maybe we can do user research, user interviews, customer service interviews, analytics reviews, oooh that last one, that might be useful for us, let’s go with that one, because it seems to help us lowering the risk as much as possible. So this is like instead of sticking with one set way of working, you can use the toolbox to decide which tool we should use to lower the risk as much as possible. 

People have collected methods in frameworks or processes before, the only catch is that there seems to be no frameworks that will cover all the perspectives we would like. But, we can pick and choose a bit to make sure we have good coverage. There are a good bunch of business analytics methods, such as business model generation from Alexander Osterwalder at Strategyzer. We have Lean Startup methods from Eric Reese and Steve Blank as well, but also frameworks like requirements engineering, which was a big part of waterfall methods back in the days and the methods in it are still extremely useful. In the user value lane we have most user experience methods, which I mentioned before is a mature domain when it comes to methods, so there’s a lot to dig into such as design thinking and lean UX. Within feasibility, the main things are organisational structure methods, a little bit of service design and then a lot of technical methods. But there are very few step by step frameworks, playbooks as we call them, in the feasibility space. So here you have to be innovative yourself.

But you can also use playbooks. You can for instance follow the previously mentioned design thinking process. That’s a playbook. You can map that out, then you can explore a little bit about what you’re missing and add that using this framework. Me and my colleagues have created a few playbooks over the years based on the holistic product discovery framework. Here’s an easy but quite holistic playbook that starts with getting an hypothesis or a business goal and goes on to do user interviews. The result from user interviews end up in user stories, the actual version of a user story which details out a need and an outcome and not the feature, because we’re in problem space still, we don’t know what features will solve that at all. We use some models from Netflix old chief strategiser Gibson Biddle. Here we use the DHM model to cover some parts of the business value space. We use Wardley mapping from Simon Wardley which details out a little bit about the evolution of our technical platforms and technical capabilities. And all of that feeds into Jeff Patton’s user story mapping which helps us structuring and prioritizing possible solutions and mapping out the risks. By the way, we’re still in discovery. So this is not a planning tool for delivery, that’s not what we’re doing. It’s more of a planning tool for what the product ideas we have, which ones would actually create a good product for us and we can validate that through a few different ways. 

So, that’s the playbook angle, following a playbook through the framework. The catch is, as I said before, it’s not flexible. So when we’ve coached companies giving them a playbook, after a while they usually realise that they’re just going through the motions. They’re just doing this user story mapping exercise even if it’s not making sense in their current situation. 

What we want to do is to use what we call a guide angle to continuously try to think of what happens next. Not detailing out a plan from the beginning but using our experience, our context and our brains, responding to the current situation with the best method. 

Almost every product development effort starts with, as I mentioned before, getting an idea from somewhere. We get a feature request or something similar from some kind of stakeholder. The first thing I would do then, because that’s a solution request, right, is to ask what’s the problem, why is this request important? This is the start of a stakeholder interview. And when doing these stakeholder interviews, focus is understanding what the underlying problem might be that they are trying to solve with this idea, this solution. Somewhere along the way I need to structure that information I get in some way. In this case I think it makes sense structuring it as a business goal, starting an impact map. Or you could do it as a business outcome in an opportunity solution tree. Or you can do it in a business model canvas. You can do whatever fits your thinking at the moment. 

And one thing that we may find in this business goal is the target group, this is the new market that we’re going to address. We would probably need to go talk to this target group to check if they have that problem that the stakeholder says. So user interviews and then when we’ve done the user interviews and we found things, maybe we found that they work in a different manner, they have a different user journey, then maybe that’s how we structure a problem. Or maybe we found that their needs were different from what the idea was. So then we list them as user needs. And since we did a start of an impact map before, there is a place for user needs in that map (as in an opportunity solution tree). So we continue there. So what’s next? Maybe we should look at feasibility of things, but we don’t actually have solutions at this point. But it might be good to look at the capabilities, start thinking about those. Maybe it is time for a Wardley mapping. It might also be good to start innovating solutions both like how could we solve this from a business perspective and how can we solve it from a user perspective. I don’t know, it depends on many things. 

So the framework in this case is just a guide and this is how I usually use it myself. 

This framework is also quite easily used for different stages of product discovery. It does not mandate a specific place to start. You don’t always start with someone that comes with an idea, it can start wherever.. But if someone comes with an idea. Or maybe not even an idea, maybe just like this is our possible business area that we can start with, then we can start exploratory. And when we start exploratory, we usually start with some kind of market research or stakeholder research and some kind of user research, greenfield exploration to understand things and these might find those new markets and the results might end up as a new product strategy, for instance.

If we already have a product strategy from somewhere, if we have a goal or an impact that we want to reach, then maybe we need to dig in a little bit more. So this is the strategic one, the second one on the slide. Then maybe we want to do some more detailed market research, detailed user research, detailed capacity research to understand possible unmet needs, possible problems to solve within that area… And then we go to existing markets and the results from this research also may end up in new strategies and maybe in roadmaps, et cetera. 

If we do have possible ideas that we believe in strongly because we have learned that they solve a worthy problem, if we have a possible product that we want to build, which is very common, we call this a tactical stage. What we mainly want to do then is to validate solutions to a known problem. So we do different kinds of tests to see if if this product actually solves a problem. And we will probably need to do some deeper market research, user research, capability research for that because we will find things in the validation that’s not matching our previous knowledge. So those three approaches are very much into the product discovery’s earlier phases. 

But product discovery should be continuous discovery. So when we are pretty far into the situation where we have a validated solution, we have lowered the risk so much so that we have a product out there that’s actually working for the users in general. Then we want to optimise things. And for optimisation, we can use things like A B testing, we can use usability testing, we can use different kinds of technical testing, such as integration test, system testing and whatever on that validated solution to optimise. 

I’m bringing this up here because I’ve been in a couple of projects where people have said that this is what they do for discovery work. And yes, sure, that is alsodiscovery, but maybe it shouldn’t start there. You would have fallen in love too much with your ideas at this stage for this to be an actual validation, for you to change the direction if the product is not actually the right one to build. I’ve also been in a project that started with A/B-testing and one of my colleagues pointed this out in a good way, he said ”how can we do A/B-testing when we do not have A nor B?”. Discovery has to start a little bit before Delivery to be really useful. 

All right, that’s the stuff that I was going to mainly talk about around how we can use this framework. There are a bunch of other uses that we have had of the Holistic Product Discovery framework, but these ones are the main ones.

If you want to try it out and there’s a web page called holisticproductdiscovery.com where you can download a PDF template. We’ve also written a book that is centered around this framework, but will for sure give you a lot more useful advise. You may also feel free to reach out to me, I can help you along the way with your Discovery endeavour. Thank you for listening!