Najdroższe oprogramowanie to takie, którego nikt nie potrzebował.
Dobry pomysł to jeszcze nie dobry produkt cyfrowy.
Zanim rozwój zacznie drogo kosztować, trzeba twardo wiedzieć: jaki problem, dla kogo, jaka korzyść i które założenia są najgroźniejsze, gdy okażą się błędne.
Z Lensem · około 3 minut
Problem przed funkcją
Najpierw sprawdzamy, który problem naprawdę warto rozwiązywać.
Ryzyko widać wcześnie
Najdroższe błędne założenie ma wypłynąć jak najszybciej.
Mały, sensowny start
Pierwszy zakres daje realną korzyść albo twardą naukę.
Po czym poznać, że rozwiązanie wyprzedza problem
Typowe sytuacje
Decyzja, żeby czegoś nie budować, bywa bardzo dobrym wynikiem produktowym.
Na ile da się dziś obronić pomysł na produkt?
Pomysł
Jest pomysł na rozwiązanie. Problem, użytkownik i korzyść stoją jednak głównie na założeniach.
- Pomysł na rozwiązanie
- Wiele założeń
- Mało potwierdzenia
Z Lensem · około 3 minut
Największą niepewność sprawdzić jak najwcześniej i jak najtaniej.
Nie na każde pytanie trzeba mieć odpowiedź. Najdroższe błędne założenia powinny być jednak znane, zanim staną się oprogramowaniem.
Jak O/S rozwija nowe produkty cyfrowe
Zrozumieć
Problem, użytkownik, kontekst i dzisiejsza alternatywa stają się konkretne.
Skupić
Główna korzyść i najgroźniejsze założenia dostają priorytet.
Sprawdzić
Założenia weryfikujemy rozmowami, prototypami, analizą procesu albo testami technicznymi.
Obciąć zakres
Z wniosków powstaje najmniejsza sensowna pierwsza wersja produktu.
Der Ablauf zuerst
Nie zaczynamy od funkcji. Zaczynamy od najdroższej niepewności.
Każde błędne założenie drożeje, gdy stanie się oprogramowaniem.
Co się zmieniadzięki dobremu DISCOVERY
Problem
Inwestycja zaczyna się od realnej potrzeby.
Zamiast startu od listy funkcji najpierw ustalamy, który problem naprawdę trzeba rozwiązać w biznesie i w operacjach.
Ryzyko
Krytyczne założenia widać wcześnie.
Niepewności sprawdzamy, zanim wejdą w drogi rozwój, zakup albo kolejne rundy uzgodnień.
MVP
Pierwsza wersja ma jasny cel.
MVP służy konkretnej korzyści albo konkretnej nauce. Nie chęci, żeby z góry odwzorować jak najwięcej oprogramowania.
DECYZJA
Budować, obciąć, zatrzymać: da się uzasadnić.
Czy budować, zacząć mniejszym zakresem, zostać przy standardzie, zmienić kierunek czy zatrzymać, wynika z potwierdzenia, a nie z przeciągającego się planowania.
Policz koszt otwartych decyzji produktowych
- Ile godzin na osobę idzie co tydzień w jeszcze otwartą decyzję produktową?
- Ile osób regularnie siedzi w temacie?
- Jak długo decyzja zostaje otwarta, zanim powstanie twardy kolejny krok?
4Godziny na osobę tygodniowo
3Osoby zaangażowane
8Tygodnie do decyzji
- ≈ 12 dni roboczychprzy 8 godzinach na dzień roboczy
- ≈ 2,4 tygodni roboczychprzy 5 dniach roboczych w tygodniu
96 godzin zespołu do decyzji · 12 dni roboczych do decyzji
Ta otwarta decyzja produktowa pochłania już
6528,00 zł
Kalkulator liczy wewnętrzny czas na decyzję. Nie mówi o wartości rynkowej, sukcesie produktu ani unikniętych kosztach rozwoju.
Którą niepewność warto zdjąć ze stołu jako pierwszą?
Lens pomoże ułożyć pomysł, ryzyko i najsensowniejszy kolejny test.
Częste pytania
- Mamy już konkretny pomysł na aplikację. Czy DISCOVERY i tak jest potrzebne?
- Czy O/S buduje MVP?
- Czy prototyp może wystarczyć?
- Czy O/S sprawdza, czy budować, czy kupić?
- Co może się wydarzyć po DISCOVERY?
- Jak mierzyć sukces produktu?
Nie automatycznie. Jeśli problem, użytkownik, wymagania i kierunek techniczny są już wystarczająco twarde, sensowne może być od razu skupione wdrożenie.
KONTAKT
Której decyzji produktowej nie da się dziś podjąć na twardych podstawach?
Opisz pomysł, problem i największe otwarte pytanie. Dostajesz wstępną ocenę, które założenie warto wyjaśnić przed rozwojem.