Ponieważ praktyka budowania MVP stała się bardziej akceptowana w zespołach w firmie Microsoft, napotkałem szereg typowych zastrzeżeń:
Zarzut: nasi klienci mają wobec nas większe oczekiwania, więc nie możemy zapewnić MVP.
Odpowiedź: MVP nie oznacza, że zapewniamy zepsute doświadczenie. Projekt i funkcjonalność mogą być wysokiej jakości; po prostu obsługujemy mniej przypadków użycia. Jeśli nasza hipoteza jest słuszna, teraz dostarczamy naszym klientom pewną wartość, a później dodamy więcej. Jeśli nasza hipoteza nie jest poprawna, dostarczamy małą funkcję, która nie jest wartościowa, zamiast dużej funkcji, która nadal nie jest wartościowa. W rzeczywistości całkowicie przestałem używać terminu „minimalny opłacalny produkt” podczas rozmów z wewnętrznymi zespołami Microsoft. Wyjaśnienie, że MVP nie jest synonimem podpunktu, zajęło po prostu zbyt dużo czasu. Zamiast tego określam to, co robimy, jako „rozwój oparty na hipotezach”, który kładzie nacisk na walidację pomysłów, a nie na jakość produktu.
Sprzeciw: musimy wspierać wszystkie platformy.
Odpowiedź: Jeśli stworzyliśmy funkcję tylko dla Androida i nikt jej nie używał, czy nie powinniśmy czuć się źle, że nie stworzyliśmy tej samej bezużytecznej funkcji dla iOS i Windows Phone oraz MacOS i Windows 8? Zakładając dobre testy funkcji, możemy szybko dodać ją na wszystkie inne platformy.
Sprzeciw: musimy objąć miliony użytkowników.
Odpowiedź: Weryfikujemy produkt na podzbiorze naszych klientów. Jeśli tylko tysiące klientów ma dostęp do produktu, wystarczy, że będzie on wystarczająco wydajny, aby obsługiwać tysiące klientów. To marnotrawstwo zasobów inżynieryjnych, aby przeprojektować produkt, którego klienci mogą nigdy nie kupić. Zakładając, że zweryfikujemy zapotrzebowanie klientów, możemy zwiększyć wydajność przed otwarciem dostępu do całej naszej bazy klientów.
Zastrzeżenie: nie ma mniejszego zestawu funkcji, które zadowolą naszych klientów.
Odpowiedź: to nie jedyne wydanie, jakie kiedykolwiek wydamy. Zastanówmy się, jak możemy zapewnić największą wartość przy najmniejszej inwestycji czasu. Czy z niektórych funkcji korzysta większy procent klientów niż inni? Czy niektóre funkcje są używane codziennie, a inne co tydzień lub rzadziej? Rozpoczynając od funkcji o najwyższym priorytecie, możemy szybko uczyć się i weryfikować nasze pomysły. Gdy klienci żądają brakujących funkcji, możemy ich użyć, aby pomóc nam ustalić priorytety w kolejności ich tworzenia.
Zarzut: nie możemy wprowadzić niespójności do projektu.
Odpowiedź: Utrzymanie spójności projektu jest niezwykle ryzykowne. Oznacza to albo stagnację przez długi czas, albo inwestowanie w kosztowne, pełne przeprojektowanie, które może faktycznie zaszkodzić użytkowaniu i użyteczności. Trudno nam też nadać priorytet zmianom w projekcie nad nowymi funkcjami. Jeśli uda nam się wykazać, że niewielka zmiana projektu w wymierny sposób pomaga klientom w korzystaniu z naszego produktu, łatwiej będzie nam argumentować o dodatkowych ulepszeniach projektu w pozostałej części produktu. Z mojego doświadczenia wynika, że te odpowiedzi pomagają kontynuować rozmowę. Nie gwarantują, że Twój zespół produktowy skutecznie przezwycięży wszystkie zastrzeżenia i będzie w stanie zbudować MVP. W dużej firmie niezwykle trudno jest pokonać wszystkie czynniki, które mogą przeszkadzać w ćwiczeniu rozwoju klienta. Mimo to każdy mały sukces stanowi dowód dla następnego zespołu projektowego, że ta metoda rozwoju działa w celu zmniejszenia ryzyka i tworzenia lepszych produktów.