Beim Ergebnis anfangen. Warum sichtbare Prototypen bessere Entscheidungen erzeugen.

Bau zuerst das Sichtbare, dann den Rest. Es klingt kontraintuitiv, weil die Softwareentwicklung jahrzehntelang andersherum funktioniert hat: erst die Architektur, dann das Backend, dann irgendwann die Oberfläche. Jenny Wen nutzt das Bild der IKEA-Anleitung: Ohne das Bild des fertigen Regals auf Seite 1 sind die 47 Schritte danach sinnlos. Beim Bauen von Produkten gilt dasselbe. Wer am Ergebnis anfängt, sieht sofort, was funktioniert und was nicht. Nicht in der Theorie, sondern am lebenden Objekt. KI macht diesen Ansatz zum ersten Mal wirklich praktikabel.

Warum "Inside-Out" das Standardmodell ist

Die klassische Softwareentwicklung folgt einer logischen Kette: Requirements, Architektur, Backend, Frontend, Launch. Das ist technisch nachvollziehbar, weil jede Schicht auf der vorherigen aufbaut. Aber es hat einen fundamentalen Nachteil: Die Oberfläche, das was Nutzer sehen und bewerten können, kommt zuletzt. Feedback auf das Sichtbare entsteht erst spät im Prozess, wenn Änderungen teuer sind.

Auch agile Teams fallen häufig in diese Logik zurück. Sprint-Planung orientiert sich an technischen Abhängigkeiten, nicht an User-Sichtbarkeit. Das Ergebnis: Produktentscheidungen werden abstrakt getroffen, auf Basis von Dokumenten, Diagrammen und Annahmen. Ohne das Ergebnis zu sehen.

Das Gegenmodell: Ergebnis-First

Amazon "Working Backwards" ist die bekannteste Formalisierung dieses Prinzips. Bevor eine Zeile Code geschrieben wird, schreibt das Team eine interne Pressemitteilung und ein FAQ. Die Pressemitteilung beschreibt das fertige Produkt aus Kundensicht. Das FAQ adressiert kritische Fragen vorab. Der Zwang, das Endergebnis in Worte zu fassen, deckt Unklarheiten auf, die in einem Backlog unsichtbar bleiben.

Jenny Wen geht einen Schritt weiter mit der IKEA-Anleitung-Analogie: Seite 1 zeigt das fertige Regal. Dann die Schritte. Nicht umgekehrt. Beim Produktbau bedeutet das: Zeige erst das Ergebnis (als Mockup, Prototyp oder Landing Page), dann baue den Weg dahin. Die Reihenfolge verändert die Qualität der Entscheidungen, weil visuelles Feedback andere kognitive Ressourcen aktiviert als abstraktes Denken. Allan Paivio hat das als Dual Coding Theory beschrieben: Menschen verarbeiten visuelle und verbale Informationen in getrennten Kanälen, und die Kombination beider führt zu besserem Verständnis und besserer Erinnerung.

Die IKEA-Anleitung beginnt mit dem fertigen Regal. Produktentwicklung sollte genauso funktionieren.

KI als Enabler: Vor KI war "Ergebnis zuerst" teuer, weil Mockups und Prototypen Design-Zeit brauchten. Jetzt kannst du in Stunden eine funktionierende Oberfläche bauen und von dort iterieren. Das verändert nicht nur die Geschwindigkeit, sondern die Methodik: Statt "planen, dann bauen" wird es "bauen, dann entscheiden".

Ergebnis-First

2 Stunden

Sichtbarer Prototyp, sofortiges Feedback, Entscheidungen am lebenden Objekt. Iteration beginnt ab Tag 1.

Klassisch

6 Wochen

Requirements, Backend, Frontend. Erstes Nutzer-Feedback nach Wochen. Änderungen sind teuer.

Case Study: linja.me

