Pułapka rozrostu zakresu: jak mówić nie funkcjom, które brzmią dobrze, ale wcale takie nie są
Zbudowałeś coś, co użytkownicy uwielbiają. Teraz chcą funkcji, które brzmią rozsądnie, ale poprowadziłyby aplikację w dziesięciu różnych kierunkach. Oto jak zdecydować, które prośby zrealizować, a które grzecznie odrzucić.
Wypuściłeś aplikację. Użytkownicy się pojawili. A teraz Twoja skrzynka jest pełna próśb o funkcje, które wszystkie brzmią jak dobre pomysły.
„Czy możemy dodać eksport do Excela?”. Rozsądne. „Czy faktury mogą być wysyłane automatycznie?”. Ma sens. „Czy możemy zintegrować ze Stripe?”. Tam mieszkają prawdziwe pieniądze. „Czy możesz dodać aplikację mobilną?”. Wszyscy o to proszą. „Czy możemy wystawiać to pod własną marką dla naszych klientów?”. O, teraz mamy model biznesowy.
Każda prośba z osobna brzmi mądrze. Razem brzmią, jakbyś budował pięć różnych produktów.
To rozrost zakresu (scope creep) i zabija on więcej małych aplikacji zbudowanych z AI, niż kiedykolwiek zrobiły to problemy techniczne. Nie dlatego, że budujesz te funkcje — ale dlatego, że kończy Ci się czas, pieniądze albo zdrowy rozsądek przy próbach.
Jak rozrost zakresu zabija działającą aplikację
Oto co się dzieje. Mówisz tak pierwszym trzem prośbom, bo wydają się rozsądne. Prosisz swojego kreatora AI, by je dodał. Zajmuje to dwa tygodnie zamiast jednego, bo każda nowa funkcja wpada na istniejący kod. Teraz masz aplikację, która robi pięć rzeczy, trzy z nich dobrze, a dwie tak sobie.
Potem przychodzi prośba czwarta: „Czy możemy mieć różne poziomy uprawnień?”. Nagle musisz przemyśleć, kto co widzi na każdym ekranie. To nie funkcja; to zmiana architektury. Prosisz swojego kreatora AI, by to zrobił. Dotyka wszystkiego. Dwa tygodnie stają się trzema. Aplikacja zwalnia, bo dodałeś logikę do każdego widoku.
Przy prośbie ósmej przestałeś wypuszczać nowe rzeczy dla swoich pierwotnych użytkowników, bo jesteś zbyt zajęty utrzymywaniem w ruchu maszynki próśb o funkcje. Ludzie, którzy uwielbiali aplikację trzy miesiące temu, są sfrustrowani, bo nic, o co prosili, nie jest skończone. Ludzie składający nowe prośby są sfrustrowani, bo funkcje powstają w nieskończoność.
Zbudowałeś coś, co działa. Zepsułeś to, próbując być wszystkim.
Schemat decyzyjny
Potrzebujesz bramki. Każda prośba o funkcję przechodzi przez trzy pytania:
Pytanie 1: Czy to należy do tej aplikacji, czy to inna aplikacja?
Twoja pierwsza aplikacja robi jedną rzecz naprawdę dobrze. Aplikacja do planowania planuje rzeczy. Aplikacja do fakturowania fakturuje. To różne aplikacje. Jeśli ktoś prosi Twoją aplikację do planowania, by fakturowała, nie dodajesz funkcji — prosisz aplikację do planowania, by zajęła się księgowością. To inny produkt.
Dobry test: „Gdybym wziął tę funkcję i wypuścił ją samodzielnie, czy ludzie chcieliby ją kupić?”. Jeśli tak, prawdopodobnie należy do innej aplikacji. Jeśli odpowiedź brzmi „nie, ma sens tylko jako część większej całości”, to budujesz właściwy zakres.
Dostaniesz prośby w stylu „zintegruj z naszym CRM-em”. To, co to naprawdę oznacza, to „bądź własnym CRM-em”. To inna aplikacja. Możesz zintegrować z CRM-em później. Nie możesz dodać funkcji wartości całego CRM-a, nie stając się CRM-em.
Pytanie 2: Czy to rozwiązuje problem większości Twoich użytkowników, czy tylko tego jednego?
Jeden klient uwielbia Twoją aplikację i ma pomysł na funkcję. To prawdziwy problem, który ma. To też prawdziwy problem, który ma tylko on.
Jeśli masz dwudziestu użytkowników i jeden o coś prosi, sprawdź: czy pozostała dziewiętnastka też na to czeka, czy tej osobie po prostu to przyszło do głowy? Możesz zapytać ich wprost: „Zanim do mnie napisałeś, pomyślałeś, by zapytać kogokolwiek innego, czy tego potrzebuje?”. Zwykle odpowiedź brzmi nie.
To niebezpieczne pytanie, bo ten jeden proszący klient może być Twoim najważniejszym klientem. Możesz potrzebować utrzymać go zadowolonym. To decyzja biznesowa, nie produktowa. Ale wchodź w to z otwartymi oczami: jeśli budujesz coś dla jednego klienta, nie rozwijasz swojej aplikacji, budujesz praktykę konsultingową.
Pytanie 3: Ile to kosztuje i jaki to koszt dla pierwotnego pomysłu?
Wszystko coś kosztuje. Eksport do Excela kosztuje Cię czas inżynieryjny. Kosztuje Twoją aplikację złożoność. Kosztuje skupienie. Zbuduj to zamiast optymalizacji wydajności, na którą Twoi użytkownicy narzekają codziennie, a dokonałeś wyboru.
Pytaj konkretnie: „Jeśli to zbuduję, czego nie zbuduję?”. Jeśli odpowiedź brzmi „niczego, mamy nieskończony czas”, nie jesteś szczery. Nie mamy. Czas jest skończony.
Koszt dla pierwotnego pomysłu jest często niewidoczny. Gdy jesteś po uszy w prośbach o funkcje, przestajesz utrzymywać tę kluczową rzecz, którą ludzie w Tobie pokochali. Rdzeń się spowalnia. Rdzeń robi się bardziej zabugowany. Rdzeń wydaje się zaniedbany. I w końcu ludzie odchodzą, bo aplikacja, która działała świetnie, teraz działa tak sobie i robi rzeczy, do których nigdy nie była zaprojektowana.
Prawdziwy przykład: formularz zgłoszeniowy
Ktoś zbudował prosty formularz zgłoszeniowy dla klientów. Klienci go wypełniają, trener go przegląda, umawiają się. To jest ta aplikacja.
Prośba pierwsza: „Czy mogę oznaczać pilne zgłoszenia?”. Tak, to wariacja kluczowego przepływu. Zbuduj.
Prośba druga: „Czy mogę eksportować zgłoszenia do Excela dla moich archiwów?”. To funkcja dokumentowa. To nie zadanie aplikacji. Zgłoszenia żyją w aplikacji. Jeśli potrzebują Excela, mogą skopiować i wkleić. Ale dobrze, eksport może mieć sens jako udogodnienie. Zbuduj.
Prośba trzecia: „Czy zgłoszenia mogą automatycznie tworzyć wydarzenia w kalendarzu?”. Teraz zajmujesz się planowaniem. Aplikacja była do zgłoszeń, nie do planowania. Jeśli ktoś chce obu, prawdopodobnie chce prawdziwego systemu planowania, nie prowizorki dokleonej z boku. Grzecznie odmów.
Prośba czwarta: „Czy trenerzy mogą wysyłać przypomnienia po zgłoszeniu przez SMS?”. Teraz jesteś systemem komunikacji. Nie.
Przy prośbie trzeciej uderzyłeś w granicę. Aplikacja to zgłoszenia. Wszystko inne to inna aplikacja. Możesz zintegrować z tamtymi aplikacjami później. Nie możesz ich dodać, nie stając się tamtymi aplikacjami.
Jak mówić nie
Najtrudniejszą częścią jest faktyczne powiedzenie tego. Nie chcesz frustrować swoich użytkowników.
Bądź szczery: „To świetny pomysł, ale to inny produkt niż to, co tu budujemy. To, co budujemy, to [Twoje jedno zadanie]. Jeśli spróbujemy robić planowanie, fakturowanie czy rzeczy CRM-owe, będziemy w nich wszystkich tak sobie, a w żadnym świetni”.
Często klient zrozumie. Zapytał, bo pomysł mu przyszedł do głowy, nie dlatego, że Cię testuje.
Czasem będzie naciskał. „Ale potrzebuję obu”. To moment, gdy polecasz: użyj prawdziwej aplikacji do planowania. Użyj prawdziwej aplikacji do fakturowania. Użyj prawdziwego CRM-a. Potem użyj tej aplikacji do tego, co robi dobrze. To uczciwa odpowiedź.
Pokusa, by być wszystkim
Najtrudniejszą częścią budowania małego produktu jest mówienie nie. Nie wydaje się zostawianiem pieniędzy na stole. A co, jeśli ten klient naprawdę zapłaciłby za oba? A co, jeśli ta funkcja uczyniłaby Cię dziesięć razy większym?
Może. Ale nie jesteś dziesięć razy większym produktem, jeśli go nie wypuścisz. Jesteś półskończonym produktem, który robi pięć rzeczy źle. Ludzie, którzy pokochali rdzeń, są sfrustrowani. Ludzie, którzy chcieli nowych funkcji, są sfrustrowani. A Ty zapędziłeś się w kozi róg, gdzie dodanie czegokolwiek nowego oznacza najpierw refaktoryzację pięciu starych rzeczy.
Produkty, które rosną, to te, które robią jedno zadanie naprawdę dobrze, a potem dodają ostrożnie. Nie próbują być Salesforce od pierwszego dnia. To aplikacja, po którą sięgasz, gdy musisz zrobić tę jedną rzecz, i aplikacja, której ufasz, że będzie szybka i niezawodna, gdy to robisz.
Mów nie. Chroń rdzeń. Zrób to, a zbudujesz coś, czego ludzie naprawdę chcą używać.