Greater clarity, speed and impact: the order matters

Doing more at the same time doesn’t mean working faster

An example from my own experience: at a major automotive supplier, specialists were working on four to five projects simultaneously. Every day began with a juggling act: status calls, emails, scheduling meetings. There was hardly any time left for actual work, and the regular project meetings often focused less on progress than on bringing everyone ‘up to speed’ again. Meanwhile, management wondered about ‘lack of productivity’, even though staff had long since exceeded their limits.

This is the parallelisation trap in its purest form. The more projects that draw on the same limited capacity, the more frequently staff have to switch between tasks. Coordination increases, waiting times arise and the lead time for individual projects is extended. In addition, the buffer that teams need to be able to react to disruptions or new requirements disappears. It’s like a congested motorway where nobody can swerve out of the way anymore. Nevertheless, product development is often planned as if all available capacity could be utilised to full capacity at all times.

My experience: if there is one organisational ailment that can be found almost everywhere, it is the loss of focus. Instead of driving forward a few projects with determination, dozens run in parallel. The tricky thing about this is that everyone feels constantly busy, the organisation appears active, but hardly anything is consistently brought to fruition. Anyone who calls for ‘more features at the same time’ is therefore often asking for the opposite of speed.

Clarity begins with a ‘no’

I admit: a plea to say ‘no’ might sound a bit odd at first in a text about pace. But that is precisely what clarity means in practice. Every additional initiative you launch takes up capacity that other projects are then lacking. The cost is therefore also the value you fail to realise because you’ve taken on too much.

A scenario you’re probably familiar with: three issues are on the table, all urgent. The product owner says: “Basically, everything is important.” Someone asks: “But what do we do first?” Silence. Then the discussion begins. Fifteen minutes later, we’re no further forward, but deeper in the thicket. In the end, it’s not clarity that decides, but volume. Or exhaustion.

What’s left are lists with priorities 1a, 1b and 1c, where in the end everything ends up happening at the same time anyway. Real prioritisation means: one thing comes first, another later. This is uncomfortable because it makes decisions visible and rules out options. And it’s not a question of tools. I’m asked surprisingly often about the best prioritisation tool. My counter-question is almost always: ‘What exactly are you trying to achieve?’ Customer benefit, business value, strategic contribution or cost of delay? Until that’s clarified, even the best tool won’t help.

Clarity requires decision-making rules

Knowing which projects take priority is one thing. It is just as important to know who is authorised to make those decisions. Without this clarity, even day-to-day decisions end up being referred to the next level of management or are postponed through additional rounds of consultation.

You can recognise unclear decision-making logic by patterns that will probably sound familiar to you:

• Decisions are reflexively escalated upwards, even though the context and expertise lie within the team.
• Meetings end with “We’ll take that on board” rather than with a designated person, a next step and a deadline.
• “We need more information” becomes the standard response and sometimes masks uncertainty or a fear of taking responsibility.

These patterns do not necessarily indicate underlying cultural problems. Often, there is simply a lack of clear decision-making rules: Who decides? How are decisions made? And when? If teams do not know whether they are authorised to make decisions, they wait for approval or, as a precaution, seek confirmation from multiple sources.

A simple preliminary check can help here: How costly would a mistake be, and how easily could it be reversed? If a decision is easily reversible and the risk is manageable, it should be made quickly and as close to the team as possible. In contrast, far-reaching decisions that are difficult to correct require more careful consideration. Problems arise when the same decision-making process is applied to both: minor issues are blown out of proportion, whilst major ones are treated in an overly simplistic manner.

A look at flow efficiency illustrates what this has to do with speed. It describes the ratio between active processing time and the total lead time of a project. Work can remain pending for days or weeks, even though its actual processing takes only a few hours. The cause often lies in waiting times, handover processes or unresolved decisions.

Anyone wishing to work faster should therefore investigate where work is left lying and why. Time is lost not only because decisions are needed, but also because it remains unclear who prepares them and how reliably they are made. Where these questions are clarified, the lead time can be significantly reduced without anyone having to work faster.

Figure: Why clarity comes before speed

Impact is felt by the customer, not in the backlog

Speed alone does not equal impact. A team can deliver quickly and still develop solutions that miss the mark. The difference lies in output and outcome: output is the delivery of a feature. Outcome asks: has it really made a difference?

