Ein Produktentdeckungsprozess, der Verschwendung verhindert

Der teuerste Code ist der Code, den niemand nutzt. Teams investieren monatelang in Features, die sauber ausgeliefert wurden, alle Tests bestanden haben und dann unberührt blieben – weil das zugrundeliegende Problem angenommen statt validiert wurde. Product Discovery ist die günstige Arbeit, die Sie vor der teuren Arbeit erledigen, um sicherzustellen, dass Sie etwas bauen, das die Leute tatsächlich wollen. Das muss nicht aufwendig sein. Es muss vor dem Build passieren, nicht danach.

Discovery ist keine Phase, sondern ein Filter

Discovery macht man nicht einmal und hört dann auf. Jedes bedeutsame Feature durchläuft denselben Filter: Ist das ein echtes Problem, für echte Nutzer, das wir auf eine Weise lösen können, die sie auch annehmen werden? Der Punkt ist, schlechte Ideen günstig zu begraben – am Whiteboard, bevor sie zu schlechtem Code werden.

Beginnen Sie mit dem Problem, nicht mit der Lösung

Gründer kommen mit Lösungen an: „Wir brauchen ein Dashboard", „KI einbauen." Die erste Aufgabe der Discovery ist es, das auf das eigentliche Problem zurückzuführen. Was versucht der Nutzer zu erreichen? Was tut er heute? Wo tut es weh?

Wenn Sie das Problem nicht in einem Satz formulieren können, ohne Ihre Lösung zu nennen, sind Sie noch nicht bereit zu bauen. Die Lösung ist eine Hypothese; das Problem ist das, was es zu validieren gilt.

Sprechen Sie mit Nutzern, bevor Sie ein Spec schreiben

Nichts ersetzt einige echte Gespräche. Fünf bis acht Interviews mit Menschen, die das Problem kennen, werden Ihnen mehr beibringen als wochenlange interne Debatten.

• Fragen Sie nach dem, was sie getan haben, nicht nach dem, was sie hypothetisch tun würden.
• Fragen Sie nach dem letzten Mal, als sie auf dieses Problem gestoßen sind – Konkretes schlägt Allgemeines.
• Achten Sie auf Workarounds; ein schmerzhafter Workaround ist der Beweis, dass das Problem real ist.
• Widerstehen Sie dem Drang zu pitchen. Sie sind dort, um zu lernen, nicht um zu verkaufen.

Wenn niemand das Problem beschreibt, das Sie vorausgesetzt haben, ist das ein Befund, der weit mehr wert ist als der Build, den Sie damit vermieden haben.

Validieren Sie die Nachfrage, bevor Sie sich festlegen

Sobald das Problem bestätigt ist, testen Sie, ob Ihre Lösung gewünscht wird, bevor Sie sie vollständig bauen:

• Ein klickbarer Prototyp, den Sie echten Nutzern vorlegen.
• Eine Landing Page, die die Anmeldeabsicht misst.
• Ein Concierge-Test, bei dem Sie das Ergebnis zuerst manuell liefern.
• Ein Fake-Door-Test, der misst, wie viele Menschen auf das Feature klicken.

Das dauert Tage und kann Monate sparen. Ein Prototyp, mit dem Nutzer nicht interagieren, ist ein günstiges „Nein."

Legen Sie fest, was Ihre Meinung ändern würde

Die Disziplin, die Discovery greifbar macht: Benennen Sie Ihre riskanteste Annahme und die Evidenz, die sie widerlegen würde. „Wir glauben, dass Operations Manager dafür zahlen werden, diesen Report zu automatisieren; wir liegen falsch, wenn weniger als die Hälfte der Befragten darin einen echten Kostenfaktor sieht." Damit hat Discovery ein klares Bestehen/Scheitern – und kein Bauchgefühl.

Dann, und erst dann, legen Sie den Build-Scope fest

Wenn das Problem validiert ist, die Nachfrage belegt ist und die Annahmen den Kontakt mit echten Nutzern überstanden haben, sind Sie bereit, Scope und Build festzulegen – mit deutlich geringerem Risiko, das Falsche gut zu bauen.

Bei Pykero führen wir schlanke Discovery durch, bevor wir Produktionscode schreiben, damit unsere Kunden nicht für Features zahlen, um die ihre Nutzer nie gebeten haben. Wenn Sie dabei sind, sich auf eine Roadmap festzulegen, sprechen Sie mit uns.