"We need an AI chatbot for customer service." "We want to analyze our data with AI." "We need a dashboard." These are the kinds of briefs we hear regularly. The person asking already has a solution in mind before the actual problem has been named. That's not a criticism. It's a deeply human pattern. And it's one of the most expensive mistakes in technology projects.

The Brief Sounds Clear. The Problem Isn't.

In software development, there's a well-known anti-pattern called the XY Problem. Someone has problem X, but instead of describing X, they ask for help with Y, a solution they've already chosen. The helper tries to fix Y, both sides get frustrated, and the real problem never gets addressed.

This happens constantly in business. A company approaches a consultant or vendor and says: "We need a chatbot." What they actually have is a knowledge management gap: an unstructured FAQ, no process documentation, inconsistent answers depending on who picks up the phone. A chatbot layered on top of that chaos would just deliver wrong answers faster.

The brief describes a solution. The problem is still hiding underneath.

Why Initial Briefs Almost Always Miss the Mark

This isn't because people are careless. There are structural reasons why the first formulation of a problem is rarely the right one.

People describe problems from their own vantage point, not from the user's. A manager sees "slow reporting." The people doing the work see a data entry process that requires them to copy numbers between three systems. The reporting isn't slow. The inputs are broken.

Internal politics shape how problems get framed. "The CEO read about it in a magazine" is a surprisingly common origin story for technology projects. The solution arrives before the problem has been articulated, and questioning it feels like questioning the person who proposed it.

Technology hype distorts the search for solutions. When every headline says "AI," every problem starts looking like it needs AI. As we explored in our first post, this pressure is real: 34% of Swiss SMEs are already integrating AI, but most haven't established the process clarity to know where it actually fits.

Non-technical people translate fuzzy problems into concrete technology terms. "We need AI for quality control" sounds specific, but it skips the entire question of what's actually going wrong, where, and why. The translation from business pain to technology label loses most of the information that matters.

This Is Not a New Insight. It's a Well-Documented One.

The pattern of solving the wrong problem has been studied for decades, across multiple disciplines. The evidence is remarkably consistent.

A Harvard Business Review study surveyed 106 C-suite executives across 91 companies in 17 countries. 85% agreed that their organizations were bad at problem diagnosis. 87% said this carried significant costs. The researchers concluded that "managers tend to switch quickly into solution mode without checking whether they really understand the problem."

The British Design Council studied how companies like Sony, Starbucks, and LEGO actually develop products. They found that every successful design process follows the same shape: a period of expanding your understanding of the problem, followed by a period of narrowing it down, before you ever start building solutions. They called it the Double Diamond. The first diamond is the problem space. Most teams, under pressure from stakeholders who arrive with a solution already in mind, skip it entirely.

The Project Management Institute found that the top-rated reason for project failure is that "the project was not adequately defined at the beginning." 66% of organizations report frequent project delays caused by unclear requirements. And the Standish Group's CHAOS research consistently shows that incomplete requirements are the single largest factor in project impairment.

Toyota's production system gave us the Five Whys technique: when you encounter a problem, ask "why?" five times before acting. Not because the first answer is wrong, but because it's almost always superficial. The method exists specifically because Toyota's engineers kept discovering that what looked like the problem was actually a symptom of something deeper.

Gerald Weinberg put it best in his classic Are Your Lights On?: "The fledgling problem solver invariably rushes in with solutions before taking time to define the problem being solved. Even experienced solvers, when subjected to social pressure, yield to this demand for haste."

Different fields, same finding: the most common failure mode isn't building badly. It's building the wrong thing.

The Hidden Cost of "Just Build It"

When you take a brief at face value and go straight to implementation, the costs compound quickly.

The obvious cost is budget. A solution built for the wrong problem doesn't solve the real one. The money is spent, but the pain remains. For an SME, where budgets for technology experiments are small and decisions are often made by one or two people, one failed project can close the door on future initiatives entirely.

The less obvious cost is trust. When a team sees a technology project fail, they don't blame the problem definition. They blame the technology. "We tried AI and it didn't work." The next time someone proposes an AI project (even a well-defined one), they'll face a wall of skepticism built from a previous failure that was never about the technology in the first place.

And there's an opportunity cost. The time spent building the wrong thing is time not spent understanding the real problem, which often has a simpler, cheaper solution. A company that spends six months building a chatbot might have solved its actual problem in two weeks with a restructured FAQ and a shared document.

Three Patterns We See Again and Again

These are composites, not client stories. But they reflect patterns that come up constantly in conversations with SME leaders.

