Problem-solution fit: рішення ще не продукт

Рішення — загальна відповідь на «як це могло б працювати краще?»: нагадувати постійним клієнтам про ТО, користуватися програмою замість журналу. Воно допомагає обрати напрям, але в понеділок зранку ним ніхто не скористається.

Продукт — та сама ідея, доведена до конкретики. Він називає:

• хто щось робить (адміністратор біля стійки, а не «автосервіс»);
• коли (під час видачі авто, поки власник чекає);
• чим (форма на телефоні, десять секунд на одне авто);
• що отримує клієнт (повідомлення у Viber від імені автосервісу за 30 днів до ТО).

Клієнти заплатили за результат: постійні клієнти повертаються. Рішення — один зі шляхів до цього результату, а продукт — цей шлях, накреслений на реальній мапі чийогось дня.

Правильне рішення все одно може провалитися як продукт. Якщо ні в кого немає хвилини, щоб дати йому дані, йому нічого надсилати. Відповідність рішення проблемі (problem-solution fit) — це обидві умови разом: рішення розв'язує проблему і вписується в робочий день клієнта.

Щоб перевірити, чи рішення вписується в роботу, пройди реальний робочий день разом із людьми, які б ним користувалися. Добрі запитання стосуються кроків, які вже відбуваються:

• «Що відбувається біля стійки, коли авто віддають власникові?»
• «Хто записує пробіг і де?»
• «Як ви сьогодні повідомляєте постійним клієнтам, що час на ТО?»

Кожна відповідь показує момент, коли з'являються дані, людину, яка могла б їх внести, і інструмент, що вже в неї в руках. В автосервісі Greg такий прохід показав, що пробіг відомий рівно один раз: коли Martha виписує рахунок на телефоні, а власник чекає.

Запитання про функції цього не дають. «Чи хотіли б ви функцію нагадувань?» викликає ввічливе «так», яке нічого не коштує. «Скільки ви заплатили б за застосунок із десятьма функціями?» просить оцінити уявну річ. Обидві відповіді підбадьорюють і нічого не кажуть про те, чи є в когось десять вільних секунд на твій продукт.

Коли в автосервісі немає жодної системи, щоб повертати постійних клієнтів, легко подумати, що поле порожнє. Це не так. Нічого не робити — теж конкурентна альтернатива, і часто її найважче перевершити.

Бездіяльність не коштує ні грошей, ні налаштувань, ні нової звички. Її ціна прихована: постійні клієнти забувають і йдуть до іншого автосервісу. Щоб виграти, твій продукт має зробити цю приховану втрату видимою, а потім коштувати менше часу й клопоту, ніж нинішні нульові зусилля автосервісу.

Це змінює запитання, які ти ставиш:

• Скільки постійних клієнтів минулого року повернулися без нагадування, а скільки ні?
• Скільки для автосервісу варте одне додаткове авто, що повернулося?
• Скільки секунд на день хтось готовий на це витратити?

Якщо чесна відповідь — «навіть не десять секунд», нагадування програють бездіяльності, хоч який гарний код. Тож щоразу, коли порівнюєш варіанти, став «нічого» поруч із журналом і наліпкою.

Будь-яка проблема клієнта вже має якусь відповідь, хай навіть незграбну. Ця відповідь і є конкурентна альтернатива (competitive alternative): те, що клієнт робить сьогодні замість того, щоб купити твій продукт. Щоб повертати постійних клієнтів, це може бути:

• родичка, яка дзвонить за журналом (4 000 грн на місяць, зупиняється, коли вона зайнята чи хворіє);
• наліпка на лобовому склі з пробігом наступного ТО (дешево, але водій перестає її помічати, а автосервіс не бачить, кому час на ТО);
• повідомлення у Viber, набрані вручну, або взагалі нічого.

Твоє рішення має перевершити цю альтернативу за часом, грошима й клопотом — з погляду клієнта.

Порівнюй кілька кандидатів поруч, зокрема ті, якими користуються зараз. У кожного є слабке місце, і в того, який хочеш будувати ти, теж: автоматичні нагадування залежать від того, чи хтось вносить авто. Порівняння — не пошук ідеального варіанта. Це вибір слабкого місця, з яким клієнти можуть жити, і ретельний дизайн довкола нього.

