Hey there, product development enthusiast!

Welcome to the cozy autumn edition of The Tech Impact Uplift!

In this edition, I’ll tackle a topic often seen as not-so-cozy: escalations!

Contrary to popular perception, escalation can actually be a healthy mechanism that drives progress within an organisation.

But how do we ensure that?

Let’s have a look.

💡 Why Escalations Are Deemed ‘Inappropriate’

An escalation happens when an employee raises an issue to their leaders.

Why is this often deemed a negative thing? There are two main reasons.

Escalating an issue could be interpreted as:

• You can’t solve the issue yourself (indicating missing competence).

• You are complaining about others (indicating inappropriate social behaviour).

These two possible perceptions often keep people from escalating issues.

While both might occasionally be true, the advantages of escalation are far greater.

🔍 Progress in Organisations Gets Stuck All the Time

Most mature organisations today don’t primarily struggle with complex tech challenges, legacy systems, or missing hard skills. Instead, their biggest pain points are organisational and collaboration issues:

• Unclear roles and responsibilities

• Knowledge and collaboration siloes

• Unclear overarching priorities

• Interdependencies between teams

All these challenges slow down progress in organisations.

What they have in common is that individual employees within the organisational units cannot necessarily solve these themselves.

As a result, important initiatives are stuck. And if people are afraid to escalate, those initiatives stay stuck.

🧱 Why Escalations Are Valuable and Needed

That’s why we need to change the narrative: Escalations are actually a good thing!

When initiatives are stuck because people or teams are waiting for others but nothing moves, an escalation is needed.

If priorities are conflicting and unclear, escalations should be the tool of choice to come to a solution.

Every time individuals or teams get stuck, it’s their leaders’ job to get them un-stuck again. But they can only do that if they’re aware of the issue.

🚀 How to Build a Positive Escalation Culture

So how can you reduce the reluctance to escalate and establish a mindset that empowers leaders to un-stuck the organisation?

You need to lead by example and create a positive culture around this.

If someone brings you an escalation, these reactions will encourage them to do it again the next time they’re stuck:

• Most importantly (and this is what this is all about): help find a solution.

• Identify the root cause and fix it, but do it in a blameless, constructive way.

• Thank people for bringing it up, and emphasise how it helps the organisation.

Handled constructively, even tricky or political issues can be resolved without offence.

One mindset helps me every time: in 98% of cases, people act with good intentions - the system just nudges them into unhealthy behaviour. It’s our job to spot and fix that.

A classic example is when some team is not collaborating. This might be because they are (over-) loaded with work from other stakeholders.

Sitting down with them and revisiting (or clarifying) priorities often leads to a constructive solution.

🌀 The Dark Side of Escalations

Of course, there’s a dark side too.

I’ve seen behavioural patterns where people tend to escalate everything right from the beginning.

Sometimes even before an issue arises or before trying to solve it themselves.

They see escalation as an easy way to hand off work and responsibility to managers, avoiding direct conversations with other teams

That’s not healthy.

In those cases, I tell them to try solving it first - and that I’m happy to help once their best attempts have failed.

✅ Wrap-Up

All in all - escalations are much better than their common perception!

They’re a useful tool - especially in complex organisations - to surface issues people can’t solve alone.

Escalations help leaders identify and resolve those issues, which is a core part of our job.

So let’s make sure escalations are seen as a constructive, necessary tool - nothing to shy away from, as long as there’s a real problem.

That’s TTIU for today. I hope you enjoyed it and found it helpful. Let me know what you think!

📬 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.

Some cozy Czech woods 🌲

💡Jan’s Knowledge Nuggets

This week’s bonus inspiration:

• 🧠 How to keep your brain sharp as a leader: A super practical post by Taha Hussain on optimising our mental work.

• 💰 The real development of costs of AI: A smart reflection by Ben Torben-Nielsen on AI token costs dropping linearly while usage is skyrocketing exponentially.

• 🤖 The snares of AI running a business: A fascinating post by Mirela Mus about what happened when Anthropic let AI run a vending machine.

• 💡Your PM skills for 2026: Already on Nov. 5th the Product Management Festival will take place in Zurich. If you are into Product Management, you will learn all you need to succeed in 2026. With the code DISCOUNT20JAN you can get 20% off ticket prices. If you go there, let me know - I would be happy to meet!

Hey there, product development enthusiast!

Welcome to the summer issue of TTIU!