"We need an AI chatbot for customer support."
What's actually going on: the knowledge base is a mess. There's no shared documentation of common issues. Different support staff give different answers to the same question. A chatbot trained on this data would confidently deliver inconsistent, sometimes wrong information. The first step isn't AI. It's organizing what the team already knows.

"We want to use AI to analyze our data."
What's actually going on: there's no shared data definition. Sales calls it "revenue." Finance calls it "bookings." Operations tracks a third number. Before any analysis can happen (AI-powered or otherwise), the company needs to agree on what its own terms mean. This is a governance problem, not a technology problem.

"We need AI for quality control."
What's actually going on: the data capture process is broken. Inspections are logged inconsistently, sometimes on paper, sometimes in a spreadsheet, sometimes not at all. AI needs clean, structured input data. The real bottleneck isn't analysis. It's getting reliable data into the system in the first place.

In each case, the stated need was technology. The actual need was clarity. And the right first step was not building, but understanding.

What Works Instead: Understanding Before Building

The alternative to jumping into solutions isn't paralysis. It's a short, structured phase of actually understanding the problem before committing resources to solving it.

In design thinking, this is the first diamond: discover and define before you develop and deliver. In consulting, it's called a discovery phase. At Toyota, it starts with the Five Whys. The label doesn't matter. The principle is the same: invest a small amount of time upfront to avoid investing a large amount of money in the wrong direction.

This is why our Insight Method starts with Listen, not with "build." We talk to the people doing the actual work, not just the person who wrote the brief. We map what's really happening, not what the org chart says should be happening. And we ask the uncomfortable questions early, when changing direction is cheap, rather than late, when it's expensive.

A discovery phase is not a delay. It's the part of the project that prevents the real delays: the rework, the pivot, the "actually, we need something completely different" conversation three months in.

Five Questions to Ask Before Any Technology Project

You don't need a consultant for this. Before greenlighting your next project, sit down with your team and answer these honestly:

1. Have we validated the problem, or just the solution?
Can you describe the problem without mentioning any technology? If the brief says "we need a chatbot," what's the problem the chatbot is supposed to solve? Can three different people in your company describe that problem the same way?

2. Who defined the problem, and who actually experiences it?
If the person who wrote the brief isn't the person living with the problem every day, there's a gap. Talk to the people doing the work. Their description of the pain will be different, and more useful, than the brief.

3. What happens if we do nothing?
This isn't an argument for inaction. It's a calibration question. If the answer is "nothing much changes," the problem might not be urgent enough to warrant a technology investment. If the answer is "we keep losing 10 hours a week to manual data entry," now you have something concrete to solve.

4. What have we already tried, and why didn't it work?
Most problems aren't new. Understanding previous attempts (and why they failed) prevents you from repeating them with fancier tools.

5. What should be different after implementation?
Not "what should be built," but "what should change." If you can't describe the desired outcome in measurable terms, you can't evaluate whether any solution (AI or otherwise) actually worked.

If your team can answer all five clearly and consistently, you're probably ready to start building. If not, the answers themselves are the first deliverable.

Our AI Reality Checklist covers similar ground with 10 questions specifically designed for SMEs evaluating AI. It takes about 15 minutes and it's free. It won't tell you what to build, but it will help you figure out whether you're asking the right question.

The Bottom Line

The most valuable first step in any technology project isn't implementation. It's making sure you understand the problem well enough to know what "solved" looks like.

This isn't a new idea. Design thinking has been teaching it since the 1960s. Toyota formalized it in the 1950s. Harvard Business Review has been publishing evidence for it for over a decade. And yet, the pressure to "just build something" remains overwhelming, especially when AI is involved.

The companies that get real value from technology aren't the ones that move fastest. They're the ones that pause long enough to make sure they're moving in the right direction.

That pause is not wasted time. It's the highest-leverage investment in any project.

"Wir brauchen einen KI-Chatbot für den Kundenservice." "Wir wollen unsere Daten mit KI analysieren." "Wir brauchen ein Dashboard." Das sind die Art von Aufträgen, die wir regelmässig hören. Die Person, die fragt, hat bereits eine Lösung im Kopf, bevor das eigentliche Problem benannt wurde. Das ist kein Vorwurf. Es ist ein zutiefst menschliches Muster. Und es ist einer der teuersten Fehler in Technologieprojekten.

Der Auftrag klingt klar. Das Problem ist es nicht.

In der Softwareentwicklung gibt es ein bekanntes Anti-Pattern namens XY-Problem. Jemand hat Problem X, beschreibt aber statt X die Lösung Y, die er bereits gewählt hat. Der Helfer versucht Y zu lösen, beide Seiten werden frustriert, und das eigentliche Problem wird nie adressiert.

