Ваш продукт не має значення. Має значення лише те, як швидко ви його переробите

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

У 2012 році Twitter купив стартап Vine за $30 млн ще до офіційного запуску. Vine був крутим продуктом, що дозволяв юзерам знімати й публікувати 6-секундні відео. Простий інтерфейс, продуманий флоу, вдала технічна реалізація.

Та вже в 2016-му Twitter закрив Vine. Чому? Бо продукт не встигав адаптуватися під те, як юзери його використовували. Доки команда обговорювала можливість змін, гіганти типу Instagram запускали «сирі» stories — і це вибило Vine з ринку.

Інтерфейс Vine, зображення взято з failory.com.

А тепер інша історія. 2012 рік, команда Tiny Speck робить онлайн-гру Glitch. Гра — провал. Складний незрозумілий геймплей, маленька аудиторія, мінімальні шанси на масштабування. Здається, що варто «докручувати» продукт, додавати фічі, намагатись залучити більше юзерів. Але команда звертає увагу на інше: внутрішній інструмент для комунікації, який вони зробили для себе під час розробки гри, працює краще за саму гру. Команди з інших компаній, які його бачили, питали «А можна й нам таке?».

Що зробила команда? Закрила гру. За кілька місяців перепакувала внутрішній інструмент. Запустила як окремий продукт. Назвала Slack, чули? Сьогодні він коштує ≈$27 млрд.

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

Чому «ідеальний» продукт нікому не потрібен

Якщо коротко, тому що ви не знаєте свого клієнта. Навіть якщо ви провели 50 інтерв’ю, зробили CustDev, прописали персони і Jobs To Be Done. Ви все одно не знаєте.

По-перше, тому що люди брешуть. Не завжди свідомо, а тому, що не вміють передбачити власну поведінку. Вони кажуть «Я б точно цим користувався!», а потім не користуються. Описують свої болі в інтерв’ю, але коли ви робите рішення, виявляється, що болить не настільки сильно, щоб заплатити.

По-друге, перші гіпотези майже завжди помилкові, і це нормально. Проблема не в тому, що ви помилилися, а в тому, скільки часу й грошей витратили на розробку того, що виявилося непотрібним.

І ще одне: ринок змінюється швидше, ніж ви доходите до кінця поточного беклогу. Особливо зараз, коли AI-гіганти випускають щось нове кожні три місяці. Якщо ви плануєте розробку на рік вперед, то будьте готові, що за цей час з’являться п’ять нових конкурентів, дві нові технології й одна регуляторна зміна, яка може відправити більше половини вашої роботи у смітник.

Що насправді важливо на ранніх стадіях

Швидкість ітерацій

Уявіть дві команди. Перша робить реліз раз на місяць. Друга — раз на тиждень. За 3 місяці перша команда зробить 3 ітерації. Друга — 12. Хто швидше знайде product-market fit? Хто швидше дізнається, що не працює? Хто витратить менше грошей на непотрібну розробку?

Швидкість — це про здатність перевірити гіпотезу до того, як закінчаться гроші. Це про те, щоб побачити реальну реакцію юзерів, а не показати світу свою версію того, як «має бути».

Швидкість означає робити «сирі» речі. Це означає випускати фічі, які ви вважаєте «не готовими». Але знаєте що найсмішніше? Користувачам майже пофіг. Їм потрібно, щоб працювало, навіть якщо працює криво, але ви гарантуєте, що за тиждень буде ок. Решта — це про его.

Культура ухвалення рішень

До публічного релізу Connecto ми свідомо працювали в робочих групах з кожним зі своїх клієнтів. Не було ніякого масового бета-тестування, після якого ми б збирали фідбек через Google-форми.

Ми підтримували щоденний контакт з клієнтами з різних ніш, де вони могли написати «не зрозуміло, як налаштувати CRM-інтеграцію/мені потрібні теги/а можна сповіщення для менеджера?» — й ми за години змінювали інтерфейс і показували результат. Вони знову пробували. Ми спостерігали. Вони казали: «Тепер краще, але оце незручно». Ми міняли ще раз. Потім ще раз. Потім щось відвалювалось. І ще раз — доки не складався пазл «зрозуміло + зручно + працює».

Приблизно так виглядала комунікація в кожній робочій групі.

Це дозволяло валідувати ідеї в режимі реального часу. Випускати фічу в понеділок, збирати фідбек у вівторок, вносити правки й фіксити баги в середу та четвер і до п’ятниці розуміти — залишаємо чи викидаємо.

Багато речей ми викинули. До деяких так і не дійшли руки (закладали в беклог, але ніхто не попросив) — і це чудово, бо дізналися про це за місяць, а не рік — і зекономили ресурси.

Але для цього потрібна специфічна культура, де можна сказати: «Ми витратили два тижні, але це нікому не потрібно, давайте скіпати». Де CTO не захищає свою архітектуру, продакт не захищає свій роудмап, а CEO готовий визнати, що його «геніальною» фічею ніхто не користується.

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

Гнучкість бізнес-моделі

Тут все ще цікавіше, бо швидкість — це не лише про функціонал. Це про готовність міняти те, як заробляються гроші.

Команда має бути готова міняти тарифні плани, пробувати різні способи оплати, тестувати freemium, відмовлятись від нього, додавати/прибирати trial, пропонувати річний тариф зі знижкою, промокоди або бонуси.

Я знаю фаундерів, які місяцями сперечаються про «правильну» ціну. $77 чи $99? Monthly чи annual? Per user чи per company? А правильна відповідь завжди одна: та, за яку заплатять. І точно дізнатися це можна лише в «польових» умовах.