The problem is rarely the method, but rather a lack of contact. Teams spend weeks or months developing ‘in a vacuum’; reviews are mainly internal, and they receive hardly any genuine feedback from users. We talk a lot about customers, but not enough with them. Then we discuss solutions, even though we haven’t even agreed on the problem, the target audience or the benefits. This is one of the reasons why backlogs grow, but clarity does not.

You don’t need a research programme for this. Even the smallest experiment that enables a decision is enough: a conversation, a prototype or a small pilot. Direct customer contact is part of product development, even with highly specialised target groups. I recall projects where we developed products for air traffic controllers and had former members of this profession on the team as consultants. This was an enormous asset in terms of product relevance.

Your role as a manager is to facilitate this learning. If you regularly check what impact your product is having on customers, you can take corrective action sooner and need to micromanage individual work steps less. One simple tool is reviews and retrospectives, for example every two weeks. These meetings do not need to be long, but they need to take two perspectives. The review looks outwards: what have we learnt from customers and stakeholders? The retrospective looks inwards: what will we change in the next iteration?

Clarity, however, is not a state that an organisation achieves once and then ticks off its list. What teams learn through contact with customers may confirm or challenge previous assumptions. Sometimes it turns out that a feature that was originally considered important brings little benefit, or that another problem is more urgent. In such cases, priorities must be adjusted, even if work has already been invested.

This is how the circle is completed: clarity on priorities and decisions reduces unnecessary waiting times. This creates momentum for a few, carefully selected projects. However, whether this results in an impact only becomes apparent with the customer. Learning without the willingness to draw conclusions from it remains merely an exercise.

What AI changes and what it doesn’t

AI can significantly speed up individual development stages. However, this does not necessarily mean that products are completed more quickly or deliver greater value. As implementation becomes easier, other bottlenecks become more apparent: understanding customers, prioritisation and decision-making.

The DORA Report 2025 describes AI accordingly as an amplifier of existing organisational strengths and weaknesses. The study shows a positive correlation between AI usage and throughput in software delivery, but also a higher level of instability. Faster development therefore by no means automatically leads to better results. [1]

Added to this is a second effect that is often underestimated: something built quickly is by no means cheap to own. Anyone who uses AI to develop lots of features that nobody needs increases the complexity of their product. Every additional feature must be tested, maintained and taken into account when changes are made. AI can help with these tasks, but it does not relieve the company of responsibility for the resulting complexity. Every unnecessary feature is a ‘no’ that was never spoken.

The faster pace of implementation therefore makes it all the more important to make conscious decisions about which ideas to pursue. When teams can develop solutions more quickly, the risk of turning untested assumptions into products more rapidly also increases. A poor understanding of customers is not improved by additional development capacity.

The crucial question is therefore not: ‘Should we use AI?’ What matters more is whether the organisation has a working model in which priorities are clarified, decisions are made reliably and results are assessed against customer benefit. Where there is clarity, AI acts as an amplifier. Where it is lacking, the increased speed can exacerbate existing problems.

Practical tip: Four questions to ask before the next call to speed things up

Before you say ‘faster’ next time, it’s worth taking a moment to check:

1. What is your team currently working on, and who actually made the most recent decision about this? If you can’t answer this in a single sentence, your bottleneck might lie in prioritisation.

2. What was the last thing you consciously turned down? If nothing springs to mind, you may not be defending priorities but simply managing a growing list.

3. Which decisions still end up with you, even though the team has the expertise? Each of these is a concrete starting point for shifting responsibility to where it is best placed.

4. When was the last time you spoke directly with one of your customers about their problem, rather than your solution? If it’s been a while, it’s worth checking what assumptions your current product development is based on.

None of these questions requires a new tool or an additional round of consultation. They require decisions that are often put off in day-to-day work. If you want to pick up the pace, you should therefore start with the next prioritisation decision and assess which work actually deserves priority.

Notes:

If you’re interested in greater clarity, speed and effectiveness, it’s worth taking a look at the website of Die Umsetzer.

Christoph Schmiedinger has published a book well worth reading: Das Ende der Innovationsblockade – Mit wirksamen Strukturen und Prozessen zu erfolgreichen Produkten.

[1] DORA Report: State of AI-assisted Software Development

Would you like to support Christoph Schmiedinger and discuss greater clarity, speed, effectiveness and, consequently, better outcomes? Then share this post on social media or within your organisation.