Какво трябва — и какво не трябва — да включва вашият SaaS MVP при стартиране

Думата „минимален“ в минимален жизнеспособен продукт е частта, която всеки пренебрегва. Основателите кимат на идеята да започнат с малко, после подават спецификация с четирийсет екрана, три потребителски роли, система за фактуриране, аналитично табло и „а, между другото, трябва да се интегрира с всичко“. Това не е MVP. Това е пълен продукт с оптимизъм, навит до максимум. И това е най-честата причина първите издания да закъсняват, да надхвърлят бюджета и някак все пак да им липсва единственото нещо, което клиентите всъщност искаха.

Помогнал съм на доста малки фирми и самостоятелни основатели да изкарат първия си софтуерен продукт навън. Техническата част рядко е това, което препъва хората. Трудната част — всеки път — е да се реши какво да не се изгражда още. MVP не е по-малка версия на продукта мечта с функции, изпилени наслуки. Това е преднамерен залог: най-малкото нещо, което можете да поставите пред реални потребители, доказващо, че основната идея си струва повече от вашите пари и време.

Затова това е ръководството, което ми се иска повече основатели да четяха, преди да напишат спецификацията си. Без жаргон, без театъра „движи се бързо и чупи нещата“. Просто практичен начин да теглите чертата между това, което принадлежи на първото ви издание, и това, което може — и трябва — да изчака.

Какво всъщност е MVP (и какво не е)

Нека изясним определението, защото повечето объркване започва тук. MVP е най-малката, най-проста версия на вашия продукт, която позволява на реален човек да направи единственото ценно нещо, което продуктът ви обещава — и ви позволява да научите дали той ще се върне, за да го направи отново. Това е всичко. Това е инструмент за учене, който случайно е направен от работещ софтуер, а не олекотено пускане на завършеното нещо.

Ключовата дума е жизнеспособен. Честа грешка е да прочетете „минимален“ и да пуснете нещо толкова голо, че да засрамите потребителя — наполовина завършен поток, който се срива, регистрация, водеща към празен екран. Това не е минимално жизнеспособно, а минимално счупено. Другият провал е обратното: продукт толкова „завършен“, че е отнел година за изграждане, а дотогава вече сте похарчили резервите си, доказвайки предположение, което сте можели да проверите за осем седмици.

Ето мисловния тест, който използвам. За всяка функция в списъка попитайте: ако я премахнем, би ли могъл потребителят все пак да постигне единствения основен резултат, заради който съществува продуктът? Ако отговорът е „да“, тя почти със сигурност не е част от MVP. Само този въпрос ще среже повечето спецификации наполовина — и половината, която отрязва, е тази, която щеше да ви забави.

Намерете единствената задача, която продуктът ви върши

Преди да решите какво да изградите, трябва да сте брутално наясно с единствената задача, която продуктът ви върши за някого. Не визията. Не пътната карта. Единственото повтаряемо действие, което, ако работи, прави деня на човека по-добър и го кара да е готов да плати. Повечето затруднени спецификации са неясни точно тук — те описват платформа, а не задача.

Опитайте се да довършите това изречение на глас: „Потребителят идва при продукта ми, за да ______, и си тръгва, след като ______.“ Инструмент за графици: мениджър идва, за да публикува графика за следващата седмица, и си тръгва с всяка смяна запълнена и екипа уведомен. Приложение за фактуриране: фрийлансър идва, за да фактурира клиент, и си тръгва с изпратена, проследима фактура. Ако не можете да попълните това изречение чисто, не сте готови да определяте обхват — все още сте готови да мислите.

Какво наистина изисква всеки SaaS MVP

Някои неща не подлежат на договаряне, дори в най-олекотената първа версия — не защото са вълнуващи, а защото без тях продуктът или не може да се използва, или не може да ви научи на нищо. Мислете за тях като за пода, не за тавана. Изградете ги просто, но ги изградете както трябва.

• Начин за вход. Дори единствен вход с имейл и парола е добре — но реален, сигурен, защото всичко останало зависи от това да знаете кой е потребителят.
• Основният работен поток, от край до край. Единствената задача, от първия клик на потребителя до момента, в който той получи ценния резултат — без задънени улици, без бутони „скоро“ в критичния път.
• Място, където данните наистина живеят. Реално съхранение, не еднократен прототип, така че работата на потребителя да преживее презареждане и той да може да се върне утре.
• Начин да виждате какво се случва. Базово логване или прост административен изглед, така че когато нещо се счупи — а то ще се счупи — да можете да разберете защо, без да гадаете.
• Начин потребителите да се свържат с вас. Дори само връзка с имейл. Ранните потребители ще ударят в ръбове, които не сте предвидили; искате те да ви казват, а не тихо да си тръгват.
• Минимумът на доверие: бележка за поверителност, разумно боравене с данните и да не правите нищо безразсъдно с информацията на хората.

Забележете какво не е в този списък: фактуриране, изящно въвеждане, страници с настройки, мобилни приложения, интеграции. Ще стигнем до причината след момент. Смисълът на пода е, че е достатъчно малък, за да го завършите, и достатъчно солиден, за да научите от него. Вход, който работи, един работен поток, който доставя, реални данни и начин да наблюдавате и да говорите с потребителите. Това е жизнеспособен продукт.

