One Day Product Framework: як валідувати вашу ідею швидше. Значно швидше

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

Привіт. Я Саша Шумило. Продуктовий стратег в The Gradient, де щодня дизайнимо та пропрацьовуємо цифрові продукти. До цього працював у декількох ІТ аутсорс-компаніях та маркетинговому агентстві.

Що важливо, я також входжу в надихаючі 90% світових стартапів, які зафейлились. Словом, маю досвід запуску продукту та втрати ~$50K власних заощаджень.

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

З чого почати

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

Про все це далі й поговоримо.

MVP

Скоріш за все, ви відразу подумали про MVP. І це крутий фреймворк. Проте, на практиці він часто не спрацьовує.

Я десятки разів чув: «Так! Почнімо з MVP!... Це буде коштувати $50К і займе 8-10 місяців розробки»

ОК, але здається трохи довго, щоб отримати відповідь на ключові питання.

Або Еджайл

Ми віримо в маніфест і сумлінно дотримуємось процесу: скрам, спрінти, ревʼю, демо, ретроспективи і все таке. Але якось так виходить, що реальні користувачі бачать продукт через 12 місяців потому.

Прототипи

Дуже їх люблю! Але, чесно кажучи, зазвичай я просто клік-клік-клік до кінця і все.

Ну, і думаю: «Блін, круто ж виглядає... скоріш за все буде працювати».

І, наостанок, славнозвісна мудрість стартапів:

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

— 100%, так і є. То що? Додамо гейміфікацію в першу версію? Я чув, що це робить продукт цікавішим і підвищує енгейджмент.

Problem statement

Зазвичай, ми інвестуємо достатньо багато часу та грошей в фічі без розуміння, чи вони будуть працювати, чи ні. На початку, нам не вистачає знання про те, що справді приносить цінність користувачам.

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

Проте, з мого досвіду, ми дуже часто настільки сильно захоплюємось процесом і настільки сильно любимо ідею, що нам складно повірити, що щось буде не так.

Але що, якщо ми отримаємо наш продукт за один день?

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

Ідея

Створення продукту за один день. Ліміт в 1 день допомагає сфокусуватись. Викиньте все зайве і подумайте, як можна зробити версію вашого продукту лише за один день.

  • Красиві кнопки? Ні, не треба.
  • 2-фактора аутентифікація? Трохи пізніше.
  • Адмін панель? Ні.
  • Ризики з безпекою? Пофіг.
  • Складні алгоритми? Використаю dummy data.
  • Складні ролі користувачів та права доступу? Усі можуть все.
  • Система щось обраховує? Під капотом жива людина.

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

Є два правила

1. Кор функціонал важливіший за UX і UI і все інше. От ви колись користувались жахливим продуктом? Можливо, покупка авіабілетів чи оформлення страховки?

Попри жахливий UX, ви все рівно користувались ним, бо кор функціонал важливіший за зручність.

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

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

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

2. Користувачі — головне і єдине джерело правди. Чим раніше ви пройдете ріаліті-чек, тим краще. Тільки користувачі своїми діями можуть показати, що щось їх справді чіпляє.

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

Ще одна ментальна пастка: ми — професіонали. Ми любимо робити те, що ми робимо. Проводити рісьорчі, обговорювати гіпотези, малювати прототипи, писати код, шукати класні нові фреймворки і заповнювати таблички. Як ви знаєте, що те, що ви робите, має сенс? Досвід — важливо. Ріаліті-чек — ще важливіше.

Як там кажуть: «Якщо вам не соромно за продукт, який ви випустили — ви запізнились».

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

Для зручності, зробив темплейт в FigJam.

Етап Перший. Ідея

Формулюємо продуктову ідею та прописуємо ключові функції. Зазвичай це все те, що ви перераховуєте, коли у вас хтось питає: «Так в чому ідея?»

Наприклад, ми хочемо зробити апку з челенджами.

  • Головна ідея — челенджити друзів.
  • Юзер може відправити челендж «відвідайт музей», або «10 віджимань», або «прогулянка на веліку», або «20 сторінок книжки».
  • Щоб валідувати, що челендж був таки виконаний, юзер має відправити фотку, як доказ, а інший юзер має апрувнути, що все чесно було зроблено.
  • У кожного челенджа є певна ціна і дедлайн.
  • Якщо друг фейлить, то повинен заплатити.
  • З іншого боку, якщо справляється, то ніяких призів немає. Просто молодець.

Етап Другий. Фічі

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

Продовжуємо з челендж-апкою.

Юзер А

  • Список челенджів (статичний). Картинка, опис, ціна, дедлайн.
  • Сторінка з описом челенджа.
  • Відправка челенджа. Тап на картці -> Вибрати юзера зі списку. Поки можна відправити тільки одному.
  • Екран успішного відправлення.
  • Список друзів.
  • ...

Юзер Б

  • Секція: мої челенджі.
  • Сторінка челенджа.
  • Прийняти челендж.
  • Завершити і відправити фотку.
  • Оплата.
  • ...

