I’m a big fan of making things as simple as possible, but not simpler. As many of those witty quotes, this one is also frequently attributed to Albert Einstein, even though it’s unlikely he said it in quite those words. Nevertheless, he was surely on board with the meaning: Every idea, every concept, every argument can in principle be reduced to an essence, but one that’s often padded with a lot of fluff. For the sake of clarity, you should therefore strive to strip away as much of that packaging as possible. But the catch is: This essence itself is ultimately irreducable. Try to make that even simpler and the idea loses its meaning and its value. Hence, the key question becomes: What’s the essence?
Let’s take a look at our domain of product management through this lens: A lot has been published, said, and written about what product management is, let alone how you should go about doing it. It’s only natural that people are overwhelmed by the all the available frameworks, processes, templates, and tools. What’s more, once you’re going down the rabbit hole of any one of those approaches, you can quickly lose sight of the bigger picture. You may find yourself “filling in the template for the sake of the template” or spending hours doing research that feels quite unproductive, just the process you picked demands that you do so.
So, let’s examine a cross-section of the frameworks that are out there. And let’s see if we can distill a common essence, shall we?
What that’s trying to accomplish first and foremost is separating the problem space from the solution space. Keeping that distinction in mind can crucial, especially in tech-savvy environments, because it helps to avoid converging (prematurely) on a solution which would later turn out not to be of use for the customer. Or, in other words, building something that nobody wanted. Arguably, that’s one of the main reasons why new product endeavors fail and the most important thing that should be on top of the mind of every product manager.
But then, how do we find out what it is that people actually want? Again, we can take our pick of frameworks, approaches, and tools. Eric Ries’ Lean Startup is a prominent one that immediately comes to mind, for example, as a way of doing structured, iterative problem discovery. Here, our basic proposition is that we know precisely nothing about what the market would want. All we’ve got our own assumptions which may very well be completely wrong. Thus, our primary objective is to learn by first build something small, measuring its effect—that is, if our potential customers find it useful—and then iteratively improving on those learnings. With every such cycle we therefore become a little wiser and—rightfully—a bit more confident.
Alberto Savoia in The Right It proposes a similar, iterative approach of formulating hypotheses, validating them as quickly and with as little investment as possible, and improving based on those learnings which he calls pretotyping.
Let’s assume now that we’ve been through a couple of such cycles, our hypotheses look more and more valid, and our idea of what the market needs begins to crystalize. We’re eager at this point to venture into solution space, We want to rally more and more people to our cause and make sure they’re all working in alignment towards a common vision. But that, of course, necessitates that we put that shared vision into writing eventually.
A lean tool we can use to formulate what value we’re trying to create is Geoffrey Moore’s Value Proposition Template. You can either use it as a literal “fill in the blanks” template, or, if that feels a bit too awkward, just as a checklist of questions that you should have good answers to:
FOR ((target customer)), WHO HAS ((need statement)), ((product/brand name)) IS A ((market category)) THAT ((key benefit statement/compelling reason to buy)). UNLIKE ((primary competitor alternatives)), THE PRODUCT ((unique differentiation statement)).
While Moore’s framework already gives a neat outline of what it is we’re trying to accomplish, it might still be a bit too thin. For example, it gives us relatively little context as to why the target customer actually has the needs we want to cater to, in what context those needs exist, and in which particular ways they would benefit from using our product. To add more meat to the bone, we can expand on our value proposition by using the Value Proposition Canvas:
And if we want to go even further, we detail for whom exactly we’re trying to create that value by borrowing the “Persona Canvas” approach often used in UI/UX research. On top of pains, gains, and jobs, we’re now also considering broader aspects such as the channels by which we can eventually reach our target audience and how we want people to perceive brand.
But let’s take a step back and re-examine our Double Diamond: We have now quite thoroughly established what problem we’re trying to solve, as well as for whom we want to solve it, and what a potential solution might look like. But still, we haven’t yet considered whether that solution could ever become a commercially viable product. Those concerns which we’ve been lacking so far can be grafted onto the value proposition as well, by expanding it towards full-fledged Business Model Canvas—a framework that poses, at its core, the following questions:
- Value Proposition(s): What value do we deliver to our customers?
- Customer Segment(s): For whom are we creating value?
- Channel(s): Through which channels do our customer segments want to be reached?
- Revenue Stream(s): For what value are our customers willing to pay?
- Cost Structure: What are the most important costs inherent in our business model?
Anyone who’s been through Econ 101 of course understands that particularly the last two questions, namely those involving revenue and cost, and, by extension, profitability and financing, can become overwhelmingly complex really fast. In order for us not to get lost in the details, let’ break them down into two separate aspects: First, let’s consider our Unit Economics model: Here, we’re focusing on (a) what we will charge for each item that we’re selling (e.g. for a single license of our software or for one package of our product that goes out to a customer) and (b) how that revenue relates to the costs we incur for producing that one item. The second level of concern is when we will eventually break even: Given that we will need to invest substantial time and resources upfront, before we can even sell that first item to the first customer, when will the product be able to pay back that investment? How many customers will be need to acquire at which point? And, therefore, what’s the financing gap from now until then which we have to bridge?
As we’re working on those questions, we’re getting closer and closer to identifying whether our product has a fighting chance of becoming a commercially viable endeavor—that is, as I like to call it, a problem worth solving. But at the same time, another important angle begins to open up: Timing. In order for us to predict, even at a high level, when we can expect to break even, we need to have an idea about which features we’re going to release at which point in time, to how many customers, and what they’re going to pay for them.
Again, we’re approaching a rabbit hole which one could easily be getting lost in, namely that of product roadmapping. Of course, there are countless ways of going about that, ranging from a simple, rank-ordered backlog up to complex, milestone-based schedules which aim at integrating and aligning the work of many different teams.
Let’s just examine one approach that falls somewhere between those two extremes, but definitely more on the leaner side: User Story Mapping. Here, we start with outlining the main path along which our users will eventually navigate the functionalities of the product. Next, we’re breaking each step along this “backbone” down into progressively more advanced ways of achieving it. The great advantage of this model is again that it forces us into a very iterative way of thinking: “What’s the simplest thing we can provide so that the user can accomplish this step of the journey?". Furthermore, it’s a nice benefit to be to cut and slice product releases out of a story map once it’s in place.
In the following example, we’re mapping the main features of a simple online shop: Users should be able to login, browse our inventory, and ultimately check out and pay. If we try to break each of those steps down into simpler and simpler solutions, we can quickly identify what a “version 1.0” could look like:
There are, of course, many more topics to product management than those we covered thus far. We haven’t scratched the surface on monetization strategies, on architectural concerns (functional or technical), on user experience, or even go-to-market. And for each of those, and countless more aspects of our complex domain, we can take a pick of a variety of frameworks, processes and tools. Nevertheless, the cross-section we’ve examined here is already quite useful if we want to answer our initial question: What’s the essence?
If we take a step back we’ll see that all the frameworks we’ve discussed revolve around three main themes:
- What is the problem we’re trying to solve?
- Is it possible to create solution for that problem?
- Can we turn this into a (commercially) viable business?
Or, more succinctly, the topics of desirability, feasibility, and viability:
Once we begin to think about them in those terms, two things become clear: First, we can now much more easily pick the right framework for the right type of job. For example, if we’re operating in an environment where the needs and pains of our potential customers are not yet clear, we can confidently open the desirability drawer of our toolbox and narrow down on this question, neglecting feasibility and viability for the moment—without dropping those concerns forever, of course.
And second, we’ve seen how those frameworks can, and should, interconnect with and build on top of each other. In some cases, such as with the value proposition template, the value proposition canvas, and the persona canvas for example, one just adds more nuance to a basic skeleton provided by the other. If we just want a rough sketch, let’s go with the former. If we need to expand on it, let’s use the latter to color in the details. Others have more of a “plug-and-play nature”, such as the business model canvas: We can use that as a kind of “meta-framework” or scaffolding into which we integrate progressively more details by applying other frameworks. We can even go so far as to craft our own “scaffolding” as long as we keep the essential questions in mind.
The point is this: By viewing the plethora of product management frameworks, processes and tools through the lens of desirability, feasibility, and viability, we can pick the right one for the right job, and also understand much better how they relate with each other. Every time someone mentions a new one, we can quickly assess where and how it fits in. And thus turn it into another arrow in our quiver.