Today I want to talk about an ugly topic: Legacy software or technical debt. This is one of the most stubborn issues in software development. Why does it always slow us down and cost a fortune? And how can we do better?

Let’s get started!

❓️ What is “Technical Debt”?

What does “technical debt” even mean?

First, it has nothing to do with the age of software. 10-years-old software can be in perfect shape while a freshly vibe-coded app can instantly turn into nasty technical debt.

I like to define technical debt by three criteria, of which one would already qualify a piece of software as legacy:

1. Fitness for purpose: If software doesn’t fulfill its purpose, I consider it technical debt.

2. Adaptability & reliable operations: Nearly every software does regularly need to be adapted. Be it fixing bugs, complying with changed regulations, or adding new functionality. If you are afraid to change anything in your software because it might break, this is technical debt. Related to that are reliable operations. A software product that works, but is not available because of outages, severely hurts its value. If you cannot operate it reliably, you are in trouble.

3. Scalability: The last point that could render a software “legacy” is if it is not scalable, but the business requires it to scale. That latter condition is important as not every software needs to scale. But if it needs to scale and doesn’t, that’s tech debt.

Secondly, there are two levels to distinguish in a software product: the micro level and the macro level.

• Micro level: The micro level is about the implementation of single services. Examples of technical debt on this level can be missing test coverage, poor code quality and necessary refactorings etc.

• Macro level: The macro level is about the architecture that combines multiple services to systems. On this higher level, technical debt can be around storage of data (wrong technology or location, unclear source of truth), their processing (unclear domain boundaries, suboptimal flow of data), or the design of the system (monolith vs. service-oriented).

On both levels, the three above mentioned criteria for technical debt can occur.

But why?

🔍 Are my developers too stupid to do their job right?

I believe there are 4 reasons how technical debt comes to life:

1. Lacking skills of the developers

2. Time pressure

3. Missing understanding of the customer problem

4. Evolution of the business

The reason for technical debt can of course be lacking skills of engineers. This hampers adaptability, reliable operations, and scalability. But often this is not the problem.

I would say the biggest part of technical debt is created because of time pressure. In order to hit a deadline, functionality is added where it can be achieved the fastest (e.g. where a team has capacity), not where it would be right. Shortcuts are implemented but not cleaned up after the launch. This again affects adaptability, reliable operations, and scalability.

While the first two reasons are kind of common sense, what is often overlooked is a missing understanding of the customer problem. If the solution was designed the wrong way, this might result in the software not being fit for its purpose. Additionally, if a lot of inadequate functionality was built, which is not used or even misused by customers, that can also lead to lower adaptability of the software, complicated operations, and missing scalability.

Lastly, a software can become technical debt, even if you did everything right! Just because the business and its requirements evolve over time, your software might no longer be fit for its evolved purpose. Similarly, the scalability might no longer be sufficient if your business grows significantly. I had a case in Zalando, where a platform that was built well (with the goal of being easily usable), at some point couldn’t scale anymore and the whole data architecture needed to be reworked to focus more on a goal of an order of magnitude higher scalability - just because the business evolved!

🌞 How can we do better?

As we have seen, there is no way to avoid technical debt in general. Therefore, there are a couple of things a product development organisation needs to embrace to prevent and manage it.

If there is a skill issue with your engineers, obviously, you need to hire and train your engineers better and provide them the right tools, e.g. AI coding tools that can detect coding mistakes, add test coverage etc.

The time pressure issue is a more delicate one. The most important thing to understand for everyone about software development is, that there is no such trade-off between speed and quality!

It doesn’t exist. 

The moment you sacrifice quality in favour of shipping faster, you will inevitably be slower from that moment on. Poor quality leads directly to slower adaptability and less reliable operations of the software. Changes get more costly and bugs will keep your team from working on new features. I highly recommend reading the excellent book “Modern Software Engineering” by David Farley on this topic.

Having said that, I am aware that sometimes - due to external factors - you might need to hit a deadline and therefore will take shortcuts. That’s okay - as long as you really take the time to clean up. Systematically, no excuses. I’ll explain more about how to do it below.

If the issue is a lack of understanding of the real customer problem, then you probably have an issue with your product management approach. You might be shortcutting the early phases of discovery and validation. And the possibility of vibe-coding does not render that unnecessary - it even allows you to do that faster!

If your business evolves quickly, even the shiniest software can age overnight. This requires investments in your existing software.

💰️ How to invest in your software to not turn into legacy?