Das passiert ständig im Business. Ein Unternehmen kommt zu einem Berater und sagt: "Wir brauchen einen Chatbot." Was es tatsächlich hat, ist eine Lücke im Wissensmanagement: ein unstrukturierter FAQ-Bereich, keine Prozessdokumentation, unterschiedliche Antworten je nachdem, wer ans Telefon geht. Ein Chatbot, der auf dieses Chaos aufgesetzt wird, würde nur falsche Antworten schneller liefern.

Der Auftrag beschreibt eine Lösung. Das Problem versteckt sich noch darunter.

Warum der initiale Brief fast immer daneben liegt

Das liegt nicht daran, dass Menschen nachlässig sind. Es gibt strukturelle Gründe, warum die erste Formulierung eines Problems selten die richtige ist.

Menschen beschreiben Probleme aus ihrer eigenen Perspektive, nicht aus der der Nutzer. Ein Manager sieht "langsames Reporting." Die Leute, die die Arbeit machen, sehen einen Dateneingabeprozess, bei dem sie Zahlen zwischen drei Systemen kopieren müssen. Das Reporting ist nicht langsam. Die Eingaben sind kaputt.

Interne Politik beeinflusst, wie Probleme formuliert werden. "Der CEO hat es in einem Artikel gelesen" ist eine überraschend häufige Entstehungsgeschichte für Technologieprojekte. Die Lösung kommt, bevor das Problem formuliert wurde, und sie zu hinterfragen fühlt sich an, als würde man die Person hinterfragen, die sie vorgeschlagen hat.

Der Technologie-Hype verzerrt die Lösungssuche. Wenn jede Schlagzeile "KI" sagt, sieht jedes Problem so aus, als bräuchte es KI. Wie wir in unserem ersten Beitrag untersucht haben, ist dieser Druck real: 34% der Schweizer KMU integrieren bereits KI, aber die meisten haben nicht die Prozessklarheit geschaffen, um zu wissen, wo sie wirklich passt.

Fachfremde übersetzen unscharfe Probleme in konkretes Technologie-Vokabular. "Wir brauchen KI für die Qualitätskontrolle" klingt spezifisch, überspringt aber die gesamte Frage, was tatsächlich schiefläuft, wo und warum. Die Übersetzung von Geschäftsschmerz zu Technologie-Label verliert die meisten Informationen, die zählen.

Das ist keine neue Erkenntnis. Es ist eine gut dokumentierte.

Das Muster, das falsche Problem zu lösen, wird seit Jahrzehnten erforscht, quer durch verschiedene Disziplinen. Die Befunde sind bemerkenswert konsistent.

Eine Studie der Harvard Business Review befragte 106 C-Suite-Führungskräfte aus 91 Unternehmen in 17 Ländern. 85% stimmten zu, dass ihre Organisationen schlecht in der Problemdiagnose sind. 87% sagten, das verursache erhebliche Kosten. Die Forscher folgerten: "Manager neigen dazu, schnell in den Lösungsmodus zu wechseln, ohne zu prüfen, ob sie das Problem wirklich verstehen."

Der British Design Council untersuchte, wie Unternehmen wie Sony, Starbucks und LEGO tatsächlich Produkte entwickeln. Sie fanden heraus, dass jeder erfolgreiche Designprozess der gleichen Form folgt: eine Phase, in der man das Verständnis des Problems erweitert, gefolgt von einer Phase der Eingrenzung, bevor man überhaupt anfängt, Lösungen zu bauen. Sie nannten es den Double Diamond. Der erste Diamant ist der Problemraum. Die meisten Teams, unter dem Druck von Stakeholdern, die bereits mit einer Lösung ankommen, überspringen ihn komplett.

Das Project Management Institute fand heraus, dass der meistgenannte Grund für Projektscheitern ist, dass "das Projekt zu Beginn nicht adäquat definiert wurde." 66% der Organisationen berichten von häufigen Projektverzögerungen durch unklare Anforderungen. Und die CHAOS-Forschung der Standish Group zeigt konsistent, dass unvollständige Anforderungen der grösste Einzelfaktor für Projektprobleme sind.

Toyotas Produktionssystem gab uns die Five-Whys-Technik: Wenn man auf ein Problem stösst, fünfmal "Warum?" fragen, bevor man handelt. Nicht weil die erste Antwort falsch ist, sondern weil sie fast immer oberflächlich ist. Die Methode existiert genau deshalb, weil Toyotas Ingenieure immer wieder feststellten, dass das, was wie das Problem aussah, tatsächlich ein Symptom von etwas Tieferem war.