Der Aufbau von linja.me ist ein reales Beispiel für Ergebnis-First. Kein Wireframe, kein Design-System als Startpunkt. Stattdessen: direkt am lebenden HTML gebaut, zusammen mit Claude Code als Co-Pilot. Jede Iteration war sofort sichtbar und testbar. Navigation, Footer, Blog-Seite, Einzelartikel: alles entstand am fertigen Objekt, nicht auf dem Whiteboard.

Der entscheidende Unterschied: Entscheidungen wurden AM Produkt getroffen. "Sieht die Navigation auf Mobile gut aus?" ist eine andere Frage als "Wie sollte die Navigation auf Mobile aussehen?". Die erste Frage hat eine sichtbare Antwort. Die zweite hat unendlich viele theoretische Antworten. Die geschätzte Zeitersparnis gegenüber einem klassischen Vorgehen (Wireframe, Design, Code): Faktor 3, bei mehr Iterationen und höherer Zufriedenheit mit dem Ergebnis.

Was ich mir vornehme

Ich möchte künftig konsequenter mit dem Sichtbaren starten. Nicht mit einem Konzeptdokument, sondern mit einem Prototyp, den ich anfassen und zeigen kann. Bei linja.me hat das als rohe HTML-Seite funktioniert. Dieses Prinzip will ich auf weitere Projekte übertragen: bei Stakeholder-Präsentationen erst die Demo bauen, bevor ich Slides mache. Bei neuen Produktideen erst zeigen, dann erklären. Ob mir das konsequent gelingt, wird sich zeigen. Die Versuchung, doch erst ein Konzept zu schreiben, ist real.

Kritische Einordnung

Ergebnis-First funktioniert vermutlich nicht für alles. Sicherheitskritische Systeme, komplexe Backend-Logik und regulierte Branchen brauchen möglicherweise andere Reihenfolgen, weil die Architektur dort keine nachgelagerte Entscheidung ist. Es bleibt auch das Risiko der schönen Fassade: ein Prototyp, der überzeugend aussieht, aber technisch nicht umsetzbar ist. Ob der Ansatz in grossen Teams skaliert oder ein Solo- bzw. Kleinteam-Privileg bleibt, muss sich erst noch zeigen. Und die Frage nach Design Debt ist offen: wenn du direkt am Ergebnis baust, statt ein System darunter zu legen, kann das langfristig teuer werden.

Was bleibt für jeden Tag

Zeige das Ergebnis, bevor du den Weg erklärst.

Stakeholder, Teams und du selbst profitieren vom Sichtbaren.

Bau zuerst, was Nutzer sehen.

Alles andere folgt aus dem, was funktioniert.

KI macht Sichtbarkeit billig.

Ein Prototyp in 2 Stunden ist besser als ein Konzept in 2 Wochen.

Quellen

Glossar

Working Backwards — Amazon-Methode: Pressemitteilung und FAQ schreiben, bevor die Entwicklung beginnt

PR/FAQ — Internes Amazon-Dokument bestehend aus Pressemitteilung und Frequently Asked Questions

Ergebnis-First — Ansatz, der mit dem sichtbaren Endergebnis beginnt statt mit der technischen Architektur

Dual Coding Theory — Kognitionstheorie: visuelle und verbale Informationen werden in getrennten Kanälen verarbeitet (Paivio)

Design Debt — Technische und gestalterische Schulden durch schnelles Bauen ohne systematische Grundlage

Rapid Prototyping — Schnelle Erstellung testbarer Produktversionen zur frühen Validierung

Build the visible part first, then the rest. It sounds counterintuitive, because software development worked the other way for decades: architecture first, then the backend, then eventually the surface. Jenny Wen uses the IKEA manual as a picture: without the image of the finished shelf on page 1, the 47 steps that follow are pointless. The same holds for building products. Whoever starts at the result sees immediately what works and what does not. Not in theory, but on the living object. AI makes this approach genuinely practical for the first time.

Why "inside-out" is the standard model

Classical software development follows a logical chain: requirements, architecture, backend, frontend, launch. That is technically reasonable, because each layer builds on the previous one. But it has a fundamental drawback: the surface, the part users see and can evaluate, comes last. Feedback on the visible only emerges late in the process, when changes are expensive.

