Prośba o funkcję, którą naprawdę powinieneś zbudować (i jak ją rozpoznać)

Wiesz, jak mówić nie złym prośbom o funkcje. Nauczyłeś się odróżniać rozrost zakresu od kluczowych funkcji. Chronisz granice swojego produktu.

Ale teraz jesteś w innej kropce: masz tuzin próśb, które wszystkie przechodzą test. Wszystkie są do Twojej aplikacji. Wszystkie są rozsądne. Wszystkie to rzeczy, których Twoi użytkownicy naprawdę chcą. Ale możesz zbudować tylko trzy z nich.

Które trzy?

Tu właśnie większość decyzji produktowych idzie nie tak. Founderzy wybierają te, które brzmią najbardziej imponująco, albo najbardziej dochodowo, albo te, które przyszły od ich najważniejszego klienta. Czasem mają rację. Zwykle się mylą.

Sygnały, które się liczą

Sygnał 1: Niewymuszone powtórzenie

Jeśli trzech osobnych użytkowników prosi o to samo, nie rozmawiając ze sobą, to sygnał. Nie skoordynowali się. Wszyscy po prostu na to wpadli. Jeśli pięciu użytkowników o to prosi, to nie przypadek — to autentyczna potrzeba.

Odwrotność jest ważna: jeśli jeden użytkownik prosi i nikt inny tego nie robi, a Ty to budujesz, to teraz utrzymujesz funkcję, której nikt inny nie używa, a ten jeden użytkownik wciąż może być nieszczęśliwy (bo zbudowałeś ją trochę nie tak).

Licz prośby, zanim zbudujesz. Nie te od najgłośniejszego klienta czy największego klienta — licz niewymuszone powtórzenie. Dwóch czy trzech niezależnych użytkowników proszących o to samo to dużo mocniejszy sygnał niż jeden ważny klient proszący o pięć rzeczy.

Sygnał 2: Obejście ma znaczenie

Jeśli masz użytkowników i zostają oni mimo że funkcji brakuje, znaleźli obejście. Może robią to poza Twoją aplikacją. Może robią to ręcznie. Może używają innego narzędzia równolegle.

Ale zostają, co oznacza, że nie potrzebują tej funkcji, by używać Twojej aplikacji. Potrzebują jej, by używać Twojej aplikacji lepiej. To różnica od blokera.

Funkcje, które liczą się najbardziej, to te, które powstrzymują ludzi od używania Twojej aplikacji w ogóle. Funkcje, które są miłym dodatkiem, to te, które ludzie obchodzą.

Zwracaj uwagę, które prośby są blokerami. Ktoś mówi „nie mogę tego używać, dopóki nie zrobisz X” kontra ktoś mówi „byłoby świetnie, gdybyś miał X”. To rozróżnienie jest na wagę złota.

Sygnał 3: Funkcja łączy się z modelem biznesowym

Niektóre funkcje odblokowują zupełnie nowe sposoby zarabiania. „Fakturuj moich klientów” odblokowuje model biznesowy, w którym pobierasz opłatę za fakturowanie. „Eksport do Salesforce” odblokowuje przychody z integracji. „White-label dla resellerów” odblokowuje kanał partnerski.

Ale oto sztuczka: nie wiesz, czy te modele zadziałają, dopóki już nie wypuszczasz. Nie możesz planować wokół nich. Możesz je tylko zauważyć po wypuszczeniu i zobaczeniu, czy ludzie faktycznie ich używają.

Najbardziej udane dodatki funkcji to te, gdzie wypuszczenie funkcji odkrywa rynek, o którego istnieniu nie wiedziałeś. Zbudowałeś eksport. Okazuje się, że firmy chcą osadzić Twój eksport w swoim przepływie pracy. Teraz masz historię integracji, której nie planowałeś.