The only way to tackle the issues that arise from the evolution of your business over time, as well as the shortcuts you might take, is a systematic approach. You need to invest in your software to not become obsolete. But how?

Let’s look at the following diagram. It shows the amount of business value created by a software over time and two graphs:

Red graph: focus on feature development without investing in the software itself until it is too late
Green graph: continuously investing in the software

The red graph shows a behaviour that focuses on shipping features fast. As outlined above, this only works very briefly and then the technical debt slows down the value created - further and further. Since it is not addressed, it becomes unbearable at some point. The software becomes so hard to change (“legacy”), that it needs to be replaced entirely: A big migration to rewrite the software from scratch.

This is the scenario to avoid! 

The migration will take a long time, while little or no new value will be added for customers.

The green graph shows what happens if you keep investing in your software like a gym habit to counter tech debt created by cutting corners or an evolving business. The value delivered is not only much more stable, but also in total much bigger than in the red graph scenario.

So how can you reach the green graph scenario? You need a system for that!

To manage technical debt on the micro-level of your software, you should:

• Regularly dedicate time for refactoring, improving tests or updating dependencies. If you work in sprints, block the last day or two for it. And this needs to be a rule: You do it every sprint. Don’t waste time negotiating this with PMs or stakeholders every sprint - it’s non-negotiable.
  Pro tip: If you fail to do so on the last days of sprints - because this is where it gets hectic and things need to be finished - do the cleanups during the first days of a sprint instead.

• If you committed to a shortcut implementation to meet a deadline, do the cleanup immediately after (and communicate that from the beginning). If you don’t, you will never get to it.

• Agree on the Boy Scout Rule: Every code that any developer touches, they have to leave better than they found it. You can even build this into your CI/CD process by breaking the build if some KPIs like test coverage or complexity metrics get worse.

Managing technical debt on the macro-level of software requires more of a plan:

On the macro-level, improvements can normally not be done within a day or two. However, also macro-level investments in the software need to happen continuously.

1. First, you need to have an architectural vision that is a) informed by both technical needs and product strategy (e.g. to foresee the evolution of the business) and b) regularly updated.

2. You then need to break that down into work packages that are ordered in a technical roadmap. These will still be big and not doable in days.

3. The art here is to plan these in over time. Surprisingly often, you can combine upcoming feature work with such work packages that affect the same services. Jackpot!

4. If that’s not feasible, you’ll need to explicitly put them in the general roadmap. Still way better than a quarter-long death march of a migration.

The overall key is to constantly weave in the tech debt work - in sprints as well as in longer-term roadmap plannings. If you continuously invest like this to avoid tech debt, this will keep your velocity for building features high and prevent you from having to do big migrations.

🤖 How does AI change the picture?

As AI enters the software development scene, this affects technical debt as well.

If AI coding tools are used and function well, I assume this to be good news in regards to technical debt. With these AI tools we will be able to re-create bigger software systems that have become technical debt much faster. So if your product doesn’t scale anymore - just rebuild it in no time, at little costs!

This is the optimistic future scenario. We still need to get there.

Today, with all the vibe-coding coming up, I see the opposite risk of creating much more technical debt faster. If “anyone can (and does) code” without knowledge about separation of concerns, scalability, security etc. we create very fast and cheap tons of software that might not be changeable, cannot be operated well, do not scale. AI might become the world’s fastest legacy-software factory.

I think we overvalue how we can build faster with AI, because “faster” often means no tests, bad architecture, no security, no scalability.

At the same time, we undervalue how we can build better with AI. AI can exactly address all of the above. AI can optimise architecture for changeability and reliability. It can identify and fix issues around security, test coverage, or code complexity. I am convinced AI will replace documentation of software - allow any skilled developer to understand and change any unknown software in an instant by talking to it. And it’s just a matter of time until AI can significantly improve software on the macro-level as well. Maybe better than humans could ever do.

So in a few years, if we are lucky, the ugly topic of tech debt might have become a non-topic.

✅ Wrap-Up

That’s TTIU for today. I hope you enjoyed it and found it inspiring. Let me know what you think.

📬 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.

Greetings from windy Denmark

💡Jan’s Knowledge Nuggets

The bonus inspiration this week:

• We are f**ked with Social Media ☠️: A recent study found that social networks are bad for social dynamics even independent of their algorithms.