Система

  • Нотіфікейшни. Відправляємо емейли.

Етап Третій. Інтерфейс

Тепер треба спроєктувати інтерфейс. Дивимось на список фіч і малюємо від руки, як бачимо UX/UI. Інший прийом — знаходимо схожі апки, робимо скріншоти і колажуємо інтефрейс. (Дивитись можна на Mobbin, Behance, Dribbble)

Якщо в процесі бачите, що треба детальніше прописати флоу, то you’re welcome to do it.

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

Про що не подумав в челендж-апці:

  • Нам не сильно треба опис челенджа, бо з назви і так все буде зрозуміло.
  • Треба додати можливість створити кастомний челендж.
  • Для Юзера А не треба сторінка з описом челенджа.
  • Список друзів також поки не треба — всі можуть відправляти усім юзерам в системі.

Етап Четвертий. Пріоритезація та варіанти рішення

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

Також думаємо, яким чином ми будемо створювати продукт, які тули використовувати. А я їх багато:

  • ChatGPT;
  • Notion;
  • Bubble;
  • Google docs;
  • Webflow;
  • Keynote;
  • Coda.

Наприклад, челендж-апку будемо робити в bubble. А функціонал оплати поки взагалі не включаємо, бо за день не встигнемо.

Етап Пʼятий. Як будемо тестувати

Останнє питання, на яке варто дати відповідь, як тестуватимете продукт — роздасте друзям, сядете поруч і будете дивитись? Самі будете тестувати? Можливо, якісь системи аналітики?

Етап Шостий. (Ну, нарешті) Створюємо

Один день. 24 години на те, щоб все закінчити. Але ви точно может закінчити і раніше. Памʼятайте, головне — щоб працювали, а не те, як виглядає.

Етап Сьомий. Заключний. Інсайти

Ура! Вітаю з продуктом. Тепер найцікавіше.

Давайте почнемо користуватись.

Слухайте себе, записуйте усі інсайти, емоції. Що вам сподобалось, чого бракує, як ви себе почуваєте, в різні етапи використання, що корисне, а що ні. Чи є якісь деталі, які ще варто додати або пропрацювати.

Записуйте все.

А що по челендж-апці? Основне відкриття — ключове флоу неправильно зроблене. Ініціатор флоу — це людина, яка відправляє челендж другу. Проте, я зрозумів, що я не стільки хочу відправляти челенджі друзям, як хочу, щоб вони перевіряли, чи я виконую свої челенджі. «Віджатись 10 разів» потрібно більше мені, а не другу.

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

Наступний інсайт. Я втратив 50 грн, бо не пішов у зал, хоч мав піти. Втрачати гроші було не прикольно, але як не дивно, воно заохотило мене ще раз створити челендж і все ж таки піти. Тепер думаю, чи треба створювати наступний челендж на наступний похід. В будь-якому випадку, ходити в зал стало простіше (і це дуже добре).

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

Трохи менші:

  • Я побачив, що предефайнуті челенджі не такі вже і прикольні.
  • Було прикольно трекати, скільки днів залишилось до того, як друг має виконати челендж.
  • Коли отримав фотку на апрув, то було прикольно. Гарний момент, щоб створити наступний челендж.
👍ПодобаєтьсяСподобалось14
До обраногоВ обраному6
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Такое ощущение что написал абы написать. На самом деле вся суть сводится к рекламе и к какой-то ерунде, которая зацепит остаться. Хороший пример говно игра атомик харт — ссср+реклама. Они вышли в ноль и чуть-чуть заработали. При этом выпустили полный шлак, который без этих двух компонентов или даже одного из них закончился бы тем что не окупилось бы вообще

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

Але я не розділяю цей підхід. Тому поділився своїм досвідом і тим, як би інакше підійшов до запуску продукту.

+ це проблема, яку бачив в декількох аутсорс компаніях. Велика купа часу і грошей іде на речі, які нікому не треба. Why?

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

Не погоджуся!
Для користувача візуальна частина є маркетинговою стратегією, а без неї важко залучити користувача. Якщо метою є перевірка основної ідеї — простіше її оформити як телеграм бот і набирати вже відгуки у тих, хто користується фічею більше кількох разів.

простіше її оформити як телеграм бот

прекрасна ідея підходу до ODP. Формат в якому будете перевіряти оносну ідею немає значення. Якщо є ідея зробити службу доставки, то не треба чекати місяця щоб зробити додаток, який буде трекати, де ви знаходитесь і розкидувати замовлення серед курʼєрів. Можна зробити простий сайт на webflow, купити новий номер тел і самостійно розвозити товари. День роботи

24 Години — це чистий робочий час, чи це просто безперервний проміжок часу в який треба вкластися?

Ідеально зробити все за день, бо ці 24 години можна розмазати на тиждень або два.

Хоча тут по життєвим обставинам, якщо неможливо виділити день на щось, то можна сплітнути на декілька днів. Навіть в такому варіанті все рівно ж будете пріоритезувати кор функціонал.