Gerald Weinberg brachte es in seinem Klassiker Are Your Lights On? auf den Punkt: "Der unerfahrene Problemlöser stürzt sich unweigerlich auf Lösungen, bevor er sich die Zeit nimmt, das zu lösende Problem zu definieren. Selbst erfahrene Löser geben unter sozialem Druck diesem Drang zur Eile nach."

Verschiedene Felder, gleicher Befund: Der häufigste Fehler ist nicht, schlecht zu bauen. Er ist, das Falsche zu bauen.

Die versteckten Kosten von "Einfach bauen"

Wenn man einen Auftrag wörtlich nimmt und direkt in die Umsetzung geht, summieren sich die Kosten schnell.

Der offensichtliche Preis ist das Budget. Eine Lösung, die für das falsche Problem gebaut wurde, löst das echte nicht. Das Geld ist ausgegeben, aber der Schmerz bleibt. Für ein KMU, wo Budgets für Technologie-Experimente klein sind und Entscheidungen oft von ein oder zwei Personen getroffen werden, kann ein gescheitertes Projekt die Tür für zukünftige Initiativen komplett schliessen.

Der weniger offensichtliche Preis ist Vertrauen. Wenn ein Team ein Technologieprojekt scheitern sieht, gibt es nicht der Problemdefinition die Schuld. Es gibt der Technologie die Schuld. "Wir haben KI ausprobiert und es hat nicht funktioniert." Beim nächsten Mal, wenn jemand ein KI-Projekt vorschlägt (selbst ein gut definiertes), trifft er auf eine Mauer aus Skepsis, die von einem früheren Scheitern stammt, bei dem es nie um die Technologie ging.

Und es gibt Opportunitätskosten. Die Zeit, die man mit dem Bau des Falschen verbringt, ist Zeit, die nicht in das Verständnis des echten Problems fliesst, das oft eine einfachere, günstigere Lösung hat. Ein Unternehmen, das sechs Monate einen Chatbot baut, hätte sein tatsächliches Problem vielleicht in zwei Wochen gelöst: mit einem umstrukturierten FAQ und einem geteilten Dokument.

Drei Muster, die wir immer wieder sehen

Das sind keine Kundengeschichten, sondern zusammengesetzte Muster. Aber sie spiegeln wider, was in Gesprächen mit KMU-Führungskräften ständig auftaucht.

"Wir brauchen einen KI-Chatbot für den Kundensupport."
Was tatsächlich los ist: Die Wissensbasis ist ein Chaos. Es gibt keine gemeinsame Dokumentation häufiger Probleme. Verschiedene Support-Mitarbeitende geben unterschiedliche Antworten auf dieselbe Frage. Ein Chatbot, der auf diesen Daten trainiert wird, würde selbstbewusst inkonsistente, manchmal falsche Informationen liefern. Der erste Schritt ist nicht KI. Es ist, zu ordnen, was das Team bereits weiss.

"Wir wollen unsere Daten mit KI analysieren."
Was tatsächlich los ist: Es gibt keine gemeinsame Datendefinition. Der Vertrieb nennt es "Umsatz." Die Buchhaltung nennt es "Buchungen." Der Betrieb trackt eine dritte Zahl. Bevor irgendeine Analyse stattfinden kann (KI-gestützt oder nicht), muss das Unternehmen sich darauf einigen, was seine eigenen Begriffe bedeuten. Das ist ein Governance-Problem, kein Technologieproblem.

"Wir brauchen KI für die Qualitätskontrolle."
Was tatsächlich los ist: Der Datenerfassungsprozess ist kaputt. Inspektionen werden inkonsistent protokolliert, manchmal auf Papier, manchmal in einer Tabelle, manchmal gar nicht. KI braucht saubere, strukturierte Eingabedaten. Der echte Engpass ist nicht die Analyse. Es ist, verlässliche Daten überhaupt erst ins System zu bekommen.

In jedem Fall war der formulierte Bedarf Technologie. Der tatsächliche Bedarf war Klarheit. Und der richtige erste Schritt war nicht Bauen, sondern Verstehen.

Was stattdessen funktioniert: Verstehen vor Bauen

Die Alternative zum Sprung in Lösungen ist keine Paralyse. Es ist eine kurze, strukturierte Phase, in der man das Problem tatsächlich versteht, bevor man Ressourcen in seine Lösung investiert.

