Wie man an einem Nachmittag einen POC fertigstellt: Ein Claude-Code- und Upsun-Leitfaden für Produkt- und Produktmarketing

Ich habe ein Upsun-Projekt, das ausschließlich aus Proof-of-Concepts besteht.

Im Grunde ist es ein Dashboard. Jedes POC hat seine eigene Kachel. Wenn du darauf klickst, gelangst du auf eine Seite mit drei Registerkarten. Die erste Registerkarte enthält eine schriftliche Erklärung dessen, was das POC demonstriert. Der zweite Reiter ist der POC selbst, mit einer integrierten Demo, die eine automatisierte Schritt-für-Schritt-Anleitung der Features bietet, sodass der Empfänger zusehen kann, wie sie läuft, ohne dass ich am Telefon dabei sein muss. Der dritte Reiter ist eine Liste der Produktkomponenten, die bereits vorhanden sind, um diesen POC zu unterstützen, sowie derjenigen, die wir tatsächlich noch entwickeln müssten, damit das Ganze wirklich auf den Markt kommt.

Ich habe das Dashboard nicht selbst erstellt. Ich habe Claude gebeten, das Dashboard zu erstellen. Dann habe ich angefangen, mich darin zurechtzufinden.

Wenn jemand aus dem Produkt- oder Entwicklungsteam sehen will, worüber ich nachgedacht habe, schicke ich die Dashboard-URL. Sie wählen eine Kachel aus. Das anschließende Gespräch ist doppelt so gut wie das, das ich früher mit einer Präsentation geführt habe.

Dieser Beitrag ist die Schritt-für-Schritt-Anleitung, von der ich mir gewünscht hätte, dass mir jemand sie gegeben hätte, bevor all das überhaupt existierte. Ich gehe davon aus, dass du ein Produktmanager oder Produktmarketer bist, der noch nie eine App bereitgestellt hat, der eine echte Produktidee hat, die du greifbar machen möchtest, und dem gesagt wurde, du solltest lernen, zu programmieren. Am Ende dieses Beitrags wirst du den Weg, die Werkzeuge sowie die spezifischen Fähigkeiten und MCPs kennen, die den größten Einfluss haben.

(Eine Anmerkung zur Terminologie: Wir nennen es ab jetzt „KI-gestützte Entwicklung“. Das ist dasselbe, klingt aber schicker und lässt sich in einer Vorstandssitzung schwerer abtun.)

Ein Hinweis zu den Risiken, bevor wir loslegen. Was du hier entwickelst, ist ein Kommunikationswerkzeug, kein Programm. Diese Unterscheidung ist wichtig. Wir kommen später noch darauf zurück.

Noch eine Annahme, von der ich ausgehe: Du hast bei der Arbeit keine strenge Token-Obergrenze für deine KI-Nutzung. Falls doch, ändert das die Rechnung ein wenig. Baue das Fundament schrittweise auf, statt an einem einzigen Nachmittag. Richte deine Produktvorlage, deine Prinzipien-Datei und dein Dashboard über mehrere Sitzungen hinweg ein. Sobald dieses Fundament besteht, kostet jedes weitere POC nur noch einen Bruchteil der Token, da die KI hauptsächlich klont und optimiert, anstatt alles von Grund auf neu zu generieren.

Was du tatsächlich brauchst

Drei Dinge.

1. Ein KI-Programmierwerkzeug. Die mit Abstand zugänglichste Option ist die Claude-Desktop-App. Melde dich an und klicke auf den Reiter „Claude Code“. Das war’s schon. Der gleiche Arbeitsablauf funktioniert auch in OpenAI’s Codex oder Googles Antigravity, falls dein Team eines dieser Tools bevorzugt.
2. Ein Upsun-Konto. Dort wird dein POC gespeichert, damit andere darauf klicken können. Melde dich unter upsun.com an.
3. Eine klare Vorstellung davon, was der POC beweisen soll. Das ist der Teil, den die meisten Leute überspringen. Wir werden darüber sprechen.

Du musst weder JavaScript, Python, Docker noch irgendetwas anderes davon beherrschen. Du musst wissen, was deine Idee leisten soll. Die KI übernimmt den technischen Teil. Du kümmerst dich um die produktbezogene Beurteilung.