Тобто 24 години це на головні функції, а збір та аналіз відгуків — окремо?

Як не крути — фактичний робочий час над проектом розтягується більше ніж на 24 години. 1-2 Тижні на проект більш реалістично.

Ще ви оминули питання — як ви залучаєте користувачів?

Що є умовою продовження роботи над проектом (хось скористався вашим додатком, вам заплатили, хтось самостійно написав статтю про ваш додаток, додаток зміг досягнути певних показників по регулярному трафіку)?

Так, 24 — головні функції, аналіз та відгуки — окремо. Справді може розтягнутись на 1-2 тижні. Основну проблему бачив в тому, що люди часто закладають супер багато часу на девелопмент, тому саме цю штуку хочеться пофіксити.

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

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

За один день зібрати цінний репрезентативний фідбек..якось це звучить не реалістично

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

Це все цікаво. Один в один описано як я також працюю. Але велике питання не розкрите! А саме як тестувати і де брати юзерів? на справді усі ці ідєї можуть бути поховані якщо ви не правильно обрали юзерів чи метод яким ви це все покажете. А ще з власного досвіду можу додати що інтерфейси без гарного UI 90% відсотків не сприймають. Люди не можуть уявити собі як воно буде виглядати. Вони бачать якісь кривульки і кажуть що навряд чи вони таким користувались. Тому варто красі теж приділити увагу.

Щодо юзерів супер згоден, це важливе питання — де знайти саме тих юзерів.
Щодо UI — тут вот не згоден. Ідея як раз в тому, що будуть, якщо буде вирішувати реальну проблему.
//
Ще раз скажу, що немає задачі через день почати збирати гроші. Важливо перед тим як малювати гарних UI, подивитись чи наш функціонал корисний людям. Якщо так, то тоді справді треба дуже багато часу вбивати на UI.

Направді, це була проблема в моєму стартапі — я вкладався дуже багато в віжуал Alabama, і він людям справді подобався. Але вони не повертались в апку за віжуалом. Важливий був кор функціонал, який не працював так як треба. Щоб було б краще — я спочатку на дуже простому UX протестував кор функціонал, зрозумів, що вот воно! і далі вже його оформлював

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

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

Імхо, 99% книг по стартапам — це ментальна мастурбація.
One size fits all не працює

Читати — круто. Робиши — ще краще :)

Так а в чому валідація?
Як прийняти рішення — рухатись далі з цією ідеєю чи ні?
З такого методу можна зрозуміти як підкоректувати / викинути фічі, а про валідацію — хз

По-перше, фідбек від юзерів. По-друге, сам бачиш, як працює, що ок, а що не ок.
В чому проблема — коли брейнштормимо, то ідея завжди здається класною і в неї хочеться вкладати багато часу і зусиль. Коли ж виходить робоча штука, то бачиш, як воно працює і чи подобається людям.
Якщо користувачі кажуть — блін клас, а можна ще. Тоді варто продовжувати (валідували). Коли отримуєш фідбек — нуу да... То варто перепридумати щось

Класна стаття! І цікавий практичний досвід) Це і є суть MVP. Y combinator рекомендує на цю фазу витрачати тиждень.

По-суті, так. MVP за один день. Як раз можна до Y Combinator зробити за 1 день, а там вже за тиждень)

Дуже цікава ідея. Дійсно, можна отримати багато інсайтів та даних на основі просто жахливого як кінцевого, але достатньо функціонального як MVP, продукту. Тоді вже буде видно — чи є сенс покращувати оточення, чи воно мертве в самій ідеї. Але чи варто «усе встигати за добу»? Можна і тиждень відправити. Приблизно 56 тижнів у році, є 100 ідей для стартапу, 2 роки сповна вистачить щоб набагато більш якісно протестувати свої ідеї. Не так швидко як за квартал, але треба все ж мати певний баланс між швидкістю та якістю)

Та от один тиждень — це вже розкіш, вже можна подумати, скільки різних фіч можна втулити. А коли є тільки один день, то супер сильно ужимаєшся. І концентруєшся на головному. Зараз реально стільки різних сервісів є, що можна дуже швидко тестувати ідею. По-ідеї, можна трохи довше готуватись до цього одного дня девелопмента, потестити, різні тули, але прям дуже хочеться, щоб основна штука робилась за день.
+ другий, дуже важливий момент — це побачити, як працює продукт і нащупати якісь міні детальки.
+ якщо не встигаєш за один день і бачиш, що є ще якісь супер важливі модулі, без яких діла не буде — це вже крутий результат, вже знаєш, що точно треба.
+ тут же ж можна, хоч щотижня оновлювати і допрацьовувати.

Не повіриш — за тиждень сильно ужимаєшся також

Мабуть. Ті ідеї з якими працював справді можна було за день зробити. Базовий базовий базовий варіант. А далі вже можна допрацьовувати

Підписатись на коментарі