Hey there, product development enthusiast!

I had originally planned to write only two newsletters about prioritization.But then I realized I had only briefly touched on a related topic in the last issue. But this one deserves more attention, as I see it often neglected or ignored. I am talking about the early phases of product development - Discovery and Design.

So let’s dive right in!

💡 Ideas Are Cheap. Delivery Is the Bottleneck.

Before we come to the early phases of product development, let me reiterate one key insight: In every company I have seen, there was always an abundance of ideas or things that could and should be done. That was never an issue.

What consistently is an issue, is the fact that delivery capacity is limited. You can only deliver a certain set of ideas, but never all the things you would like to.

That’s why prioritization is important—and why you also need to invest effort in the early phases of product development.

🔍 What Are the Early Phases?

Depending on your product development methodology, the names of the phases (and even their separation) may vary. For simplicity, let’s agree for the purpose of this discussion on four phases:

1. Discovery

2. Design

3. Delivery

4. Operations

In the Discovery phase, we identify the customer problem - e.g. through user research, data analysis, fake door tests etc. It ideally culminates in a question like “How might we enable our customers to do X?”.

That question then should be answered in the Design phase, where you open up the solution space and narrow it down to the specific approach you want to take. That includes the customer journey, maybe even with visual prototypes, but also the technical design for the services behind.

These two are the early phases of product development, before you start into the Delivery phase to build the solution and later into Operations to run it.

🧱 How It Doesn’t Work (Well)

For the Discovery phase, some companies employ methodologies like “executive driven innovation” or “hippo” (“highest paid person’s opinion”). 😉 That essentially means that decisions about initiatives to pursue are taken not based on insights into actual customer needs, but on opinions (typically of senior management).

As a consequence, the product market fit might be hard to reach. You might spend your delivery capacity on things that won’t help your customers and thus not your company - while not working on more impactful ideas.

What is also a very popular approach is to even skip the Design phase and start right into Delivery, involving full delivery teams with the initiative. But as the solution was not designed yet, they might not know what to do and waste their time trying to figure that out.

Another potential drawback is that without a proper upfront design, you might miss some parts that you will ultimately need for a successful product. That could include dependencies on other teams. If you discover them late, this will either lead to cost of delay or disrupt the other teams with unplanned work.

Imagine you are building a new hardware device for which you already have an operating system with a user interface. But only shortly before the launch you realise that you might also need to have some setup user flow when turning on the device for the first time. That will likely cause you some trouble and an inferior - because rushed - setup experience. Totally avoidable if solution design was done properly.

🌀 “But We’re Agile…”

These rushed approaches are typically advocated for as “agile”. A more systematic approach accordingly is discarded because of being “waterfall-ish”.

I totally understand that you cannot make the perfect plan upfront. However, not having any plan is not agile, it is just waste - of your scarcest capability.

Let’s consider this. In the first row “A”, you would immediately start with Delivery of a new initiative. Discovery is axed, no design upfront, so it happens while delivering.

The second row “B” represents a proper process with Discovery and Design before Delivery.

As you can see, in scenario A, where you rush right into Delivery, you might be on the market faster.

If you do proper Discovery and Design, you might be later, but the actual effort is smaller, because teams have clarity on what to build, don’t have to wait for a plan, or pivot because of changing plans. The effort is smaller even if you take Discovery and Design into consideration, as this is done by less people. Plus - the product in scenario B will most likely be better than the one in scenario A.

Consequently, the output of an organisation following approach B will be higher in total. As the time spent on Delivery for each initiative is smaller, they can work on more initiatives in a given time span.

🧠 Discovery & Design Require Capacity

For this, of course, we need to acknowledge that Discovery and Design also require capacity and do not come for free.

Discovery requires product managers’ time (together with user researchers, analysts…) and is essential product management work. In order to have that time, it’s always good to have engineers take responsiblities during Delivery, e.g. clarifying interfaces with dependencies, business details with stakeholders etc. This way, the team can run more autonomously - without depending on the PM all the time, who in turn can already invest in Discovery of future initiatives.

For the Design phase, you need PM capacity as well, but also designers and engineers. For designers, this is their natural phase, so all should be good. For engineers, you indeed need to invest time, e.g. from staff engineers to determine the future architecture. That should be their job anyways, so it should also come naturally.

✅ Wrap-Up

Skipping Discovery and Design isn’t just risky - it wastes your most precious resource: Delivery capacity.

Do it right. Plan the right things. Then build them well.

📬 I read every piece of feedback - hit reply and let me know your thoughts! Got a topic you want me to cover? I’m all ears.

💡Jan’s Knowledge Nuggets

The bonus inspiration this week:

• The resilience of alien chess 🧠: The VP of VR at Meta argues against planning. I still believe there is value in making a plan and successful companies like Amazon or Zalando do. But reading his post certainly brings different facets to the topic.

• Software Engineers are becoming Product Engineers: Like I shared in this newsletter issue, engineers shouldn’t just work through tickets. Companies like Chatbase expect them to think product, too.

• Agentic AI in Practice: I had the privilege to try out Manus, an agentic AI system that actually does stuff for you. Impressive… but not quite magic (yet).