Czy klient ma zawsze rację?

Popularna fraza-wytrych: „Klient ma zawsze rację”. Ostatnio trafiłem na nią przy narzekaniach na wielkie systemy IT, które wyglądają jakby nigdy nie chciały do końca działać zgodnie z oczekiwaniami.

No i konkluzja (choć w środku wypowiedzi): „Dlaczego X wygrywa? Bo klient ma zawsze rację…” i sugestia, że firma X faktycznie słucha klientów.

Otóż, uwaga – przyznam się Wam do czegoś: uważam, że to nie prawda. Powiem nawet więcej: pogląd, że klient ma zawsze rację jest bardzo niebezpieczny.

Sama fraza wywodzi się z amerykańskich metod prowadzenia biznesu z XIX wieku (dziewiętnastego wieku!) i dotyczyła sposobu interakcji między kupującym a sprzedającym – szczególnie w pierwszych dużych domach handlowych, sieciach sklepów i hoteli (źródło)

Ale tak jak druga poprawka do amerykańskiej konstytucji nie przewidziała, że kiedyś pojawi się broń pół-automatyczna, tak powyższe motto nie przystaje do obecnych czasów.

Po pierwsze:

„Klient ma zawsze rację” odnosi się do interakcji między dwoma osobami – obsługiwanego (klienta) i obsługującego (sprzedającego). Sprawdza się dobrze (także do tej pory), jeśli relacja faktycznie jest personalna, jeden na jeden. Gdy jednak zarządza się usługą lub produktem o znacznej skali to spełnianie zachcianek wszystkich klientów staje się kakofonią sprzecznych opinii. A w przypadku produktów cyfrowych to idzie jeszcze dalej: matematyka często podpowiada, że lepiej jest zyskać nowego klienta niż stracić niezadowolonego. Get over it.

Po drugie:

Poddańcze słuchanie klientów prowadzi do tworzenia produktów-choinek: mnóstwo funkcji, kombinacji, możliwości, które wydawały się fajne, ale gdy doszło do realizacji to nikt lub prawie nikt z nich nie korzysta.

Dlaczego tak się dzieje? Bo użytkownicy mówią co myślą, a nie mówią co robią. Każdy z nich zapytany będzie chciał filtry, sortowanie, podpowiedzi – wszystko co teoretycznie brzmi jakby dawało większą kontrolę i ułatwia działanie w tym jednym konkretnym przypadku. Gdy jednak dochodzi do finalizacji to to, co miało ułatwiać – zaciemniają i komplikują w codziennym używaniu.

Użytkownik bowiem operuje na wysokim poziomie abstrakcji bo nie widzi wewnętrznej złożoności produktu ani zespołu, który nad nim pracuje. Nie ma w tym nic złego, użytkownika nie musi to obchodzić. Problem jest jednak w tym, że taka nieprecyjna opinia z naklejką „klient ma zawsze rację” powoduje tworzenie nieprecyzyjnych rozwiązań przez co ostatecznie tracą wszyscy.

Po trzecie:

Zbyt bezkrytyczne słuchanie klientów jest niebezpieczne biznesowo. Czytelnicy Innovators Dilemma Claytona Christiensena wiedzą o czym mówię: firmy, które pierwsze stają się ofiarą innowacyji, to te, które zbyt mocno uczepiły się opinii klientów przez to tworzą coraz mocniejsze, szybsze, dokładniejsze rozwiązania zamiast szukać nowego podejścia. W tym czasie od spodu zaczyna je podgryzać konkurencja, która jest tylko „good enough”, ale klienci widząc nowe, przełomowe rozwiązanie i bezceremonialnie opuszczają wsłuchujące się w nich firmy. Więcej o tym pisałem tutaj.

19FA7A6F-BA61-44DC-BCBE-6CBE06B4AC1C-3413-0000064868F9D6F6

Co więc z tym zrobić? Jedyne sensowne rozwiązanie to selektywne słuchanie. Balansowanie między intuicją a sygnałami z rynku. Krytyczne obserwowanie obydwu.

Pamiętajcie, że klient nie ma wobec Waszego produktu żadnych obowiązków. To Wy macie obowiązek dbać i o klienta, i o produkt. Odpowiedzialność jest ostatecznie po Waszej stronie, więc nie pozwólcie, aby stery w samolocie przejęli pasażerowie.

To, czego nie widać

Empiryzm zakłada, że źródłem poznania są doświadczenie. Doświadczenie są lepsze od idei, bo opiera się na sprawdzalnej, materialnej rzeczywistości.

