Użyteczny problem jest dość duży lub dość częsty

Pulpit pięknie wygląda podczas prezentacji. W tym ilustracyjnym przypadku znajduje błąd formatowania w miesięcznym eksporcie. Poprawka zajmuje dwie minuty, a błąd zdarza się dwa razy w roku. Wszystkim podoba się pokaz; po okresie próbnym nikt już nie otwiera pulpitu.

Problem da się opisać, lecz koszt życia z nim może być niższy niż koszt dodania kolejnego narzędzia. Sama elegancja nie tworzy pilnej potrzeby.

Zarejestrowana rozmowa o produktach proponuje użyteczny test dwóch osi: uważaj na problem jednocześnie drobny i rzadki. Duży problem może zasługiwać na uwagę nawet wtedy, gdy pojawia się sporadycznie. Mały, ale powtarzalny może przerodzić się w codzienny nawyk. Chodzi o zbadanie pracy ukrytej za ofertą.

Oddziel częstość od konsekwencji

„Ile osób ma ten problem?” to zbyt szerokie pytanie na początek. Zapytaj konkretny zespół, kiedy ostatnio się pojawił i co nastąpiło potem. Czy ktoś stracił kilka minut, sprzedaż, opóźnił zamówienie, ujawnił prywatne dane, czy tylko zauważył niedogodność? Tych konsekwencji nie można traktować jednakowo.

Następnie zapytaj, jak często zdarza się ta sama klasa sytuacji. Cotygodniowa pięciominutowa poprawka może zabierać zaskakująco dużo czasu w dużym zespole. Coroczna awaria może być ważna, jeśli blokuje krytyczny transfer. Dwuminutowa uciążliwość dwa razy do roku trudniej uzasadnia osobny produkt.

Rozważ ilustracyjne rozróżnienie na obu osiach:

Pola są wskazówkami do badania, a nie wyrokami o rynku. „Wysoki koszt” zależy od tego, czyj koszt liczysz. Błąd ledwie widoczny dla administratora może poważnie dotknąć klienta. Awaria, której nie było w krótkim wywiadzie, może być kluczowa w sezonie.

Drobny błąd w demo może być wielkim błędem w systemie

W integracjach widać to szczególnie wyraźnie. Błędna wartość pola wygląda niegroźnie na jednym kontakcie. Jeśli jednak to samo mapowanie zostanie zastosowane do tysięcy kontaktów, powstaje powtarzalne źródło ręcznych poprawek. Z drugiej strony rozbudowany alarm dla jednorazowej kosmetycznej niezgodności może wymagać więcej obsługi, niż oszczędza.

Poradnik integracji narzędzi biznesowych zaczyna od procesu i źródła prawdy, bo rzeczywisty koszt tkwi w sposobie przepływu i wykorzystania rekordów. Zespół rozważający, czy przejść z darmowych narzędzi na płatne, powinien podobnie policzyć obejścia i pominięte działania, a nie tylko porównać listy funkcji.

Poproś o trzy ostatnie rzeczywiste wystąpienia. Dla każdego zapisz, kto je zauważył, kto naprawił, jaka inna praca stanęła i co by się stało bez interwencji. Ostatnie pytanie odróżnia uciążliwość od niewidocznego ryzyka. Zapobiega też zamianie efektownego scenariusza hipotetycznego w rzekomo zmierzony wzorzec.

Zapytaj następnie, ile kosztuje obecne obejście. Arkusz i pięciominutowa kontrola mogą w zupełności wystarczać. Ręczny proces, w którym specjalista co rano uzgadnia rekordy, może już nie wystarczać. Alternatywa jest częścią wartości produktu; nie należy jej ukrywać.

Testuj koszt wdrożenia obok kosztu problemu

Nawet ważny problem może nie uzasadniać nowej aplikacji. Ktoś musi ją połączyć z innymi systemami, nauczyć się jej używać, sprawdzać wyniki i utrzymywać dostęp. Jeśli produkt kosztuje więcej uwagi niż zadanie, kupujący może rozsądnie pozostać przy obecnym obejściu.

Rozmowa źródłowa ostrzega również, że ręczna pomoc przy konfiguracji może zawyżać pozorne zainteresowanie na początku. Zespół wygląda, jakby kupował oprogramowanie, choć w istocie polega na niewycenionym doradztwie. Mały problem z drogim wdrożeniem szczególnie trudno obsłużyć w sposób trwały. Nie zakazuje to usługi; wymaga policzenia jej kosztu.

Od testu dwóch osi są wyjątki. Obowiązki prawne mogą wymagać działania, nawet gdy obserwowane incydenty są rzadkie. Nowy rynek może nie mieć historii do pomiaru. Niszowa grupa może odczuwać problem dostatecznie mocno, choć większość populacji nie. W takich sytuacjach szukaj dowodów w obowiązkach, wiarygodnych scenariuszach awarii lub zatwierdzonych budżetach, a nie tylko w oszacowanej częstości.

Osie pomagają też zdecydować, czy potrzeba zasługuje na własny produkt, czy na niewielką funkcję w narzędziu, którego ludzie już używają. Rzadki drobny błąd formatowania może uzasadniać przycisk w procesie eksportu, choć nikt nie wykupiłby osobnej usługi. Częsty mały problem może najlepiej rozwiązać zmiana ustawienia domyślnego, a nie sprzedaż kolejnego pulpitu. Zakres produktu powinien odpowiadać uwadze, jaką zadanie już pochłania. Pytanie brzmi nie tylko, czy problem istnieje, lecz jakiej nowej zmiany zachowania można rozsądnie wymagać, by go rozwiązać.

Użyteczne pytanie badawcze nie brzmi „Czy używałbyś tego?”. Brzmi: „Opowiedz o ostatnim razie, gdy to się zdarzyło, ile kosztowało i co zrobiliście zamiast tego”. Produkt ma rację bytu, gdy odpowiedź wskazuje na pracę, którą ludzie już próbują zmienić.