• Product Management Festival 2025 🎉: In November this year, the crème de la crème of Product Management will meet in Zurich for the Product Management Festival. The lineup of speakers is already great and more is yet to come. If you want 20% off your ticket, you can use my voucher code: DISCOUNT20JAN

• “Job hugging” has replaced “job hopping”: As the labor market continues to shrink while uncertainties due to AI and macro-economic conditions rise, people cling to their jobs as CNBC reports for the US. The situation in Europe is comparable, I would say.

• Local prioritisation is bad prioritisation: Very good examples that show how prioritising locally can easily be a big disadvantage. If you are interested in prioritisation in general, this previous issue of TTIU might be of value to you.

Hey there, product development enthusiast!

It’s two and a half years since ChatGPT was launched - the first in a wave of large language models (LLMs) that fundamentally change how we live and work. Unprecented fast iterations of these models and their capabilities, integrations of LLMs with other tools, and the rising agentic application are just further steps towards an artificial general intelligence (AGI) happening at breathtaking speed.

These rapidly advancing capabilities of AI affect more and more areas in our personal life, but even more at work.

What does that mean for the future of jobs and especially for people working in Tech - right now and in the more distant future?

Let’s have a look!

💡Today

⛈️ Jobs in Tech are at risk - that’s for sure.

Shopify’s CEO Tobi Lütke was amongst the first to promote this:

Shopify CEO says no new hires without proof AI can’t do the job

Tobi Lütke shared a memo outlining the expectation.

www.theverge.com/news/644943/shopify-ceo-memo-ai-hires-job

A lot of others followed and VC investors today tell the same to the companies that they fund. There have been drawbacks as well, e. g. when Klarna, after publicly claiming to fully automate customer care through AI, had to hire humans again.

As Klarna flips from AI-first to hiring people again, a new landmark survey reveals most AI projects fail to deliver

Just 1 in 4 AI investments bring in the ROI they promise—but CEOs just can’t resist the technology.

fortune.com/2025/05/09/klarna-ai-humans-return-on-investment

But don’t get fooled by that. What is impossible today, might be a total commodity by tomorrow. With the race between the big LLM developers OpenAI/Google/Meta/Anthropic in the US, DeepSeek and Alibaba in Asia, and Mistral in Europe, the rate of innovation stays insanely high. I was personally impressed by the new image creation capabilities of OpenAI’s 4o models, which I regularly use.

Introducing 4o Image Generation

At OpenAI, we have long believed image generation should be a primary capability of our language models. That’s why we’ve built our most advanced image generator yet into GPT‑4o. The result—image generation that is not only beautiful, but useful.

openai.com/index/introducing-4o-image-generation

With that, I created this design amongst others:

If you like it, you can buy this shirt.

Today, AI can help with most aspects of a business. From market research, to product development, to marketing - multi-agent systems can do all parts of the product development lifecycle. Accordingly, companies need less and less people for that.

Especially the entry level positions in many of these roles today can be done by a more senior person with the support of AI. The career paths and systems are about to collapse. You will need very few experienced people with AI to do what a team did before.

And we are still just getting started with AI.

❓️ So what if you are in Tech today? What’s the best places to be at in terms of job perspective? It’s for sure the ones where you learn and build up your AI knowledge.

1️⃣ The obvious choice would be to work for the main players in the AI market, like OpenAI or Mistral. But there are only so many of these players and they can pick really the best of the best employees.

2️⃣ The other place to be in Tech these days is in companies leveraging AI - for their products and their internal processes. If you can help them to do that, you have good job perspectives. There are so many companies who need to level up their game in terms of AI - especially outside of big tech, i. e. in practically all other industries.

3️⃣ As mentioned before, there are two trends caused by AI in the job market: a) Companies can be run with less and less people. b) Career paths in companies collapse as entry level jobs get replaced by AI.
But what got much easier at the same time: Starting a business yourself! As a single person you can use all the above mentioned capabilities and start your own business to disrupt exisiting ones or create new services and products. I expect that to happen much more as traditional employment relationships are anyways not loved too much by Gen Z and younger people (understandably so).

🧱 Product Engineers

Recently, I heard a CEO say the following:

While I can clearly see what he means, that would be quite expensive engineers.

Instead, I see a trend continuing - the elevation of engineers.

In the past, their role evolved from code monkeys like Scrum describes them, to topic owners who take overarching responsibility, e.g. for a feature. As productivity of developers is rising with AI, so should their level of work. Going forward, I expect Product Engineers who focus even more on customers and understanding their needs. With AI support, new features can be prototyped, tested, and brought to customers faster than ever.