Buduj funkcje, bo Twoi użytkownicy ich potrzebują. Potem obserwuj, czy Twoi użytkownicy potrzebują ich w sposób, który tworzy nowy biznes. Nie przewiduj modelu biznesowego najpierw.

Sygnał 4: Prośba o pomoc

Jeśli użytkownik prosi Cię, byś coś zbudował, to prośba. Jeśli użytkownik pyta, czy mógłbyś coś zbudować, i oferuje pomoc w testowaniu, to coś innego.

Ludzie, którzy oferują pomoc w testowaniu, to ludzie zaangażowani w rezultat. Będą używać funkcji uważnie. Będą zgłaszać błędy. Powiedzą Ci, czy naprawdę rozwiązuje ich problem.

Ludzie, którzy tylko proszą, to ludzie liczący, że magicznie zbudujesz to, co sobie wyobrażają. Czasem tak będzie. Często nie.

Buduj najpierw z testerami. Wszystko inne jest drugorzędne.

Pokusa, by zbudować prestiżową funkcję

Każdy produkt ma jedną funkcję, która, jeśli ją wypuścisz, sprawia, że brzmisz bardziej imponująco. Dla aplikacji do planowania to integracja z Calendly. Dla aplikacji do zadań to integracja ze Slackiem. Wszyscy wiedzą, co to jest. Wszyscy ich chcą.

Oto rzecz: wszyscy też dostają je od kogoś innego. Jeśli Twoja funkcja nie jest najlepszą, najłatwiejszą integracją ze Slackiem, po prostu dodaje złożoności Twojej aplikacji, nie czyniąc Cię sławnym.

Funkcje, które czynią Cię sławnym, to te, które jesteś wyjątkowo predysponowany zbudować, bo rozumiesz problemy swoich konkretnych użytkowników lepiej niż ktokolwiek inny. To nie są prestiżowe funkcje. To nudne funkcje, które rozwiązują prawdziwe problemy prawdziwych ludzi.

Integracja ze Slackiem jest imponująca. Narzędzie, które pozwala Twoim użytkownikom zrobić jedną konkretną rzecz dużo szybciej, niż Slack kiedykolwiek o tym pomyślał, jest wartościowe.

Jak faktycznie zdecydować

Gdy masz partię próśb o funkcje, które wszystkie przechodzą test „czy to jest w zakresie?”, uszereguj je według:

1. Ilu użytkowników poprosiło (niezależnie)? Więcej jest lepiej.
2. Czy to bloker czy miły dodatek? Blokery są pilniejsze.
3. Czy Twoi użytkownicy mogą to dziś obejść? Jeśli nie, jest ważniejsze.
4. Czy ktoś pomoże Ci to przetestować? Jeśli tak, zbuduj to najpierw.
5. Czy to odkryje nowy rynek? Jeśli może, to bonus, nie powód.

Potem buduj w tej kolejności. Nie w kolejności imponującego brzmienia. Nie w kolejności Twojego największego klienta. W kolejności faktycznego sygnału od ludzi używających Twojej aplikacji.

Funkcja, której (jeszcze) nie zbudujesz

Będziesz mieć prośby, które nie przejdą selekcji. Nie udawaj, że zbudujesz je kiedyś. Powiedz użytkownikowi: „Nie budujemy tego teraz. Oto dlaczego. Oto co budujemy. Oto alternatywa, która może Ci zadziałać”.

Ta szczerość ma większe znaczenie, niż myślisz. Użytkownicy woleliby wiedzieć, że tego nie zrobisz, niż czekać sześć miesięcy z nadzieją.

I czasem, gdy już powiedziałeś nie, użytkownik znajduje obejście albo inne narzędzie, albo rozwiązuje problem inaczej. To w porządku. Nie możesz być wszystkim dla wszystkich.

Produkty, które wygrywają, to te, które dobrze wykonują swoje zadanie i uważnie słuchają, czego użytkownicy naprawdę potrzebują, a nie te, które próbują być wszystkim i kończą jako nic.