Im Design Thinking ist das der erste Diamant: Discover und Define, bevor man Develop und Deliver macht. In der Beratung heisst es Discovery Phase. Bei Toyota beginnt es mit den Five Whys. Das Label ist egal. Das Prinzip ist dasselbe: eine kleine Investition an Zeit am Anfang, um eine grosse Fehlinvestition an Geld zu vermeiden.

Deshalb beginnt unsere Insight Method mit Listen, nicht mit "Bauen." Wir sprechen mit den Leuten, die die eigentliche Arbeit machen, nicht nur mit der Person, die den Auftrag geschrieben hat. Wir kartieren, was wirklich passiert, nicht was das Organigramm sagt, das passieren sollte. Und wir stellen die unbequemen Fragen früh, wenn eine Kursänderung günstig ist, statt spät, wenn sie teuer ist.

Eine Discovery Phase ist keine Verzögerung. Sie ist der Teil des Projekts, der die echten Verzögerungen verhindert: die Nacharbeit, den Pivot, das "eigentlich brauchen wir etwas komplett anderes"-Gespräch drei Monate nach Projektstart.

Fünf Fragen vor jedem Technologieprojekt

Dafür braucht man keinen Berater. Bevor Sie Ihr nächstes Projekt freigeben, setzen Sie sich mit Ihrem Team zusammen und beantworten Sie diese Fragen ehrlich:

1. Haben wir das Problem validiert oder nur die Lösung?
Können Sie das Problem beschreiben, ohne eine Technologie zu erwähnen? Wenn im Auftrag "Wir brauchen einen Chatbot" steht: Welches Problem soll der Chatbot lösen? Können drei verschiedene Personen in Ihrem Unternehmen dieses Problem gleich beschreiben?

2. Wer hat das Problem definiert, und wer erlebt es tatsächlich?
Wenn die Person, die den Auftrag geschrieben hat, nicht die Person ist, die täglich mit dem Problem lebt, gibt es eine Lücke. Sprechen Sie mit den Leuten, die die Arbeit machen. Ihre Beschreibung des Schmerzes wird anders sein, und nützlicher, als der Auftrag.

3. Was passiert, wenn wir nichts tun?
Das ist kein Argument für Untätigkeit. Es ist eine Kalibrierungsfrage. Wenn die Antwort "nicht viel" ist, ist das Problem vielleicht nicht dringend genug für eine Technologie-Investition. Wenn die Antwort ist "Wir verlieren weiterhin 10 Stunden pro Woche durch manuelle Dateneingabe," haben Sie etwas Konkretes zu lösen.

4. Was haben wir schon versucht, und warum hat es nicht funktioniert?
Die meisten Probleme sind nicht neu. Frühere Versuche zu verstehen (und warum sie gescheitert sind) verhindert, dass man sie mit schickeren Werkzeugen wiederholt.

5. Was soll nach der Implementierung anders sein?
Nicht "was soll gebaut werden," sondern "was soll sich ändern." Wenn Sie das gewünschte Ergebnis nicht in messbaren Begriffen beschreiben können, können Sie auch nicht beurteilen, ob irgendeine Lösung (KI oder nicht) tatsächlich funktioniert hat.

Wenn Ihr Team alle fünf Fragen klar und konsistent beantworten kann, sind Sie wahrscheinlich bereit zu bauen. Falls nicht, sind die Antworten selbst das erste Ergebnis.

Unsere KI-Realitäts-Checkliste deckt ähnliches Terrain ab, mit 10 Fragen speziell für KMU, die KI evaluieren. Sie dauert etwa 15 Minuten und ist kostenlos. Sie sagt Ihnen nicht, was Sie bauen sollen, aber sie hilft Ihnen herauszufinden, ob Sie die richtige Frage stellen.

Fazit

Der wertvollste erste Schritt in jedem Technologieprojekt ist nicht die Umsetzung. Es ist sicherzustellen, dass man das Problem gut genug versteht, um zu wissen, wie "gelöst" aussieht.

Das ist keine neue Idee. Design Thinking lehrt es seit den 1960ern. Toyota hat es in den 1950ern formalisiert. Die Harvard Business Review veröffentlicht seit über einem Jahrzehnt Belege dafür. Und trotzdem bleibt der Druck, "einfach etwas zu bauen," überwältigend, besonders wenn KI im Spiel ist.

Die Unternehmen, die echten Wert aus Technologie ziehen, sind nicht die, die am schnellsten handeln. Es sind die, die lange genug innehalten, um sicherzustellen, dass sie in die richtige Richtung gehen.

Diese Pause ist keine verlorene Zeit. Sie ist die wirkungsvollste Investition in jedem Projekt.