From the other perspective, AI empowers Product Managers more and more to implement new prototypes and functionalities. So we might see a conversion of the both and Product Engineers might be a thing very quickly.

🔮 Tomorrow

With all the disruptions of AI, I believe the value of formal education is drastically declining.

Most things AI will be able to explain very easily and in an instant, whenever you need it.

Moreover, the replacement of workers by AI happens first in white collar jobs - the ones requiring more formal education. Anthropic’s CEO Dario Amodei just claimed that AI might eat half of all white collar jobs.

Anthropic CEO warns AI will destroy half of all white-collar jobs

Technology has often been bad news for blue-collar jobs. Now, white-collar workers could be facing pink slips.

mashable.com/article/anthropic-ceo-warns-white-collar-unemployment-ai

When I think about my kids and what they should do, I see two main opportunites for them, or for anyone who is young today:

1️⃣ As stated above: Learn and start your own business.

2️⃣ Don’t invest too much into formal white collar education, but rather focus on blue collar jobs. I see a clear shift towards these jobs. Robotics are behind compared to the progress we see in AI. Yet still, houses need to be built, kitchens installed, stuff constructed. And they are lacking people everywhere these days. Ultimately, I believe this will also be automated through robotics. But we are not there yet. So blue collar work might be a good alternative to high-education, soon-to-be-replaced white collar jobs. And that shift is already happening.

AI is destroying jobs. Gen Z has found a safe haven.

In lieu of student-loan debt and white-collar automation, Gen Z is pivoting to old-school, blue-collar jobs.

www.businessinsider.com/gen-z-pivot-college-degrees-work-blue-collar-jobs-trades-2025-5

🌀 The Days After Tomorrow

Upfront warning: Now it gets a bit philosophical.

In the long run, the number game goes against us. With continued efficiency gains, we will simply need drastically less people - for white collar as well as for blue collar work.

What might sound like a nightmare to many, I see as an opportunity. We are approaching a point, where for the first time in human history, we might not have to work to ensure our living. We could free ourselves from that fundamental compulsion and all the pressure, anxiety, and negative effects it comes with. We might approach a society like in Star Trek with an abundance of products and services. A world where people work not because they have to, but because they want. They work what they want and how much they want.

However, there is no straight path to such future. With what we saw as a society during Covid, like conspiracy myths spreading everywhere, populism rising worldwide, and the mechanisms of capitalism to concentrate capital in the hands of few, there is a lot of things to change in order to get to that better future.

But it’s the first time in history that we have this opportunity. Let’s grab it and prove my pessimism wrong!

❕ Footnote

There is one more thing to consider in this disruption of the job market.

As Tech companies need less and less people, there is a visible shift in the market where companies move away from seeing and treating people as their main capital. They remove flexibility they gave to their employees in the past like working from home. They reduce initiatives to foster diversity in the work force. They push harder, expecting their employees to dedicate most of their energy and time to their job only.

While this is likely routed in the insight that they will need less people, it ignores one fact: The best talent still can choose where to work. And just because AI will multiply the impact of people, the best people will still outperform less excellent ones. Even more so in these times, where you are forced to learn new skills, new AI tools, new approaches every week.

So - also, and especially in the age of AI - having outstanding talent will make a huge difference - multiplied by AI.

Thus, I believe you still need to be able to attract the best talent. And that won’t work if you switch the ways of working and leadership back to industrial times.

✅ Wrap-Up

That’s it for today! I hope you liked this somewhat different edition of the newsletter. Please let me know your thoughts - there is so much we still have to figure out!

📬 I read every piece of feedback - hit reply or click the button below!

Got a topic you want me to cover? I’m all ears.

The Dublin Zoo

💡Jan’s Knowledge Nuggets

The bonus inspirations this week:

• Book to Action: This post indicated the necessity to learn new skills fast. What did you learn from the last 5 books you read? Can you name the 3 most important take-aways from each? And even more importantly: Do you apply them? I didn’t. The excellent Sebastian Kamilli created a methodology to get actual value from the time we invest into reading books.

• The Future of Jobs Report 2025: It does not yet fully indicate the shift to blue collar work, but this is just now and my post also showed the supportive data above.

• The Agentic Research Society: Speaking of high-education white collar jobs to be replaced by AI: Sai from Google, author of Agentopedia shares how he witnessed AI agents reviewing, debating, and improving scientific papers. Mindblowing.

