Executive Corner: “Solve your Problem in the Model”
Early success with AI comes quickly. Reliable results do not. The reason is usually the same: people throw thoughts into a prompt, close their eyes, and hope. If the result is poor — try again. And again.
That is not a strategy. Not an AI problem. But a thinking problem.
Interestingly, it is the same thinking (or rather thinking-avoidance) problem I have been observing in product development for years.
Iterating Instead of Thinking — an Expensive Habit
Ask people in your company why they work “agile.” A common answer is:
“Because requirements constantly change.”
I have my doubts — at least in our industry.
Intended purpose, stakeholder requirements, regulatory frameworks, patient safety: these do not fluctuate from sprint to sprint. In many cases, iteration is therefore not compensating for changing requirements. It is compensating for insufficient problem analysis.
One symptom of this is the widespread use of user stories. The template “As a [role], I want [function], so that [benefit]” mixes concepts that actually require entirely different types of thinking:
- Intended purpose: the [benefit]
- Stakeholder requirement: the [role] and its need
- Product specification: the [function]
Three distinct levels — blended into a single sentence. That is not precision. It is conceptual soup. And it is the perfect breeding ground for the endless iterations that are later glorified as “agility.”
And when version n + 1 “improves” something that could already have been done correctly in version n, people celebrate it as progress.
It is not. It is a documented failure.
[I hope this does not trigger too much of a shitstorm. Better take it as an invitation to think.]
What I Had to Learn Myself
When I was a junior developer, my boss appreciated me because I often delivered a first solution within hours. What he did not see: the architectural chaos in my backend code.
Then I took over a large-scale project, and the implementation partner (IBM) made one thing clear: “If we see you coding at the start of the project, we’re out.”
And then came the sentence that changed everything: “Christian, solve your problem in the model.”
So we modeled the architecture. For months. My boss became impatient — no quick visible results.
But once the model was stable, we were able to generate several hundred thousand lines of code. The architecture remained robust for many years.
Those months of thinking were not wasted time. They were the actual value creation.
Frontloading ≠ Waterfall
Do not worry — this is not an argument for a waterfall process. Because frontloading does not mean predicting everything upfront.
It means: think as deeply as possible before you start building.
And that thinking matters equally at every level:
- Intended purpose: What business or medical problem are we actually solving — and for whom?
- Stakeholder requirements: What do users truly need?
By the way: Customer Requirement ≠ User Requirement!
- Product requirements: What must the product accomplish as a black box?
- Architecture/specification: How do we design the internal structure so that the system actually holds together?
Anyone who mixes or skips these levels creates exactly the ambiguity that later causes endless iterations.
Does this mean you should never iterate? Of course not. But iterations should be targeted experiments designed to answer a concrete question:
- Does this UI specification satisfy the user requirements?
- Does this architecture achieve the required performance goals?
Those are good reasons to iterate. Iterating across the entire development process because the initial problem analysis was skipped is not.
What this means for you
- Do not celebrate the number of sprints. Celebrate the quality of the problem analysis. For every “improvement,” ask: Could we have known this earlier?
- Demand clear mental models. For example: Can your teams reliably distinguish between intended purpose, stakeholder requirements, and product specifications? If not: invest there — not in yet another Scrum training.
- Apply the same principle to AI. Before writing the prompt, ask: What exactly is my goal? What are the acceptance criteria? What knowledge does the model need in order to understand my problem?
Those who master this often need one attempt instead of ten.
In a world overflowing with tools, the most valuable skill remains the oldest one: thinking.
