Ta dekompozycja produktowa jest (nawet jak na moje możliwości) bardzo długa, więc postanowiłem podzielić ją na 5 rozdziałów, które będą publikowane w odstępnach czasowych
Rozdział 1: Początki
Rozdział 2: Uciekający Product-Market Fit
Rozdział 3: Domknięcie Customer Journey (jesteś tutaj)
Rozdział 4: Lably
Rozdział 5: Nowe, nowe otwarcie
Nie wiem czy wiesz, ale piszę książkę pt. Produkt Nieskończony. Tutaj możesz dowiedzieć się więcej i dostać ją najszybciej (gdy już będzie gotowa).
Tutaj podcast na temat tego kejsu wynegerowany przez NotebookLLM:
Po wielu debatach i warsztatach dotarliśmy wreszcie do tego kim chcemy być, a to dało nam produktową klarowność. Zrozumieliśmy, że to czego chce użytkownik, to coś więcej niż tylko wygodne wkłucie w żyłę – to odpowiedź na pytanie, czy z jego zdrowiem jest wszystko w porządku.
Aby my to dać, musieliśmy najpierw rozwiązać problem, który wisiał nad organizacją od samego początku jej istnienia.
Panel wyników
uPacjenta od samego początku było budowane w partnerstwie z siecią laboratoriów Diagnostyka. To bardzo wygodna kooperacja, która spowodowała, że mogliśmy skupić się na aspekcie usługowym, pozostawiając partnerowi analizę dostarczonego materiału i odbiór wyników.
Zawsze chcieliśmy mieć własny panel odbioru wyników, ale ten oferowany przez Diagnostykę był wystarczający dobry, więc w niekończącej się walce z pożarami tworzenie własnego rozwiązania zawsze lądowało nisko w backlogu.
Niemniej, po warsztatach strategicznych w drugiej połowie 2022 dotarło do nas, że to ślepy zaułek. Nigdy nie posuniemy się do przodu produktowo, nigdy nie domkniemy naszego Customer Journey. Jeśli chcemy budować długotrwałych relacji z naszymi klientami, to musimy z nimi być podczas tego kluczowego etapu ścieżki jakim jest odbiór wyników.
Panel wyników MVP1
Naszym pierwszym ruchem było zmapowanie tego, jak obecnie nasi użytkownicy korzystają z obecnego rozwiązania. Proces wyglądał tak, że po pobraniu krwi na probówkę zostaje przyklejony kod identyfikacyjny, którego kopia trafia także na kartkę wielkości wizytówki. Probówka ląduje w walizce specjalistki medycznej, a wizytówka zostaje z pacjentem. Specjalistka w aplikacji uPacjenta rejestruje pacjenta i łączy ten kod z jego danymi osobowymi. Dzięki temu pacjent może jakiś czas później zalogować się do systemu a ten pokaże mu odpowiednie wyniki.
Budowanie nowego panelu odbywało się dwutorowo. Z jednej strony trwała intensywna analiza techniczna, aby zobaczyć w jaki sposób możemy budować niezależne rozwiązanie, ale na zewnętrznym API, a z drugiej strony odkrywanie tego, co potrzebują użytkownicy.
Analiza techniczna wykazała, że musimy sporo czasu przeznaczyć na prace architektoniczne, ale to nam dało jednocześnie bufor na pogłębienie insightów od użytkowników. Nasze wnioski badawcze wydają się po czasie oczywiste, ale podczas etapu “pustej kartki” były kluczowe.
Zadawaliśmy sobie na przykład pytanie o to, jak bardzo alarmistyczne ma być nasze oznaczanie wykroczenia parametru krwi poza normę? Czy dać użytkownikom listę wyników i zostawić im pracę interpretacji suchych danych?
A może wziąć na siebie ten ciężar i starać się zbudować narrację i podsumować wnioski oszczędzając czas naszego użytkownika?
Pierwsza opcja niczym by się nie różniła od dotychczasowego rozwiązania, natomiast druga brzmiała jako bardzo duży wysiłek technologiczny i medyczny – tymczasem my szukaliśmy dobrego balansu dla MVP1.
Po rundzie rozmów z dotychczasowymi użytkownikami zebraliśmy ich najważniejsze oczekiwania. Wyłonił nam się z tego jasny klucz wartości produktowych. Osoby po pobraniu krwi chcą:
- Jak najszybciej dostać informację o tym, że wyniki są już dostępne,
- Wyłowić w całej liście te wyniki, które są nieprawidłowe,
- Pokazać wyniki lekarzowi bez dostępu do panelu czy generalnie Internetu
Te trzy funkcje stanowiły dla nas scope dla MVP1 naszego panelu. Punkt 1 zrealizowaliśmy przez prosty mechanizm wysyłki SMS. Przy czym okazało się, że przy złożonych zestawach badaniach wyniki mogą pojawić się w różnym czasie (na przykład morfologia po 24 godzinach, a lipidogram 12 godzin później). Mieliśmy tutaj małą debatę zastanawiając się co jest dla userów ważniejsze:
- świadomość tego że już są pierwsze, “najszybsze” wyniki, a na resztę trzeba niestety poczekać,
- dostęp do całego zamówionej paczki, brak informacji o wynikach cząstkowych, co powoduje dłuższe oczekiwanie na pierwszą informację od nas.
Finalnie zdecydowaliśmy, że opcja a) jest lepsza, bo daje szybszą informację zwrotną, nawet jeśli jest niepełna. Wymusiło to jednak na nas konieczność dobudowania dodatkowego stanu, w którym pokazujemy nazwaną pozycję badania, ale jeszcze bez wartości liczbowej.
Drugi punkt naszego MVP to szybkie wyławianie nieprawidłowych wyników. Dotychczasowe panele z krwią wyświetlały listę albo z wartością liczbową bez pokazywania norm górnych i dolnych, albo z nimi i wtedy pacjent sam musiał wywnioskować, czy któryś parametr wykracza poza normę. Nowsze iteracje paneli zdrowotnych idą o krok dalej i podświetlają niepokojące parametry i w ten sposób wyróżniają je na liście.
My uznaliśmy, że to za mało. Nasze badania pokazały, że większość pacjentów odbiera swoje wyniki na telefonie, a biorąc pod uwagę, że lista badań jest zazwyczaj długa (sama podstawowa morfologia zawiera w sobie 28 parametrów) to oznacza dużo scrollowania. To z kolei spory wysiłek, aby wyłuskać te kilka najważniejszych informacji.
Dlatego dodaliśmy sekcję “Wyniki wymagające Twojej uwagi”, gdzie prezentujemy te pozycje, które odchodzą od normy. Ta sekcja znajduje się zawsze nad górze strony, ponad standardową listą, tak, aby była pierwszą rzeczą, jaką pacjent zobaczy.
Trzeci punkt naszego MVP to była dostęp offline. Do tej pory pacjenci dostawali wyniki w kilku oddzielnych plikach PDF, które były zapisane małym czarnych fontem, nierozróżnialnymi od siebie w podglądzie telefonu. Dlatego najpopularniejszy sposób to było robienie screenshotów na telefonie interesujących fragmentów bądź drukowanie całości i wkładanie do teczki.
Aby trochę ułatwić ten proces prowadziliśmy mechanizm, który konsoliduje wszystkie pliki w jeden zbiorczy PDF i zaprojektowaliśmy panel tak, aby robienie screenshotów było łatwiejsze, a odczytywanie możliwe bez powiększania PDFa.
Nasze MVP było mocno okrojone względem pierwotnych planów. Niemniej zderzenie nawet ograniczonej wersji z rzeczywistością jest zawsze lepsze niż teoretyzowanie i polerowanie na wszelki wypadek. W efekcie pierwsza wersja panelu pozwalała na odbiór pojedynczych wyników – bez możliwości zobaczenia historii badań, modyfikacji lub odwołania nadchodzących badań czy ponownego umówienia pobrania.
Dostarczenie MVP1 Panelu odbyło się w lipcu 2023, a jej stworzenie zajęło nam 9 miesięcy. Choć na powierzchni wyglądało jak coś niewielkiego, to pod spodem (technologicznie i organizacyjnie) było dla nas ogromnym skokiem biznesowym i fundamentem pod kolejną wersję.
Panel wyników MVP2: akcja integracja
Panel MVP1, choć okrojony funkcjonalnie, dał nam mnóstwo insightów i zdefiniował dalsze kroki. Potwierdziliśmy sobie, że dla naszych użytkowników nielogiczny jest podział na odbiór wyników i konto pacjenta, który u nas istniał ze względu na posługiwanie się wcześniej opisanym panelem dostarczanym przez partnera laboratoryjnego. Teraz jednak już potrafiliśmy odbierać te dane z zewnętrznego laboratorium. Nic nie stało na przeszkodzie, aby przejść do drugiej fazy planu: integracji z panelem pacjenta.
Musicie wiedzieć, że jestem uczulony na słowo “integracja” w kontekście technologicznym. Z mojego doświadczenia zmuszanie kilku różnie napisanych systemów do rozmowy ze sobą zawsze niesie za sobą ukryte problemy i kończy się gruntownym refactorem jednego z nich. Tak też było i tym razem.
Nasz pierwotny panel pacjenta wymagał całkowitej przebudowy, abyśmy mogli w niego wpleść wyniki badań. I jak to zazwyczaj bywa w takich sytuacjach, przebudowa zajmuje więcej czasu niż pierwotnie zakładały nasze plany. Po pierwsze, kod był na tyle stary, że zespół musiał odświeżyć sobie jego logikę „na żywym organizmie”. Po drugie – funkcje, które mi wydawały się drugorzędne (a więc mogły być zepchnięte na dalszy etap) okazały się kluczowe.
Czymś takim było właśnie anulowanie zamówionej wizyty. Sądziłem, że nasi użytkownicy nie będą z tego korzystać w panelu, bo o wiele łatwiej da się to zrobić telefonicznie. Ale okazało się, że elektronicznych odwołań jest bardzo dużo i usunięcie ich skutkowałoby czymś na kształt DDoS infolinii na własne życzenie.
Dalsza odkrywka pokazała, że dużą część anulacji to po prostu zmiana planów pacjenta, więc danie mu alternatywnych terminów wizyty jest w stanie uratować transakcję. To z kolei przełoży się na istotny wzrost przychodów.
To jednak nie wszystko. Anulowanie wizyty oznaczało ponowne “otwieranie” koszyka – więc skoro już przy tym jesteśmy, to może oprócz samego odwoływania wizyty dodamy też bardziej złożoną możliwość modyfikacji badanych parametrów? To ten sam kawałek kodu, a my możemy upiec dwie pieczenie na jednym ogniu. I faktycznie: istotna część wizyt była odwoływana ze względu na omyłkowo wybrane lub zapomniane parametry. Udostępnienie możliwości dobrania brakujących badań to kolejne uratowane koszyki. Zupełnie przy okazji dostaliśmy też świetny mechanizm do upsellingu.
Biorąc to wszystko razem zrozumieliśmy, że musimy zwiększyć zakres funkcjonalny MVP2 Panelu, aby wpleść także zarządzanie zbliżającą się wizytą. Wtedy rozwiążemy jednocześnie dwa problemy: przepiszemy bardzo istotny fragment kodu i jednocześnie spowodujemy, że ta inwestycja nam się bezpośrednio zwróci większą efektywnością procesową i dodatkowym źródłem przychodu.
Wynik to nie wszystko
Jednak nasz pierwszy krok w MVP2 był zupełnie inny. Nasze prace zaczęliśmy od dodania do wyników możliwości konsultacji online. Dlaczego? Widzieliśmy w danych, że użytkownicy spędzali bardzo dużo czasu w panelu. Długo zastanawialiśmy się dlaczego, skoro widzą wszystko czarno na białym.
Po dalszych eksploracjach okazało się, że sama wartość liczbowa badań to nie wszystko (co potwierdziło nasze inicjalne wnioski przy panelu pacjenta). Sam wynik nie mówi wprost, tego co chce usłyszeć pacjent. On chce zrozumieć, co ta liczba dla niego oznacza. Parametry medyczne mają swoje naukowe nazwy, jest ich dużo i te wartości liczbowe trzeba przełożyć na język użytkownika. Czy ma wykonać jakąś dodatkową akcję? Zmienić coś w swoim życiu? Umówić się do jakiegoś konkretnego lekarza? Zbadać coś kolejnego?
Znaleźliśmy na to dwa rozwiązania:
Pierwszym były dokładniejsze opisy wykonanych badań z informacją, po co mierzy się dany parametr wraz z normami i co oznacza ich wykroczenie. Drugim jest udostępnienie możliwości umówienia się na konsultacje online wprost z panelu.
Bezpieczeństwo
Największy problem jaki przed nami stał to kwestia autoryzacji. Odbierając pojedyncze wyniki wystarczy podać numer z karteczki otrzymanej podczas pobrania oraz datę urodzenia – nie trzeba zakładać konta. To jednak oznacza, że każde pobranie i wszystkie wyniki są oddzielnymi bytami, które siebie “nie widzą”.
Z jednej strony to duży plus, bo w ten sposób nie ma ryzyka wycieku danych, ale z drugiej oznacza, że musimy znaleźć sposób na agregację wyników tego samego pacjenta bez pogwałcenia zasad dostępu do danych personalnych.
Widzieliśmy kilka opcji rozwiązania tego problemu, ale te, które technicznie wydawały się najlogiczniejsze generowały ryzyka po stronie prawnej i bezpieczeństwa. Z kolei te najbezpieczniejsze, z „dmuchaniem na zimne” były UXowo koszmarne.
Podjęliśmy decyzję, aby iść drogą środka i udostępnić dwie opcje. Pacjenci dalej mogą zobaczyć swoje pojedyncze wyniki online bez logowania (tak jak było do tej pory). Alternatywnie mogą także zalogować się do panelu i po szybkiej weryfikacji otrzymują dostęp do swoich historycznych pobrań.
W ten sposób nie zmuszamy nikogo do wykonywania dodatkowych akcji: dalej wystarczy podanie kodu i danych osobowych, aby jednorazowo podejrzeć swoje wyniki. Pokazujemy jednak, o ile łatwiej jest być zautoryzowanym, bo wtedy wszystko można mieć w jednym miejscu. To odrobinę podobny mechanizm do zakupów w e-commerce bez zakładania konta.
Te prace zajęły nam najwięcej czasu, choć z perspektywy użytkownika końcowego są najmniej widoczne.
Co dalej?
Panel MVP2 był dużym krokiem, ale przede wszystkim enablerem dla kolejnej wersji, która wreszcie spełniłaby moją definicję dojrzałego systemu. Zdobyliśmy dużo doświadczenia i wiedzy zarówno od strony rynkowej jak i technologicznej. Nauczyliśmy się czego pragną użytkownicy, oraz z jakimi technologicznymi wyzwaniami się mierzymy.
Tworzenie interfejsu było bardziej złożone niż myśleliśmy, ponieważ wyniki wynikom nie są równe. Czasami jest tak, że jeden parametr to jedna liczbowa, ale czasami opis tekstowy. Innym razem z kolei to nie jest parametr, ale ich grupa, jak morfologia (która ma ich 10). Natomiast korzystanie z zewnętrznego API od zaufanego partnera powinno być w teorii proste, ale w praktyce teoria różni się od praktyki.
Po prostu mnóstwa rzeczy nie wiedzieliśmy. I nie mogliśmy wiedzieć bez rozpoznania bojem.
Te wnioski pozwoliły przygotować MVP3, którego pierwsze efekty (jak możliwość ponownego zamówienia badania) widać już teraz na stronie Portalu Pacjenta.
-==:Koniec części trzeciej:==-
3 komentarze do “Jak ewoluowała strategia produktowa uPacjenta. Rozdział 3: Domknięcie Customer Journey”