• Multiply your impact as a Researcher: The fabulous Nikki Anderson shared very useful AI prompts that will make your user research work much better.

• AI is making us dumber: To add some counterperspective: Research indicates that the more we rely on AI, the less critically we think. (Not sure why they picked 666 participants, though 😆)

• Product Management Festival 2025: As every year, Product Managers from around Europe will gather in Zurich in November to learn about the latest of their craft. “AI in Product Management” is one of the tracks. With my discount code, you can get 20% off regular ticket prices: DISCOUNT20JAN

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

Product Development Phases

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.

Two scenarios: A) Only Delivery respectively Delivery while doing Design, B) 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).

Hey there, product development enthusiast!

Welcome back!

In the previous issue of this newsletter, I talked about the shortcomings of OKRs and how to avoid them. But there is a simpler and - in my opinion - better alternative to prioritise and plan initiatives. So let’s look at how prioritisation could work easier and better.

Let’s dive right in!

Good Prioritisation

When I am claiming a “better” methodology - what does good look like in prioritisation?

A prioritisation method should have the following qualities:

1. Focus: It might seem obvious that a prioritisation method needs to bring clarity and focus on what to develop - and also what not to develop. However, as I explained in my post about OKRs, this is not always the case.

2. Agility: As disruptions come our way more often and faster, a prioritisation mechanism needs to be able to adapt to changes. You need to be able to react to Covid, or AI etc. - and not only in the next quarter.

3. Global: Disruptions typically mean you have to change your products substantially, maybe even your business model. That will involve many units of your organisation. But also in general, real innovation stems from overarching changes, not from small optimisations. Thus, your process needs to support initiatives across org units.

4. Lean process: Last but not least, the prioritisation process needs to be efficient and not locking up your organisation.

A Simpler Approach

To do prioritisation in a simpler way than OKRs, that fulfils all of the above criteria, you can combine two things:

1. A backlog approach

2. A product development methodology

Both are good things to have, but combined, they can form a mighty prioritisation methodology.

The backlog is where you manage all bigger product initiatives. Typically this is filled by the product management within your organisation. The product development methodology then is used to turn this backlog into a kind of funnel of initiatives.

This whole approach I like to call “Rolling Prioritisation”.

Rolling Prioritisation

The product development process is used to drive these initiatives in the backlog from early thoughts to a point where they are ready to be prioritised and implemented. Such product development methodologies could, for example, be the Working Backwards methodology invented at Amazon, Design Thinking, or the 4D methodology.

The whole process consists of 5 steps:

1. Collecting ideas: Start adding ideas to the backlog by identifying customer problems and the estimated rough benefits of solving these.

2. Refining: Then refine the initiatives by designing solution approaches (initially UX-focused, followed by technical designs), understanding necessary contributions and dependencies within your organisation, creating rough effort estimations, leading up to approximate milestone planning. This is a process during which you drive up clarity and “implementation-readiness” of your initiatives.
   If during that process, some ideas turn out to be not that impactful or too costly or less attractive for any reasons, dismiss them as early as possible.

   Similarly, decide how quickly you drive each forward, based on the early impact estimations.

   

   During the refinement of an initiative, clarity increases - from understanding the customer problem to creating a milestone plan for execution.

3. Prioritisation: While the initiatives matured, also their priority became clearer. That can and should include the by then created clarity around effort and benefits, but also necessary contributions and dependencies. For initiatives ready for execution, do a final prioritisation.

   It is sufficient to do this prioritisation anytime you are about to do the next step.

4. Starting an initiative: Start the highest prioritised initiative whenever you have the necessary capacity to do that. Typically, this happens when implementations of previous initiatives finish. But it can also be when e. g. a pandemic hits and you stop running initiatives to free up capacity for urgent new ones.

5. Delivery: The delivery itself then starts based on all the discovery and design done before and with the ensured capacities to fully deliver. This means you make a well-informed decision before you invest your precious delivery capacity. Because you ensured the availability of all needed contributors, you reduce the cost of delay that normally happens, when an initiative is nearly done, but is delayed waiting for some dependency to complete their work to go live.

   If you are lucky, delivery goes as planned in the roadmap. But life happens and one key insight that led to agile was, that you cannot plan everything in advance. You will always learn new information while executing. The benefit of this rolling prioritisation is that a delivery can take longer. Start the next highest prioritised initiative from the backlog only when the necessary capacity is available. But if some ongoing initiative takes much longer, you can also stop that initiative if the effort-benefit-ratio becomes too bad.

