Product decision-making is probably the most impactful aspect of early-stage startups. In this context, you have such limited resources that you simply can’t afford more than a few big mistakes. That’s of course very relevant to companies of any size, but for startups in particular it can be the most important thing. When you work with 12 to 24 months of runaway, 1 month wasted can be too much!

But the way product decisions are made is seldomly given enough attention at this stage. Usually, it receives attention only when the team grows and coordination/managing becomes an issue. Then you hire some ‘product people’, organize teams in ‘squads’, and hope they will know what to do.

Until there, usually, product decisions are made in an intuitive and ad-hoc way, which can yield a lot of good decisions, but lacks a bit of consistency and sometimes can lead to waste.

Deciding intuitively is also not ideal for the eventual growth of the team itself if you can manage to get there. When the company grows, it’s pretty easy to lose the team’s DNA if you don’t have your approach sufficiently defined. And with a bigger team, it’s a lot more difficult to make process and work style changes.

Of course, systematizing the decision process too early can also be a waste. We just need to find the right balance (as in everything else).

I bet there’s already a bunch of different product approaches you can choose from nowadays if you want to make your decision process a little more explicit/conscious. I’m not a specialist in that, but recently I read this book that seems to have hit a very fundamental point, for me - the definition of a framework to structure the relevant elements in product decision-making.

By framework, I mean a shared vocabulary, a model, a way to identify and refer to the different kinds of elements we need to organize and consider in our decisions. And how they relate to each other and our process of product and customer discovery.

We all have already participated in long and tiring meetings where people can’t reach conclusions. Frequently it’s simply because they are using different models to think and argue. People cannot understand each other if someone is arguing about testing an idea, while the other wants to prioritize a solution. Those expressions may look pretty natural at first, but when we make that vocabulary clear, and everyone understands how things relate to each other, it becomes pretty clear, for example, that we should not be prioritizing solutions, but “problems”; and that we should not “test ideas”, but challenge their assumptions.

You have many options for how to identify, analyze, classify, organize and prioritize between those elements. You may have different processes, tools and whatnot. But you’ll always need this common ground so the team members can understand each other and even disagree about it.

Essentially, the book defines these concepts:

  • Outcomes - what business and/or customers need to accomplish (instead of Outputs, by themselves);
  • Opportunities - can be problems, pains or desires customers can potentially have, that can lead to the defined Outcomes;
  • Solutions - are hypothetical ideas of how to address an Opportunity;
  • Assumptions - are implicitly made when you draw a possible Solution for an Opportunity;
  • Tests - are systematically made over Assumptions to clarify choices on possible Solutions;

And those concepts are related like:

  • We define the Outcomes we want to pursue, that can benefit customers and the business (strategical vision);
  • We look for, identify, classify, hierarchy, organize and ultimately prioritize opportunities that can impact those outcomes;
  • We ideate, hypothesize, discuss and elaborate ways of addressing the top priority opportunities;
  • We identify hidden assumptions each possible solution makes, organize them, and we Test some of them to make clearer the impact each possible solution can have (that feeds back opportunities prioritization).

Once these elements and their meaning are clear to everyone, it’s a lot easier to debate and decide things collectively.

The book also offers a lot of thoughtful and pragmatic ways of dealing with those elements. I love particularly the use of trees to organize opportunities. I’ve always been a mind-map passionate. It solves a very common and important problem in prioritization: It allows us to organize Opportunities hierarchically, making it possible to compare things at the same ‘size’. Also, it makes Opportunities as the right level of prioritization and commitment, instead of the much common Solution or even Task prioritization.

I also liked a lot the approach regarding how to collect and organize interviews in a way that’s useful to support the opportunities analysis mentioned above.

There are a lot of useful pieces of advice. But, for me, the big merit of the book is defining that common vocabulary so we can at least properly talk about those matters. You can even dislike the framework itself. But then you should propose another one. We simply cannot make good and consistent collective decisions without a coherent and shared vocabulary like that.

A final root aspect that I want to mention in the book’s approach, that’s neatly expressed in the title (two of three words - ‘continuous’ and ‘habits’) and is an intrinsic part of all recommended practices, is the continuous nature of the process. All the pieces of advice I mentioned should be made every day, continuously. That’s such a relevant perspective, especially for the extremely dynamic context of startups.

So, as you can tell, I highly recommend you take some time to read the whole book. And please tell me what you thought about it, if you do.