To właśnie empiryzm leży u podstaw metodyk zwinnych, ze swoim słynnym „inspect and adapt”.

Empiryzm poznawczy trafia jednak na powien problem. Wprawdzie teoretycznie wszystko, co materialne można poznać empirycznie, ale nie do wszystkiego mamy (i chcemy mieć) praktyczny dostęp – to jednak nie powstrzymuje nas przed wydawaniem opinii.

Patrzenie tylko na powierzchnię wystarcza, aby mieć swój osąd. Ale pod spodem jest to, czego nie widać – węwnetrzna złożoność, która umyka.

Na własnej skórze się o tym przekonałem pracując nad PizzaPortal, gdy po roku pracy w zespole kilkanastu osób w trzech krajach zostałem skrytykowany za brak funkcji, która przecież jest łatwa we wdrożeniu. Ten sam mechanizm widziałem dzisiaj jak wypuściliśmy stronę zamow.itaxi.pl, gdzie dostaliśmy sugestię dodania kilku linijek kodu, aby strona lepiej wyglądała na komputerze.

Z perspektywy krytykującego to oczywista sprawa i szybka poprawka. Dla nas w sumie też, ale poza samym kodem musimy brać pod uwagę także:

  • zaplanowaną listę funkcji do wdrożenia,
  • ustalone priorytety biznesowe,
  • konkretną grupę docelową w głowie,
  • dług technologiczny, którym trzeba zarządzać,
  • uzgodniony proces testowania i akceptacji kodu,
  • dostępność zespołu programistycznego,
  • konieczność skupienia na tym, co jest dla nas najważniejsze,

… oraz kilka innych czynników, z których żaden nie jest widoczny na powierzchni (i nie powinien być).

1a66d8e4-fc83-40dc-9bbc-c19d0ed93197-501-000001b4dc0b29f5_tmp
xkcd tłumaczy to najlepiej

Często łapię się na tym, że krytykuję bezsensowne rozwiązania w różnych usługach. Zawsze z zewnątrz wydają się idiotyczne, ale gdy przepuszczam je przez filtr własnych doświadczeń to odechciewa mi się obgadywać je publicznie. Bo wiem, że efekt końcowy to wypadkowa decyzji i priorytetów, które są dla mnie niewidoczne.

Podobnie się czuję, gdy planuję nową super funkcję i ta wydaje się bardzo prosta do czasu konsultacji z zespołem, który odkrywa przede mną wewnętrzną złożoność problemów jakie nas czekają przy implementacji.

Rzeczy wydają się proste, gdy nie patrzy się na nie wystarczająco głęboko.

Długie ogony

Jesteśmy przyzwyczajeni do myślenia o długim ogonie jako czymś jednoznacznie pozytywnym.

Długi ogon daje nadzieje na znalezienie sobie niszy, która jest zbyt mała dla wielkich danego rynku, aby była interesująca, ale wystarczająco duża, aby zwalidować nową ideę biznesową bez realnej konkrencji. Mikrodziałalności mogą nawet nigdy z takiej niszy nie wyjść i ciągle satysfakcjonująco funkcjonować dzięki katalizującej roli Internetu i postępującemu minimalizowaniu kosztów marginalnych.


Długie ogony mają jednak swoją drugą stronę. Takiemu rozkładowi ulegają także elementy, których (technologiczna) obsługa może być nieproporcjonalnie kosztowna. Obsługa niezwykle rzadkiej kombinacji systemu operacyjnego i przeglądarki w najlepszym przypadku wymaga podobnego nakładu czasu co najpopularniejszej kombinacji, ale nie będzie generować podobnej liczby zamówień. W gorszych przypadkach problemy z replikacją błędów, przestarzałą technologią i dziurawą dokumentacją spowobują niepotrzebne marnotrawienie budżetu w imię pogoni za perfekcyjnym, „bug-free” produktem, który zadowoli 100% użytkowników. 

Z mojego doświadczenia wynika, że lepiej jest okresowo odcinać 20% „złego” ogona użytkowników i tak zaoszczędzone środki przeznaczyć na bardziej perspektywiczne działania. Wspomniane 20% użytkowników w większości nawet nie zauważy, że coś się zmieniło – ich przywiązanie do naszego produktu i tak jest iluzoryczne.

Z tej perspektywy arbitraż między „dobrymi” (koncentracja) i „złymi” (obcinanie) długimi ogonami wydaje się być dobrym sposobem na minimalizację długu technologicznego w organizacji.