Achtung, falls dein Unternehmen dir die Nutzung einer Desktop-KI-App nicht erlaubt. Wenn du deinen eigenen API-Schlüssel verwenden musst, ist „opencode“ die open source CLI, die ich benutzt habe. Etwas mehr Einrichtungsaufwand. Gleiches Endergebnis.

Schritt 1: Öffne das Tool und wähle einen Ordner aus

Wenn du noch nie ein KI-Programmier-Tool benutzt hast, fang mit Claude Desktop an. Lade es herunter, melde dich an und klicke auf den Reiter „Claude Code“.

Hier ist etwas, was dir niemand von vornherein sagt: Du musst einen Ordner auswählen. Claude Code (und jedes andere agentische Programmier-Tool) arbeitet innerhalb eines einzigen Projektverzeichnisses auf deinem Computer.

Du brauchst nicht für jeden POC einen separaten Ordner, und ich würde dir sogar ausdrücklich davon abraten. Ich nutze das Prinzip: ein Ordner für alles. Deine Produktvorlage befindet sich darin. Jedes POC befindet sich darin. Dein Dashboard befindet sich darin. Wenn du dein fünftes POC starten möchtest, öffnest du Claude Code im selben Ordner und sagst: „Lass uns ein weiteres POC starten.“ Die KI verfügt bereits über den gesamten Kontext: deine Vorlage, deine Grundsätze, deine bisherigen POCs, dein Dashboard.

Erstelle irgendwo an einem sinnvollen Ort (Desktop, Dokumente, wo auch immer deine Arbeitsdateien liegen) einen neuen leeren Ordner. Nenne ihn „pocs“ und lass ihn wachsen. Weise Claude Code darauf hin, wenn es danach fragt. Von nun an befindet sich jede Datei, die die KI schreibt, darin.

Codex, Antigravity und opencode funktionieren genauso. Wähle zuerst einen Ordner aus und starte dann das Gespräch.

Quäle dich nicht mit der Frage, welches Tool du wählen sollst. Die Arbeit ist wichtiger als das Tool.

Schritt 2: Richte zuerst deine Skills und MCPs ein

Es mag kontraintuitiv erscheinen, aber der richtige Schritt vor deiner ersten Eingabe ist, deine Skills und MCPs zu installieren. Sie verändern das Verhalten der KI bereits ab der allerersten Nachricht, und einer davon (grill-me) wurde speziell entwickelt, damit deine erste Eingabe besser ankommt.

Skills sind wiederverwendbare Anweisungen, denen die KI automatisch folgt. MCP-Server sind Verbindungselemente zu anderen Tools (Notion, Linear, Figma, Slack, GitHub und so weiter). Plugins sind Bündel aus beidem.

Die Liste der Dinge, die du installieren musst, ist überwältigend, wenn du dich erst einmal auf die Suche machst. Mach dich nicht erst auf die Suche.

Die Eingabe, die ich tatsächlich verwende, lautet in etwa:

„Ich nutze Claude Desktop auf dem Mac. Installiere für mich den ‚grill-me‘-Skill aus Matt Pococks Repo, den Upsun-Skill und Context7. Erkläre mir alle notwendigen Einrichtungsschritte oder führe sie einfach direkt durch, wenn du kannst.“

Das war’s. Die KI weiß, wie ihr eigenes Ökosystem funktioniert. Lass sie die Installation übernehmen. Du optimierst nicht für eine elegante Skill-Liste. Du optimierst für den nächsten Prototyp.

Die drei, die ich bei jedem POC-Projekt installiere:

• Matt Pococks Skill-Repo, insbesondere den „grill-me“-Skill. Er zwingt die KI dazu, dich zu deiner Idee zu befragen, bevor sie irgendetwas generiert. Fängt die Hälfte meiner falschen Annahmen ab, bevor sie zu schlechtem Code werden.
• Das „Upsun“-Skill. Bringt Claude bei, wie man Upsun-Konfigurationsdateien auf Anhieb richtig schreibt. Spart dir einen Hin- und Rücklauf beim Deploy.
• Context7. Versorgt die KI mit aktueller Dokumentation für jede Bibliothek, die du verwendest. Ohne sie erfindet die KI gelegentlich Funktionsnamen. Mit ihr lässt sich das Programmieren tatsächlich durchführen.

Darüber hinaus solltest du die MCPs für die Tools installieren, in denen dein Kontext tatsächlich vorliegt. Notion oder Confluence für Spezifikationsdokumente. Linear oder Jira für Tickets. Figma für Designs. Slack für Kundengespräche.