Even agile teams often fall back into this logic. Sprint planning orients around technical dependencies, not user visibility. The result: product decisions get made in the abstract, on the basis of documents, diagrams, and assumptions. Without seeing the result.

The counter-model: result-first

Amazon's Working Backwards is the best-known formalization of this principle. Before a single line of code is written, the team writes an internal press release and an FAQ. The press release describes the finished product from the customer's view. The FAQ addresses critical questions up front. The discipline of putting the end result into words exposes ambiguities that stay invisible in a backlog.

Jenny Wen takes this a step further with the IKEA manual analogy: page 1 shows the finished shelf. Then the steps. Not the other way around. For product building this means: show the result first (as a mockup, prototype, or landing page), then build the path to it. The order changes the quality of decisions, because visual feedback activates different cognitive resources than abstract thinking. Allan Paivio described this as Dual Coding Theory: people process visual and verbal information in separate channels, and combining the two leads to better understanding and better recall.

The IKEA manual starts with the finished shelf. Product development should work the same way.

AI as enabler: before AI, "result first" was expensive because mockups and prototypes required design time. Now you can build a working surface in hours and iterate from there. That changes not only speed but methodology: instead of "plan, then build" it becomes "build, then decide".

Result-First

2 hours

Visible prototype, immediate feedback, decisions on the living object. Iteration starts on day 1.

Classical

6 weeks

Requirements, backend, frontend. First user feedback after weeks. Changes are expensive.

Case study: linja.me

Building linja.me is a real example of result-first. No wireframe, no design system as a starting point. Instead: built directly on living HTML, with Claude Code as a co-pilot. Every iteration was immediately visible and testable. Navigation, footer, blog page, individual articles: everything emerged on the finished object, not on a whiteboard.

The decisive difference: decisions were made AT the product. "Does the navigation look good on mobile?" is a different question than "How should the navigation look on mobile?" The first has a visible answer. The second has infinite theoretical answers. Estimated time savings compared to a classical approach (wireframe, design, code): factor 3, with more iterations and higher satisfaction with the result.

What I commit to

I want to be more consistent about starting with the visible. Not with a concept document, but with a prototype I can touch and show. With linja.me this worked as a raw HTML page. I want to carry this principle into other projects: for stakeholder presentations, build the demo before the slides. For new product ideas, show first, then explain. Whether I manage to be consistent about this remains to be seen. The temptation to write a concept first is real.

A critical look

Result-first probably does not work for everything. Safety-critical systems, complex backend logic, and regulated industries may need different orderings, because architecture there is not a downstream decision. There is also the risk of the beautiful facade: a prototype that looks convincing but is not technically feasible. Whether the approach scales in large teams or stays a privilege of solo or small teams remains to be seen. And the question of design debt is open: when you build directly at the result instead of laying down a system underneath, that can become expensive in the long run.

What stays with you every day

Show the result before you explain the path.

Stakeholders, teams, and you yourself benefit from the visible.

Build first what users see.

Everything else follows from what works.

AI makes visibility cheap.

A prototype in 2 hours beats a concept in 2 weeks.

Sources

Colin Bryar & Bill Carr (2021). Working Backwards: Insights, Stories, and Secrets from Inside Amazon. St. Martin's Press.
Allan Paivio (1971). Dual Coding Theory. Imagery and Verbal Processes. Holt, Rinehart & Winston.
Teresa Torres (2021). Continuous Discovery Habits. Product Talk LLC.
Alberto Savoia (2019). The Right It. Harper Business.
Ryan Singer (2019). Shape Up. Basecamp.

Glossary

Working Backwards — Amazon method: write press release and FAQ before development starts

PR/FAQ — Internal Amazon document made of press release and frequently asked questions

Result-First — Approach starting from the visible end result instead of technical architecture

Dual Coding Theory — Cognitive theory: visual and verbal information are processed in separate channels (Paivio)

Design Debt — Technical and design debt from fast building without a systematic foundation

Rapid Prototyping — Fast creation of testable product versions for early validation