Що насправді має залишитися в MVP

Автоматичний парсинг подарунків я хотів зробити ще на старті Bazhannya.

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

Але в першій версії я її не додав.

Я зробив звичайну форму, де подарунок потрібно було додати вручну.

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

Що для мене насправді було MVP

Коли робиш свій продукт, дуже легко дивитися на нього як розробник.

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

Усе це можна розробляти дуже довго.

Але для першої версії Bazhannya мені потрібно було перевірити досить просту річ: чи будуть реальні люди реєструватися і створювати свої вішлісти.

Тому база продукту була мінімальна.

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

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

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

Тобто я не намагався зробити в MVP просто менше екранів, я намагався залишити тільки потрібний функціонал.

Функція може бути простою — і все одно зайвою

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

Наприклад, різні типи доступу до вішліста: приватний, публічний, для друзів.

Це не була якась величезна технічна задача. Саме тому її легко було виправдати: якщо зробити нескладно, чому б не додати?

Зараз я думаю, що для першого тесту можна було залишити один тип вішліста.

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

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

А таких невеликих речей легко назбирати багато.

Найбільше часу забрала не функція

Ще одна помилка першої версії була взагалі не пов'язана з набором можливостей продукту.

Для Bazhannya я взяв куплений шаблон.

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

На старті це додало зайвої роботи.

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

Тому що користувачу насправді немає різниці, написаний твій продукт на PHP, React чи на чомусь іншому.

Йому важливо натиснути кнопку й отримати той результат, якого він очікує.

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

Те, що я відклав, потім стало важливим

З автоматичним парсингом вийшла цікава ситуація.

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

Люди не хочуть заповнювати довгі форми. Набагато природніше вставити посилання і в один клік зберегти бажання.

Але я не думаю, що через це потрібно було робити парсер ще до першого запуску.

У цьому для мене і є різниця між «ця функція потрібна продукту» і «ця функція потрібна першій версії продукту».

Це не одне й те саме.

У першій версії мені потрібно було побачити перших реальних користувачів.

Я пам'ятаю, як кількість реєстрацій росла: 5, 10, 100.

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

Чи зробив би я зараз першу версію Bazhannya інакше?

Насправді ні.

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

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