Ideas are collected in a backlog. They are refined through a product development process, increasing clarity and informing relative priorities. Less valuable initiatives should be dismissed. The refined one with the highest priority can be started once capacity allows.

Criticism

You might argue, that this approach resembles project management more than product management. This is a fair observation.

However, according to my experience, most organisations are missing specifically this part. Their ability to deliver meaningful big initiatives, that really make a difference, is limited by self-organising, small structures that do not perform well in coordinating overarching initiatives. Rolling Prioritisation fixes that.

But of course, you also need to bring longer-term product management into the picture. For example, if something was launched through such a big initiative, you afterwards need to spend time on iterating and improving it to e. g. optimise the product-market fit. In order to do so, only a part of all teams’ capacity should be consumed by delivering big initiatives. Other capacity needs to be reserved to work on local optimisations and ongoing product development. This is a tough balance to find, but it’s crucial.

Benefits

Using this Rolling Prioritisation fulfills the requirements towards a prioritisation method discussed above:

1. Focus is maintained by limiting parallel initiatives to available capacity.

2. Agility is given because you decide prioritisation and the actual start of the delivery at the latest possible moment in time, when you know the most.

3. The approach supports global initiatives as it coordinates dependencies and timelines of all contributions, minimising cost of delay.

4. It is lean, because it eliminates unviable ideas early, ensuring full effort is invested only in initiatives which really get delivered.

What to Watch Out For

The identification of ideas in step 1 and their refinement in step 2 are key parts of a product delivery methodology. They are actual work and thus require actual efforts. Step 1 requires user researchers and product managers, while step 2 involves designers and engineers.

I definitely recommend having people from these functions taking ownership for driving the ideas forward also before the start of delivery. E. g. a product manager to be responsible for the overall discovery and product solution design, a principal engineer for the technical solution design etc.

Wrap-Up

That’s it! This is an alternative to (and much more than) OKRs. I experienced the Rolling Prioritisation as super productive in Zalando. It makes sure that you invest your capacity into the right customer problems and that you can successfully execute and bring these initiatives to life. With basic concepts like the backlog approach, I find it simpler than OKRs, yet much more useful.

What are your thoughts on this? Have you experienced other methodologies you can share? I appreciate every single feedback I receive.

And now - I wish you a very good start into 2025 (I hope it is still legal to say that 😉)!

All the best!

Jan’s Knowledge Nuggets 💡 

In this section I share knowledge nuggets that will further help you to increase the impact of your tech organisation.

• Scott Belsky’s predictions for 2025: From DIY software replacing commercial software to companies centered around data and computation, requiring humans only as stewards.

• Financial education for tech leaders: In this training, the amazing Simonetta Batteiger provides valuable commercial skills to understand value for a company, balance sheets, and P&L. Essential skills for talking to your CFO.

• Free workshop on how to build a second brain: The fabulous Sebastian Kamilli will do a free workshop on Wednesday how to leverage AI to step up your learning and creative process. How to sign up is described at the bottom of this post.

Hey there, product development enthusiast!

Welcome to the first edition of the Tech Impact Uplift newsletter! Just in time for some pleasurable read over the holidays. I am super thankful that you subscribed and are here with me. 😊 

The first topic we discuss will be how to prioritise.

Let’s dive right in!

Why is Prioritisation Important?

Ideas are cheap and there is always an abundance of them. But the most important bottleneck in product development is our capacity to work on these ideas.

Therefore, we need to be very mindful about what we spend this capacity on.

There are several prioritisation methodologies out there, but one is by far the most (over-) hyped: Objectives and Key Results (OKRs).

Hype alert

The OKR Methodology

OKRs consist of two main concepts:

• Objectives: These should be aspirational goals like “We expand into a new customer segment”.

• Key Results: Belong to an Objective and should be measurable steps to reach these goals, like “We acquire X new customers from that segment, who use our product A at least 3 times.”

These Objectives and Key Results should exist on every organisational level of the company and cascade down. I. e. company OKRs should be supported by department OKRs, which in turn should be paid into by unit OKRs.

OKR Concepts

The creation of OKRs should ideally be a mixture of a top-down approach, where overarching business direction is provided, and bottom-up input, which should provide ideas that support this direction.

Process

