Danylo Golota 💸

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

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

Бісяче, бо кожен раз коли я чую запит, мій внутрішній голос кричить “Я ЗНАЮ ШО ЦЕ ТРЕБА, МИ ЦЕ ВЖЕ РОБИМО, ПОТЕРПІТЬ, нам просто трошечки не вистачає часу, дєнєг і відповідно рук, щоб все зробити швидше, але ми в курсі”.

Потім я заспокоююсь і йду працювати далі.

Добрий раночок, коротше.

…

PS. Найпопулярніші запити від юзерів, і те що в нас в процесі, якщо вам було цікаво:

1. Управління грошима парт-тайм членів команди, які працюють на рейті, і треба знати скільки заплатити їм в кінці місяця.

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

3. Non-billable таймлоги: час який команда працює в проекті клієнта, але агенція йому не білить цей час в інвойс (через якісь причини), тому платить за це сама.

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

І ще парочка дрібніших.

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

Це я до того, що локалізація Fintellect українською вже на підході 🇺🇦

Ми: заводимо клієнта в підписку.

Stripe: “ми заблокували платіж, бо клієнт якийсь підозрітєльний”.

Ми: довго і нудно переписуємось з підтримкою.

Stripe: “ми перекинули вас на відповідального менеджера, який все порішає.”

Менеджер: курить бамбук.

Ми: дзвонимо в підтримку, говоримо 30 хв, щоб розблокували.

Stripe: “ми розблокували ID платежу клієнта, хай платить, велкам”.

Клієнт: платить.

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

Ми: “та йоб вашу мать”.

Stripe: “оцініть якість сервісу🧡”.

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

Воронка залучення клієнтів схожа на відро, бо вам тупо не вистачає функціоналу, який відповідає задачам клієнтів, і здатен їх затримувати. На цій стадії retention це виключно про можливості продукту. Закриває потреби — компанія користується. Не закриває якусь частину потреб — “сорі, ми посидимо почекаємо”. І це справедливо.

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

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

Власне прикол з пріоритизацією в тому, що вам потрібно одночасно:

- Будувати функціонал, щоб збільщувати % конверсії з вашої воронки (бо на цьому етапі конвертує продукт, а не маркетинг)

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

- Бути на постійному зв’язку з користувачами, щоб передбачати, що вони хочуть, і відрізняти загальні ідеї, від реальних блокерів перед користуванням.

- Займатись фандрейзингом, щоб не впертись в банальну відсутність кешу.

- Тримати в порядку операційку, фінанси, команду.

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

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

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

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

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

Під кожною позицією є кнопка “голосувати” яка веде на пейвол де треба заплатити скажімо $1 за голос. Далі робимо просту автоматизацію, за якою беклог пріоритизується за кількістю грошей в кожному пункті.

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

Хз чи зійдеться така бізнес-модель, і чи це взагалі можливо, але це було б точно цікаво і весело)

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

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

Яке рішення?

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

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