Бізнес-модель на старті — це така ж гіпотеза, як і продукт, бо ви не знаєте, скільки вам готові платити, поки не попросите гроші. Ви не знаєте, який пеймент-флоу конвертує краще, поки не протестуєте. Ви не знаєте, чи спрацює freemium, поки не спробуєте.

І знову ж, швидкість важлива. Скільки часу у вас займе зміна тарифу? Якщо більше тижня — це потенційна проблема.

Не вимірюйте свій потенціал лише якістю продукта

2020 рік. Стартап Quibi — преміум сервіс із епізодами по 5–10 хвилин, оптимізованими для смарфонів. Засновник — Джеффрі Катценберг, легенда Голлівуду (той самий, що створив DreamWorks разом зі Спілбергом). У команді — топові продюсери та режисери. Залучили $1,75 млрд інвестицій ще до запуску.

Вони робили дуже «якісний» продукт. Найняли найкращих, інвестували в контент, продумали все до найменших деталей. Місяці підготовки. Ідеальний запуск і... фейл через 6 місяців.

Що пішло не так? Вони не чули ринок. Запустились під час пандемії, коли люди сиділи вдома, а продукт був для перегляду в дорозі. Не давали можливості ділитись контентом, бо боялись піратства. Робили тільки вертикальне відео, бо «це логічно для мобільних». Коли юзери давали фідбек, команда витрачала тижні на обговорення, чи варто міняти стратегію.

У цей самий час TikTok робив по кілька апдейтів на день. Тестував нові формати щотижня. Вмикав і вимикав фічі залежно від реакції. Не питав дозволу в ради директорів, не чекав «ідеального» моменту.

$1.75 мільярда vs гнучкість та швидкість. Гроші програли.

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

Як це втілити

Якщо говорити про організацію, то подумайте про маленькі кросфункціональні команди. Ідеально — 3-5 людей, які можуть самостійно ухвалити рішення і випустити фічу. Розробник, дизайнер, продакт. Без «я зроблю таск і передам далі», а за принципом «ми разом викотимо це юзеру».

Autonomous decision-making. Команда вирішує, що робити, без узгодження з CEO кожного кроку. Так, CEO задає напрямок і нагадує про метрики успіху, але команда вирішує, як цього досягти.

Flat hierarchy. На ранніх стадіях кожен рівень узгодження — це день затримки. А день затримки — це день, коли ви витрачаєте бюджет не на те.

Якщо говорити про культуру, то класно працюють weekly або bi-weekly спринти з обов’язковим релізом. Не «ми працюємо над фічею», а «ми випускаємо щось щотижня». Навіть якщо фіча сира. Навіть якщо це MVP до MVP. Випускаємо, спостерігаємо, слухаємо користувача, дивимось аналітику. «Done is better than perfect» має бути мантрою. Не як виправдання для халтури, а як нагадування, що ідеальний продукт, який ніхто не побачив, коштує 0, а сирий продукт, який вже використовують 10 людей, дає вам інсайти вартістю в тисячі доларів (якщо не вірите, напишіть в агенції, запитайте прайс на дослідження).

Не треба боятись клієнтів, негативу й відмов. Будьте близькими: не через CSM, не через тікети, не через дашборди аналітики. В спільних чатах. Фаундер чи кофаундер має спілкуватися з користувачами. Розробник має бачити, що людина тикає в його коді. Дизайнер має чути, де користувач заплутався.

Коли продукт починає мати значення

Коли ви нащупали product-market fit. Коли з’явились повторювані процеси продажу. Коли є розуміння, хто ваш клієнт, яка його customer journey, які метрики й про що вони кажуть.

Чому лише зараз? Тому що тепер ви масштабуєтесь, а не шукаєте. Тепер один баг впливає на сотні або тисячі користувачів, а не на десять. Тепер погана архітектура сповільнює всю компанію, а не одну команду.

На цьому етапі треба інвестувати в якість. Рефакторити код. Будувати дизайн-систему. Налагоджувати процеси. Словом, починати робити речі «по-людськи».

Але навіть тут швидкість залишається критичною. Подивіться на гігантів: Spotify робить сотні експериментів на рік. Amazon деплоїть код кожні 11 секунд. Netflix постійно A/B тестить інтерфейс.

Справа в тому, що тепер у вас з’являється інфраструктура для швидкості. CI/CD, feature flags, моніторинг. Ви можете (і вже маєте!) зберігати швидкість + слідкувати, щоб нічого не зламалось.

При цьому підхід до роботи має залишатися з фокусом на «швидше дізнатись, швидше адаптуватись, швидше релізнути».

Виміряйте свою швидкість зараз

Дуже просте питання: скільки часу пройшло від вашого останнього релізу?

Якщо відповідь «більше тижня» і ви стартап на ранній стадії — у вас проблема. Не з продуктом. З процесами.

Ще одне питання: скільки часу займає шлях від «у нас є ідея фічі» до «користувач може її затестити»? Якщо більше двох тижнів — у вас проблема. Вона може бути в процесах узгодження. В побоюванні когось образити. В технічному борзі. В страху щось зламати. В перфекціонізмі (продовжіть список самі).

Останнє питання: коли ви востаннє відкидали фічу, в яку вклали час? Якщо ніколи — ви або генії, або боїтеся визнавати помилки, або взагалі не в контакті з юзерами.

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

А в що вірите ви?