OKRs are defined and worked on for a pre-defined timeframe, typically 3 months. The progress is ideally reviewed during the cycle, but latest at the end. Based on that, the next cycle is planned with renewed OKRs.

Through that, goals should be clear, results measurable, and teams aligned on common goals. What could go wrong?

Shortcomings of OKRs

There are a few things that I have seen over and over going wrong with OKRs.

Too Costly

Planning OKRs can be a logistical nightmare.

As organisational units plan towards overarching goals, e.g. "We expand into a new customer segment", each unit can have very different ideas on how to support that. In any non-trivial organisation, they will most likely need support from others.

So before each cycle, all units spend tons of time preparing, pitching, and aligning their ideas with others. (This mostly happens when you plan for projects rather than for goals, which you shouldn’t.) I have seen cases where the whole company was busy for two weeks just preparing the next OKRs.

Upfront Alignment: A Logistical Nightmare

No Focus

What I have also seen a lot is focus getting lost during the OKR cycle.

Let’s imagine a unit has defined own OKRs and works on those. But other orgs might need their support for their OKRs. So they approach them for help, very often with the argument “But it’s in the OKRs - you need to help!”.

The bigger the company, the more such dependencies, the more requests on each organisational unit and: the less focus!

No Focus

Likewise, planning for 6 Objectives with 3-5 Key Results each is just too much.

One example I’ve seen was a company, where all walls of one room were completely covered by OKRs of all teams. Do you think this provides focus?

Not Agile

Theoretically, OKRs look very agile:

Allegedly Agile

But if you think about it, they are not.

First, which initiative takes 3 months? Rarely any do.

What I have seen happen a lot, is that after the 3 months, the initiatives got dropped. Often, because another stakeholder did not get their request added to the OKRs in the previous cycle, so for the next “we really need to do something for them”.

The result: Products are not optimised, accordingly, product-market fit is not reached. Long-term innovation is hampered in favor of short-term thinking (or project thinking vs. product thinking).

This might look agile, but is de-facto a series of mini-waterfalls of fixed duration.

Series of Mini-Waterfalls

How to Do Better

Of course, you can do better even with OKRs. Here are my tips on that. 🚀 

1. Strictly limit the amount of objectives and key results that each unit should define from the beginning (3 sounds reasonable but depends on many factors).

2. Have somebody own each of them from the beginning to coordinate dependencies early on.

3. Plan for max. 60% of an org’s capacity to leave room for operational business, unplanned support, unplanned complexity, maintenance etc.

4. Don’t plan projects, plan goals!

5. Objectives should be long-lasting and stable over several cycles until they are reached (or consciously deprioritised).

What OKRs Cannot Do

Now we talked about how to do OKRs in a better way.

Yet, I often experience severe misconceptions about what OKRs can do. So let me clarify this as well.

OKRs do not replace:

• a strategy

• a product development process

• a design and planning process

• a conflict resolution process

Also, by their nature, they cannot provide the refinement of a topic or the solution design. OKRs are about the “What”, not the “How”. The solution design can only follow later.

Because of this, OKRs also cannot provide alignment between teams upfront. Why not? As the solution design only comes later, the dependencies of that solution will also only become known by then.

Wrap-Up

I hope you got a good feeling about what all can go wrong with using OKRs. This does not mean you should not use them at all.

You need to prioritise as otherwise your organisation will go into all different directions and you will not spend your delivery capacity efficiently. The tips provided should help with that.

But there is alternatives to OKRs, which I will cover in the next newsletter. So stay tuned!

I am keen to hear your experience with OKRs or your thoughts on this newsletter.

And now - I wish you Happy Holidays and a good start into the New Year. 🎄I hope you’ll have a relaxing time with your loved ones, as I am sure 2025 will come soon enough with its challenges.

Jan’s Knowledge Nuggets 💡 

In this section I share knowledge nuggets that will further help you to increase the impact of your tech organisation.

• Free Webinar “The Strategy Habit”: Markus Andrezak is a master when it comes to strategy. On January 9th he will share his pragmatic approach to do strategy in a practical and impactful way. I already registered and look forward to the session.

• 9 key take-aways on User Research: The wonderful Nikki Anderson is a legend in the field of User Research. She condensed her 10,000 hours of practical experience into 9 key lessons everyone in product development should be aware of.

• Free courses to learn AI: Paul Storm shared a valuable overview of free AI learning courses by Harvard, Google, OpenAI and many more. From prompt engineering to programming to ethics of AI.