Schritt 3: Formuliere die Eingabeaufforderung wie ein Produktbriefing

Das ist der Teil, den die meisten Nicht-Ingenieure beim ersten Versuch falsch machen. Sie tippen: „Erstelle mir eine App, die X macht.“ Das Ergebnis ist eine generische Hülle, die X nicht ganz erfüllt.

Formuliere es so, wie du einen erfahrenen Entwickler briefen würdest, dem du bei Entscheidungen vertraust, und nutze dabei die Fähigkeiten, die du gerade installiert hast.

Eine schlechte erste Vorgabe:

„Entwickle ein Tool, mit dem Nutzer eine CSV-Datei hochladen und ein Diagramm anzeigen können.“

Eine bessere erste Anforderung:

„Ich bin Produktmarketer bei einem Unternehmen für Entwicklertools. Ich möchte ein anklickbares POC erstellen, das eine einzige Positionierungsidee veranschaulicht: ‚Die Onboarding-Dokumentation deines Teams ist das Produkt.‘ Nutze ‚Grill-me first‘, um meine Formulierung zu hinterfragen und alles aufzudecken, was ich noch nicht zu Ende gedacht habe. Sobald wir die Aufgabenstellung geschärft haben, stelle ich mir Folgendes vor: eine zweiseitige Web-App. Seite eins nimmt eine Markdown-Datei entgegen. Seite zwei rendert eine anklickbare, navigierbare Version mit einer Seitenleiste aus Überschriften und einem ‚Diesen Abschnitt bewerten‘-Widget am Ende jedes Abschnitts. Verwende React. Nutze den Upsun-Skill, damit das Projekt von Anfang an für Upsun bereit ist. Keine Authentifizierung, keine Datenbank, In-Memory-Zustand ist in Ordnung. Das ist ein Wegwerf-Prototyp. Optimiere es so, dass ich es am Donnerstag vorführen kann.“

Der Unterschied: Du hast der KI mitgeteilt, wozu der POC dient, wie er aussehen soll, welche Skills aufgerufen werden sollen, worauf du optimierst und welche Kompromisse in Ordnung sind. Das ist dieselbe Vorgabe, die du einem erfahrenen Entwickler geben würdest. Dieselbe Vorgabe funktioniert auch hier.

Tipp: Gib ihr dein echtes Produkt als Eingabe. Zieh zumindest drei oder vier Screenshots deiner Produktions-App hinein, damit der POC das echte Look-and-Feel übernimmt. Besser noch: Gib der KI die URL deines Produkts und weise sie an, deine Website zu analysieren, den von dir verwendeten Stack zu ermitteln und ihn so originalgetreu wie möglich nachzubilden. Je näher dein POC am Original ist, desto leichter fällt es Ingenieuren und Kunden, auf die Idee einzugehen, anstatt sich von einer ungewohnten Benutzeroberfläche ablenken zu lassen.

Tipp: Fang im Plan-Modus an. Die meisten agentenbasierten Tools haben einen. So schlägt die KI einen Plan vor, bevor sie auch nur eine einzige Datei anfasst. Lies den Plan durch, weise auf alles hin, was nicht passt, und wechsle in den Auto-Modus, sobald ihr euch darauf geeinigt habt, was entwickelt werden soll. Das ist ein POC. Schnell und schlampig. Aber auch „schlampig“ profitiert von einem fünfminütigen Plan.

Schritt 4: Iteriere laut

Sobald die KI mit der Entwicklung beginnt, ist es deine Aufgabe, mit ihr zu sprechen wie mit einem Kollegen, der über alle technischen Fähigkeiten verfügt, aber keinen Einblick in deinen Produktkontext hat.

Was funktioniert:

• „Der Button auf Seite zwei ist zu klein. Er soll sich wie ein primärer CTA anfühlen, nicht wie ein Link in der Fußzeile.“
• „Wenn ich eine Datei ohne Überschriften hochlade, ist die Seitenleiste leer und die Seite sieht kaputt aus. Zeig einen hilfreichen Leerstatus an.“
• „Das ist zu ausgefeilt. Lass es absichtlich eher wie einen Prototyp aussehen. Weniger fertiges Produkt, mehr Skizze.“

Was nicht funktioniert:

• Vage Anweisungen. „Mach es besser.“ Die KI wird etwas anderes erstellen. Es wird nicht besser sein.
• Mehrere Änderungen in einer einzigen Nachricht. Gib ihr jeweils nur eine Sache auf einmal. So kommst du schneller voran, nicht langsamer.
• Es wie eine fertige Spezifikation behandeln. Der POC wird zeigen, dass du eigentlich gar nicht wusstest, was du wolltest. Gut. Genau darum geht’s.

Die meisten meiner POCs durchlaufen in der ersten Stunde 15 bis 25 Runden dieses Gesprächs. Das ist normal. Das Gespräch ist die Arbeit.

Tipp: Sag der KI, sie soll ihre Grundsätze aufschreiben. Etwa so: „Erstelle in diesem Projekt eine Datei namens PRINCIPLES.md. Halte die Designentscheidungen fest, auf die wir uns gerade geeinigt haben, und aktualisiere sie jedes Mal, wenn wir eine ändern.“ Meine festen Grundsätze lauten: API first. Mobile first. Biete immer einen Hell- und einen Dunkelmodus an. Gib mir zwei Versionen zur Auswahl, nicht nur eine. Klone immer die Vorlage, bearbeite sie niemals direkt. Sobald diese festgehalten sind, musst du deinen Geschmack nicht mehr bei jedem neuen Chat neu erklären. Die nächste Sitzung liest die Datei und macht dort weiter, wo du aufgehört hast.

Schritt 5: Auf Upsun bereitstellen

Jetzt hast du eine funktionierende App auf deinem Laptop. Dein Entwickler kann sie von dort aus nicht sehen. Hier kommt Upsun ins Spiel.

Upsun ist eine cloud-basierte Anwendungsplattform. Das heißt: Du verweist sie auf dein Projekt, sie findet heraus, wie es gehostet werden muss, gibt dir eine URL und hält sich ansonsten im Hintergrund. Für einen POC ist genau das ideal. Du willst dir keine Gedanken über Server machen.

Der schnellste Weg ist, die KI die gesamte Einrichtungsarbeit über den Upsun-MCP-Server erledigen zu lassen. Du meldest dich einmal an. Die KI erledigt den Rest.

1. Registriere dich oder melde dich unter upsun.com an.
2. Klicke oben rechts in der Upsun-Konsole auf deinen Namen, um das Profilmenü zu öffnen, und klicke dann auf „API-Token“. Erstelle ein Token und kopiere es.
3. Füge diesen in deine KI ein:

„Ich möchte dieses Projekt auf Upsun bereitstellen. Ich habe einen Upsun-API-Token, den ich als Nächstes einfügen werde. Behandle den Token wie ein Geheimnis: Wiederhole ihn mir nicht, schreibe ihn in keine sichtbare Datei und protokolliere ihn nicht. Installiere den Upsun-MCP-Server mit aktivierten Lese- und Schreibrechten (die Standardeinstellung ist schreibgeschützt; wir brauchen Schreibrechte, damit du das Projekt erstellen kannst), erstelle dann ein neues Upsun-Projekt, pushe diese Codebasis und gib mir die URL, sobald du fertig bist.“

Ein Wort zum Token. Dieser API-Token ist der Schlüssel zu deinem Upsun-Konto. Füge ihn nicht in Slack ein. Committe ihn nicht in ein Repo. Teile ihn nicht mit einem Kollegen, der bereits über eigene Zugangsdaten verfügt. Der Satz „Behandle dies als Geheimnis“ in der obigen Eingabeaufforderung ist bewusst so formuliert; er weist die KI unter anderem an, den Token aus Protokollen und Dateien fernzuhalten, wo ihn später jemand anderes lesen könnte.

Die KI installiert das MCP, kommuniziert direkt mit Upsun, erstellt das Projekt, programmiert den Code und gibt dir eine URL. Das dauert in der Regel von Anfang bis Ende nur ein paar Minuten.

Tipp: CLI als Backup. Falls das MCP aus irgendeinem Grund hängen bleibt, greif auf die Upsun-CLI zurück: „Wechsle zur Upsun-CLI. Installiere sie, führe `upsun login` aus, erstelle ein Projekt und pushe den Code.“ Gleiches Ergebnis, nur etwas manueller.

Die offizielle MCP-Anleitung findest du unter developer.upsun.com.

