Świetne produkty: Discovery vs. Delivery

Większość z nas pracuje nad dość trudnymi problemami i zazwyczaj potrzeba dość złożonych systemów, aby te problemy rozwiązać.

Wiele zespołów stoi przed dwoma głównymi wyzwaniami:

Po pierwsze, muszą dowiedzieć się, jak powinna wyglądać rozwiązanie dla klienta (Discovery). Oznacza to zarówno ustalenie, czy w ogóle istnieją klienci, którzy potrzebują tego rozwiązania (popyt), jak i znalezienie rozwiązania, które działa zarówno dla klientów, jak i dla własnej firmy. Jeszcze trudniej jest znaleźć jedno rozwiązanie, które działa dla wielu klientów, a nie tylko dla kilku konkretnych. Aby to osiągnąć, musimy szybko się uczyć.

Po drugie, trzeba zadbać o dostarczenie solidnej i skalowalnej implementacji, na której wartości nasi klienci mogą polegać (Delivery). Zespół powinien mieć zaufanie do wydania. Nawet jeśli nigdy nie można mieć 100% pewności, nie powinno się też modlić o to, żeby wszystko poszło dobrze podczas releasu.

Trzeba więc zarówno szybko się uczyć, jak i mieć zaufanie do swoich releasów.

Czy to może działać?

Zrozumiałe jest, że wiele osób uważa, że te dwa różne cele są sprzeczne ze sobą. Musimy próbować szybko coś releasować, aby dowiedzieć się, co działa, a co nie. Jednocześnie nie chcemy releasować czegoś, co nie jest jeszcze dojrzałe, i ryzykować szkody dla naszych klientów i marki.

Rozmawiałem z wieloma zespołami produktowymi i często byłem konfrontowany z tym, że z jednej strony nakłaniam zespół do agresywniejszego releasowania i zbierania feedbacku od klientów, a jednocześnie wymagam, aby nie szli na kompromisy w zakresie niezawodnego, wydajnego i bezpiecznego oprogramowania.

Minimum Viable Product

Dla wielu zespołów koncepcja Minimum Viable Product (MVP) nie jest prosta, ponieważ z jednej strony jest się zmotywowanym, aby szybko dostarczyć coś klientowi i uzyskać feedback, ale z drugiej szybko pojawia się uczucie, że tzw. „produkt" mógłby być wstydliwy – i jak w ogóle można by coś takiego wypuścić na rynek?

Szybkie uczenie się i solidne releasy

Chciałbym tutaj wyjaśnić, jak dobre zespoły potrafią łączyć oba cele – szybkie uczenie się i solidne releasy.

Zasadniczo uważam, że większości zespołów drugi cel – dostarczanie sensownego oprogramowania – przychodzi łatwiej niż szybkie próbowanie rzeczy i zdobywanie nowej wiedzy. Continuous Delivery, czyli ciągłe dostarczanie, to dobra metoda, którą zaobserwowałem u zespołów, które zrozumiały znaczenie wielu małych i przyrostowych zmian złożonego systemu.

Czym w ogóle jest produkt?

Przyczyną tego zamieszania jest między innymi fakt, że często po prostu nie wiadomo dokładnie, co oznacza „produkt", „jakość produktu", „live in production" itp. Staram się zawsze używać pojęcia „produkt" dla produktu, który jest w stanie rzeczywiście nadającym się do sprzedaży. Jest skalowalny i oferuje odpowiednią wydajność. Istnieje solidny pakiet testów regresyjnych. Jest zaprojektowany tak, aby można było zbierać potrzebne analizy. W zależności od potrzeb został zinternacjonalizowany lub zlokalizowany. Jest łatwy w utrzymaniu. Odpowiada obietnicom marki. I co najważniejsze, zespół może releasować produkt z czystym sumieniem.

To nie jest proste i zajmuje większość czasu przy tworzeniu. Właśnie dlatego staramy się, aby te wysiłki nie poszły na marne.

Wykonywanie tej pracy, nawet gdy sam menedżer produktu nie jest pewny, czy klienci w ogóle chcą lub potrzebują rozwiązania, to absolutnie pewny przepis na marnotrawstwo.

Product Discovery

Sens Product Discovery polega więc na zbieraniu dowodów na to, że wszystkie wysiłki deweloperów włożone w wysokiej jakości oprogramowanie nie pójdą na marne.

Dlatego istnieje tak wiele różnych technik Product Discovery. Mamy techniki, aby lepiej rozumieć naszych użytkowników i klientów oraz walidować pomysły na produkty ilościowo i jakościowo. A większość tych technik nie zajmuje nawet czasu deweloperów (to ważne, ponieważ wiemy, ile czasu i wysiłku kosztuje wytwarzanie dobrej jakości).

Efektywna Product Discovery ma wiele wspólnego z uzyskaniem dostępu do klientów, a nie tylko z jak najszybszym wdrażaniem naszych eksperymentów z nowymi produktami.

Jeśli jesteś bardzo młodym startupem bez klientów, to oczywiście nie jest to tak naprawdę kwestia (i być może jest nawet za wcześnie na oprogramowanie w jakości produkcyjnej).

Większość z nas ma jednak prawdziwych klientów i prawdziwe przychody, dlatego musimy też o tym myśleć. Pisałem już o najważniejszych technikach szybkiego i odpowiedzialnego eksperymentowania z Product Discovery w ugruntowanych firmach.

Wiele z tych technik polega na przekonaniu niektórych naszych klientów lub potencjalnych klientów do przetestowania naszych nowych pomysłów na produkty (w jakikolwiek sposób). Program rozwoju klientów jest do tego szczególnie odpowiedni, ponieważ te osoby dobrowolnie zgłosiły się, aby być królikami doświadczalnymi. Możemy z nimi rozmawiać lub po prostu obserwować, jak próbują naszych pomysłów na produkty, albo pozwolić im przez chwilę testować nasze prototypy i zobaczyć, co z tego wychodzi.

Podsumowanie: Discovery vs. Delivery

Jeśli naprawdę chcesz odkrywać świetne produkty, niezwykle ważne jest wczesne i częste testowanie swoich pomysłów na prawdziwych użytkownikach i klientach. Jeśli chcesz dostarczać świetne produkty, powinieneś korzystać z najlepszych metod wytwarzania i starać się nie pomijać obaw inżynierów.

Kiedy chcemy szybko posuwać się naprzód i odkrywać nowe pomysły, korzystamy z metod discovery i angażujemy klientów. Gdy już ustalimy, jakie rozwiązanie powinniśmy opracować, pozwalamy deweloperom tworzyć oprogramowanie w jakości produkcyjnej – mogą je wtedy dostarczać z pełnym przekonaniem.

Tekst pochodzi z bloga Marty'ego Cagana i został przez nas przetłumaczony.