Коли вже є кандидат, понеси його назад до людей, які з ним житимуть. Мета перевірки рішення (solution validation) — з'ясувати, що піде не так, а не здобути «так».

Техніка проста:

• опиши крок за кроком, що воно робитиме, у світі самого клієнта: «Martha вносить пробіг під час видачі, за 30 днів до ТО йде повідомлення від вашого імені…»;
• потім замовкни й слухай, чи прозвучить «у нас так не вийде, бо…».

Це речення цінніше за будь-який комплімент. Воно вказує на реальний крок, якого ти не бачиш: продане авто, новий власник якого отримає чуже нагадування; власник авто, який терпіти не може спаму; племінниця, чию роботу нагадування тихо заберуть.

Продаж робить навпаки. Обіцянка результату («на 30% більше постійних клієнтів!») і запитання «берете?» викликають ввічливість і ховають усі ці проблеми до запуску, коли їх уже дорого виправляти.

У малому бізнесі людина, яка вирішує і платить, часто не та, хто користується продуктом щодня. В автосервісі Greg саме Greg обрав GarageDesk і заплатив. А вносити кожне авто мала б Martha, адміністраторка.

Це важливо, бо система нагадувань хороша рівно настільки, наскільки хороші її дані. Пробіг відомий в один момент: під час видачі авто біля стійки, поки власник чекає. Якщо внести авто забиратиме в Martha більше кількох секунд, вона це пропустить, і гроші Greg куплять порожню систему.

Тож проєктуй введення під момент користувача, а не під уявлення покупця про цей момент. Nina спершу уявляла, що Greg раз на тиждень заповнюватиме список клієнтів; Greg навіть не знає пробігу половини авто.

У кожній розмові став два окремі запитання: хто вирішує купити? і хто торкається продукту щодня і коли? Говори з обома. Покупець може сказати «так» продуктові, який користувачі потихеньку перестануть наповнювати.

Дві «відповідності» легко сплутати.

• Відповідність рішення проблемі (problem-solution fit): клієнти визнають, що проблема реальна, а конкретне рішення вписується в їхній робочий день. Це показують розмови, проходи робочим днем і вибір між варіантами — до розробки або під час неї. У GarageDesk це виглядало так: усі п'ять автосервісів, що заплатили наперед, обрали нагадування замість обдзвону й наліпок, коли дизайн Nina вклався в десять секунд Martha біля стійки.
• Відповідність продукту ринку (product-market fit): достатньо клієнтів користуються продуктом і платять місяць за місяцем, а нові приходять без героїчних зусиль. Це видно лише пізніше, в утриманні й платежах, після запуску.

Перше — передумова другого, а не його обіцянка. П'ять автосервісів, які обрали дизайн, кажуть, що його варто будувати. Вони не кажуть, що платитимуть і на шостий місяць або що його хочуть ще сто автосервісів. Оголосити product-market fit після кількох добрих розмов — поширений спосіб завчасно перестати слухати.

Три запитання складаються в коротку процедуру, яку можна пройти ще до будь-якого коду:

1. Записати результат, за який заплатили клієнти (постійні клієнти повертаються), а не функцію, яку маєш на думці.
2. Скласти список кількох варіантів рішення, зокрема незграбних, якими користуються зараз: автоматичні нагадування, щомісячний список для обдзвону, кращі наліпки.
3. Пройти робочий день разом із людьми, які б цим користувалися: у кого є дані, в який момент, яким інструментом.
4. Для кожного варіанта з'ясувати, що він замінює і що може зламати: скільки коштує нинішня альтернатива і які нові проблеми з'являться — спам, продані авто, чиясь втрачена задача.
5. Обрати один і визначити точний момент і людину, які його наповнюють.

Порядок важливий. Варіанти йдуть до проходу днем, щоб оцінювати їх за реальним днем, а не порівнювати з улюбленцем. Ризики — після того, як знаєш день, бо саме там вони ховаються. А останній крок, назвати людину й момент, якраз і перетворює рішення на продукт.