Wenn irgendwo auf dem Weg ein Fehler auftritt, füge den Fehlertext einfach wieder in die KI ein. In neun von zehn Fällen kennt sie die Lösung.

Schritt 6: Mach es zugänglich (das Dashboard-Muster)

Das ist der Schritt, von dem ich mir wünschte, jemand hätte ihn mir vor sechs Monaten gezeigt.

Stelle nicht jedes POC als eigenständige App bereit, nach der du dich erst durch Slack-Threads wühlen musst, um sie zu finden. Erstelle ein einziges Upsun-Projekt, das alle deine POCs beherbergt, und stelle ein Dashboard an den Anfang. Da dein Ordner aus Schritt 1 bereits die Vorlage, jedes POC und das Dashboard nebeneinander enthält, wird das Ganze zusammen als ein einziges Upsun-Projekt bereitgestellt. Das Dashboard ist einfach der Einstieg.

Jedes POC bekommt eine Kachel. Jede Kachel verlinkt auf eine Seite mit drei Registerkarten:

1. Das Argument. Eine schriftliche Erklärung, was der POC ist und für welche Idee er spricht.
2. Die Demo. Der POC selbst, mit einer integrierten „Walkthrough“-Schaltfläche, die eine automatische Führung durch die Features ermöglicht. Füge den Link in Slack ein, damit der Empfänger sich die Funktionsweise in Ruhe ansehen kann.
3. Die Grundbausteine. Eine Liste dessen, was in unserem eigentlichen Produkt bereits vorhanden ist, um diesen POC zu unterstützen, sowie dessen, was noch entwickelt werden müsste, um die Features wirklich auf den Markt zu bringen.

Dieser dritte Reiter ist derjenige, der das Vertrauen des Entwicklerteams gewinnt. Er sagt ganz klar: „Ich tue nicht so, als wäre das einfach. Hier ist, was wir tatsächlich entwickeln müssten.“

Tipp: Erstelle einmalig eine Vorlage deines echten Produkts. Verbringe einen Nachmittag damit, ein abgespecktes Gerüst zu erstellen, das wie dein tatsächliches Produkt aussieht und sich auch so anfühlt. Die wichtigsten UI-Komponenten sind vorhanden, kein echtes Backend, nur Scheindaten. Von da an beginnt jeder neue POC mit einem „git clone“ dieser Vorlage. Damit hast du bereits 30 % geschafft. Deine Demos sehen aus wie das Produkt. Deine Entwickler zucken nicht mehr bei ungewohnten UI-Mustern in deinen Prototypen zusammen.

Tipp: Entwickle nach ein paar Durchläufen deine eigene POC-Skill. Sobald du ein oder zwei POCs veröffentlicht und herausgefunden hast, wie dein persönlicher Prozess aussieht, bitte die KI, diesen Workflow in eine benutzerdefinierte Skill zu verpacken. Gib ihr deine Konventionen vor (Ordnerstruktur, README-Format, „Primitives“-Tab-Muster, Upsun-Konfigurationsstil) und lass sie die Skill für dich erstellen. Danach beginnt jedes POC automatisch mit dem richtigen Gerüst.

Tipp: Das zweite POC geht viel schneller als das erste. Sobald dein Ordner eine Vorlage, eine Prinzipien-Datei, ein Dashboard und mindestens ein POC enthält, lässt sich deine Eingabeaufforderung für das nächste POC auf einen Satz reduzieren: „Lass uns ein weiteres POC starten. Hier ist die Idee: [deine Idee]. Klone die Vorlage, füge dem Dashboard eine Kachel hinzu, halte dich an die Prinzipien.“ Die KI erledigt den Rest. Die meisten meiner POCs nach dem ersten sind in weniger als einer Stunde fertig, da das gesamte Gerüst bereits vorhanden ist.

Schritt 7: Teile es wie einen Prototyp

Das ist der kulturelle Teil. Wie du den POC teilst, entscheidet darüber, ob er ein POC bleibt oder versehentlich zum Ausgangspunkt für die Produktion wird.

Ich halte nicht viel von der Förmlichkeit „POC-Alarm!“. So redet eigentlich niemand. Was ich in Slack schicke, klingt eher so:

„Okay, hör mir mal zu … Was wäre, wenn [die Idee, für die dieses POC spricht]? Hier ist ein erster Entwurf: [Link]. Klick dich ein bisschen durch. Sag mir, was gut rüberkommt, was nicht und was du weglassen würdest. Das ist ein POC, kein Ausgangspunkt. Den Code schmeiß ich so oder so weg.“