Какво преднамерено да оставите извън v1

Това е разделът, на който основателите се противят, затова нека бъда директен: повечето неща, които изглеждат съществени за първото ви издание, не са. Изглеждат съществени, защото „истинският продукт“ ги има — но вие още не изграждате истински продукт, а изграждате въпрос. Да оставите тези неща извън не е отрязване на ъгли. Това е цялата дисциплина на един MVP.

Автоматизирано фактуриране и сложно ценообразуване

Почти със сигурност нямате нужда от самообслужваща се система за фактуриране, степенувани планове, пропорционално начисляване и логика за напомняния в първата версия. Ако ранните потребители искат да платят, можете да вземете парите им ръчно — фактура, връзка за плащане, бързо обаждане. Ръчното фактуриране на първите ви десет клиента ви казва нещо, което автоматизираното не може: дали изобщо някой ще плати. Изградете машината, след като сте доказали, че има пари за събиране.

Сложни роли и права за достъп

Многоролевите системи за права — администратори, мениджъри, наблюдатели, гранулирани правила за достъп — са истинско инженерно блато и умножават огромно повърхността за тестване. За първо издание един вид потребител почти винаги е достатъчен. Ще научите реалните нужди от права, наблюдавайки как истински екипи използват нещото, и тези нужди рядко са това, което бихте предположили на хартия.

Интеграции, нативни мобилни приложения и таблото

„Трябва да се интегрира с всичко“ е фразата, която тихо удвоява сроковете. Изберете най-много една интеграция и само ако е част от основната задача. Нативните iOS и Android приложения почти винаги могат да изчакат — отзивчиво уеб приложение работи на телефон още днес. А аналитичното табло, което всеки иска? Потребителите не могат да анализират данни, които още не са създали. Пуснете първо нещото, което създава данните; визуализирайте ги, след като има какво да се покаже.

Прост метод за теглене на чертата

Да познавате принципа е едно; да го приложите към собствената си спецификация, където всяка функция ви се струва вашето дете, е по-трудно. Ето метод, който работи, защото принуждава решение за всеки елемент, вместо да остави всичко да се изплъзне в „съществено“.

1. 1
   Изброй всяка функция, която си си представял

   Изсипи всичко — без филтриране засега. Сложи целия списък с желания на масата, така че нищо да не дебне неизказано и да изскочи насред изграждането като изненада.
2. 2
   Маркирай всяка спрямо основната задача

   За всяка функция попитай: има ли потребителят нужда от това, за да завърши единствената основна задача от край до край? Маркирай я „основна“, „полезна“ или „някой ден“. Бъди честен — повечето попадат в последните две.
3. 3
   Запази само „основни“ за v1

   Твоят MVP е купчината „основни“ и нищо друго. Купчините „полезни“ и „някой ден“ не са отхвърлени — те са пътната ти карта, паркирана там, където им е мястото.
4. 4
   Провери разумността на отрязването

   Погледни какво е останало и попитай: може ли реален потребител да получи реална стойност само от това? Ако да, определил си обхвата на MVP. Ако нещо наистина чупи основния поток, върни само този един елемент — и нищо друго.

Дисциплината е в стъпка четвърта. Винаги има изкушение да „върнем само още едно нещо“, после още едно, докато тихо не сте възстановили пълния продукт. Позволете си да спасявате само елементи, които наистина чупят основния поток — не елементи, които просто биха го направили по-приятен. По-приятното е за версия две.

Жизнеспособен пак значи, че трябва да изглежда реален

Има режим на провал от другата страна на чертата и си струва да го назовем. В бързината да пуснат малко, някои основатели пускат скалъпено — и го наричат MVP. Основен поток, който губи работата ви, регистрация, която дава 404, текст, пълен със запълващи фрази. Това не тества идеята ви честно; то тества дали потребителите ще търпят счупено преживяване, а отговорът винаги е „не“. Ще заключите, че идеята се е провалила, когато всъщност изпълнението е се провалило.

„Минимален“ се отнася за обхвата, никога за качеството на частта, която запазвате. По-малко функции, всяка от тях солидна. Единственият работен поток, който пускате, трябва да изглежда завършен — бърз, ясен и надежден — дори ако е единственото нещо, което продуктът прави. Тесен продукт, направен добре, бие широк продукт, направен зле, всеки път, особено когато молите непознати да ви се доверят с работата си.

MVP не е финалната линия — той е първият отчет

Ето частта, която преосмисля всичко: пускането не е целта. Целта е това, което научавате в седмиците след него. MVP, който се пуска и ви казва „потребителите обичат основното, но постоянно искат X“, е оглушителен успех — дори ако X означава месец повече работа. MVP, който се пуска в тишина, без никой да се връща, също е свършил работата си: спасил ви е от изграждането на другите трийсет функции върху основа, която никой не искаше.

Затова планирайте първите седмици толкова преднамерено, колкото и изграждането. Наблюдавайте какво хората всъщност правят, не какво казват в анкети. Говорете с тези, които се върнаха, и с тези, които не. Оставете реалното използване — а не оригиналната ви спецификация — да реши какво влиза във версия две. Пътната карта, която паркирахте по-рано, не е обещание; тя е хипотеза, а потребителите ви всеки момент ще я оценят.

Чести въпроси