Die lockere Formulierung „hör mir mal zu“ ist wichtig. Sie lädt zu einem Gespräch ein, anstatt eine Überprüfung zu verlangen. Der Satz „POC, kein Ausgangspunkt“ zieht bewusst die Grenze zwischen Produktion und Prototyp, damit niemand die funktionierende App mit einem Vorsprung für das Produktionssystem verwechselt.

Lass die Einleitung nicht weg.

Das empfohlene Starter-Kit (an einem Ort)

Eine Copy-Paste-Version dessen, was installiert werden muss.

KI-Tool:

• Claude-Desktop-App (am einfachsten zugänglich), Claude-Programmieren-Registerkarte
• Alternativen: Codex, Antigravity oder opencode, falls dein Unternehmen API-Schlüssel benötigt

Skills:

• Matt Pococks Skills-Repo, insbesondere „grill-me“
• Das „Upsun“-Skill
• Context7
• Dein eigener, individueller POC-Skill (nach ein paar POCs)

MCPs (installiere sie dort, wo dein Team tatsächlich arbeitet):

• Notion oder Confluence
• Linear, Jira oder Asana
• Figma
• Slack
• GitHub (optional)

Projekt-Hygiene:

• Eine PRINCIPLES.md-Datei, die von der KI gepflegt wird
• Eine funktionsfähige Vorlage deines echten Produkts, aus der du neue POCs klonen kannst
• Ein Upsun-Projekt, das alle deine POCs hostet, mit einem Dashboard

Du kannst in einer Stunde loslegen. Noch schneller, wenn du die Installation der KI überlassen lässt.

Der Kompromiss, den ich dir schulde

POCs, die auf diese Weise erstellt werden, haben einen echten Fehlermodus. Sie sehen fertig aus. Eine funktionierende App mit echten Schaltflächen erzeugt die Illusion von Vollständigkeit. Wenn die Demo präsentiert wird, lautet die naheliegende nächste Frage: „Okay, lasst uns das veröffentlichen“, und genau da geraten Teams in Schwierigkeiten. Das Programm, das die KI an einem Nachmittag programmiert hat, ist kein Programm, das irgendjemand vor Kunden ausführen sollte. Gartner warnte, dass „Prompt-to-App-Ansätze, die von Citizen-Entwicklern angewendet werden, die Anzahl der Softwarefehler bis 2028 um 2500 % erhöhen werden“. Sie haben Recht damit, was passiert, wenn niemand eine Grenze zieht.

Zieh eine Grenze. Dann überschreite sie absichtlich – unter der Leitung des Entwicklers. Der POC war das Gespräch. Das Produkt ist das, was du als Nächstes entwickelst – mit den richtigen Leuten, der richtigen Sorgfalt und der richtigen Architektur.

Zurück zum Dashboard

Das Dashboard war nicht der Plan.

Mein erster POC lief als eigenständiges Projekt. Der zweite ebenfalls. Beim dritten oder vierten hatte ich ein Chaos: Links, die über Slack-Threads verstreut waren, die Hälfte davon veraltet, und niemand konnte die Demo von gestern finden, wenn er sie einem Kollegen zeigen wollte.

Also bat ich Claude, das Dashboard zu erstellen. Der gleiche Arbeitsablauf wie bei jedem anderen POC. Zwei Stunden später hatte ich eine Seite mit Kacheln, die alle POCs an einem Ort zusammenfasste, im oben beschriebenen Format mit drei Registerkarten. Jetzt schicke ich eine URL und lasse den Empfänger stöbern.

Das ist das, was dir niemand sagt. Das wertvollste Ergebnis in diesem Arbeitsablauf ist nicht irgendein einzelnes POC. Es ist das System, das du um sie herum aufbaust und das die POCs für alle anderen zugänglich macht.

Bau das hässliche Ding. Stell es auf Upsun bereit. Mach es zugänglich. Dann mach das nächste einfacher als das letzte.

Der Prototyp ist nicht das Produkt. Er ist das schnellste Argument dafür, wie das Produkt aussehen könnte. Das Dashboard, nach acht Monaten, ist der Beweis dafür, dass das alles funktioniert.

Jetzt bring eins auf den Markt.