Половина дзвінків із засновниками починається з «Мені треба побудувати X, і я не розумію, як це описати». Це проблема опису, а не продукту. Розробник на іншому кінці розмови намагається оцінити те, чого ще немає на папері, і обидва ви гадаєте.
Цей пост — шаблон брифу, який я прошу надіслати до першого дзвінка. Одна сторінка. Пишеться за вечір. Економить 4–8 тижнів на типовому проєкті.
Шаблон — копіюйте
Вставте в Google Doc або Notion, заповніть кожен розділ. Не пропускайте. Порожні — ті, що пізніше вилазять найдорожче.
Назва проєкту: [робоча, можна чорнова]
Одне речення про те, що ви робите:
Платформа, де [хто] може [робити що] щоб [який результат].
Чому саме зараз? (1–2 речення про те, чому це правильний момент — вікно запуску, раунд, зсув ринку)
Три користувацьких сценарії, які мають працювати в v1:
Єдина метрика, яка скаже, що вийшло: (число, не дашборд)
Інтеграції, які мають бути живими в день 1: (Stripe? Resend? Supabase? Clerk? Конкретно.)
Жорсткі обмеження:
- Дедлайн і причина:
- Діапазон бюджету:
- Цільові платформи: веб / iOS / Android / все
- Мови / локалі:
Що вже є:
- Figma / дизайн:
- Брендбук / гайди:
- Існуючий код або акаунти (Stripe, Vercel, тощо):
- Домен:
Що ви точно не будуєте в v1: (скорочення — див. нижче)
Як приймаються рішення:
- Хто затверджує дизайн?
- Хто затверджує зміни обсягу?
- Ваше зобовʼязання щодо швидкості відповіді (48 годин підходить для більшості проєктів):
Одна сторінка. 300–500 слів у заповненому вигляді.
Чому кожен розділ важливий
«Одне речення про те, що ви робите»
Шаблон змушує вкласти хто × дія × результат. Ця комбінація вбиває розмитість. «Платформа для креаторів» не проходить тест. «Платформа, де незалежні викладачі музики продають записані пакети уроків щоб отримувати повторюваний дохід від існуючих учнів» — проходить.
Якщо не виходить заповнити речення — ви ще не готові до брифу. Витратьте тиждень, ітеративно уточнюючи. Покажіть трьом людям, що підходять під «хто». Скоригуйте.
«Чому саме зараз?»
Проєкти без терміновості розповзаються. «Чому зараз» каже розробнику, справжній у вас дедлайн (демо на конференції, закриття раунду, сезонне вікно) чи «хотілося б». Це змінює, як він оцінює, що скорочує, і взагалі брати проєкт чи ні.
Добре: «Закриття раунду 15 вересня, хочемо показати платячих користувачів до цієї дати». Слабо: «Хотілося б запуститися скоріше».
«Три користувацьких сценарії»
Три — це стеля. Не пʼять. Не «гнучко».
Сценарій — це: починається десь, закінчується доставленою цінністю. «Купити квиток» — сценарій (лендинг → список → вибір місця → оплата → підтвердження). «Дашборд» — не сценарій, це поверхня. У сценаріїв є дієслова і кінці.
Якщо у вас пʼять сценаріїв, які не виходить скоротити, — у вас два продукти, що прикидаються одним. Оберіть, який запускається першим.
«Єдина метрика»
Засновники опираються цьому найсильніше. «У нас багато метрик». Ні. Одна. Сенс єдиної метрики — не вимірювання, а вирішення суперечок під час розробки. Кожне «додати X?» вимірюється проти цієї однієї метрики.
Добре: «50 платячих клієнтів у перші 90 днів». Добре: «1000 щотижнево активних організаторів». Слабо: «Траєкція, ріст, валідація».
«Інтеграції»
Кожен рядок у списку інтеграцій — це 3–8 днів реальної роботи, включно з граничними випадками. Засновник, що перераховує 12 інтеграцій у день 1, замовляє 6-місячний проєкт, знає він це чи ні.
Stripe — це не «Stripe». Stripe Subscriptions, Stripe Checkout, Stripe Connect з розділенням платежів і Stripe Invoicing — чотири різні інтеграції з чотирма різними профілями складності. Конкретно.
«Жорсткі обмеження»
Три числа рятують більше проєктів, ніж будь-який технічний вибір:
- Діапазон бюджету. «€15–30K» — нормально. «Стеля €20K» — нормально. Називати діапазон замість числа економить обом сторонам позерство.
- Дедлайн + причина. Дедлайн без причини — побажання. Дедлайн із причиною — зобовʼязання.
- Платформи. Тільки веб? Адаптивний веб + iOS? Подвоєння обсягу при додаванні платформи — найбільший зсув у ціні.
«Що вже є»
Якщо є Figma — білд іде на 30% швидше. Якщо ні — розробник проєктує і будує одночасно, це сповільнює все. Визнайте чесно. Сказати, що «дизайн є», коли є три екрани у Figma і мудборд, — значить зсунути неприємну розмову на другий тиждень замість нульового дня.
«Що ви точно не будуєте»
Цей розділ відокремлює добрий бриф від відмінного.
Записати, чого ви не робите, складніше, ніж що робите. Але це запобігає 80% повзучості «заодно зробимо», яка вбиває проєкти з фіксованою ціною.
Приклад скорочень із реальних брифів:
- Не: кастомний адмінський дашборд. Замість: прямий доступ до бази для нас, нормальна адмінка в другу фазу.
- Не: дизайн шаблонів листів. Замість: plain-text транзакційні листи.
- Не: роль-орієнтовані права понад власника/користувача. Замість: усі — власники в v1.
- Не: нативний мобільний застосунок. Замість: тільки адаптивний веб.
- Не: багатомовність. Замість: тільки англійська на запуску.
Перерахуйте скорочення. Розробник, що читає «ось чого я не будую», видихає — значить, ви подумали про обсяг.
«Як приймаються рішення»
Ключовий рядок — зобовʼязання щодо швидкості відповіді.
Якщо я надсилаю демо в пʼятницю, а ви відповідаєте в четвер — я втратив половину наступного спринту. Більшість зривів термінів трапляються на затримці погоджень, а не на реалізації. Впишіть «48 годин на рішення або неявне затвердження» в бриф. Звучить агресивно, але це не агресія, а спосіб запускати проєкти.
Три питання, важливіші за будь-який Figma
Після того як бриф існує, три питання діагностичніші за будь-який дизайн-файл:
1. Яка найменша версія того, що ви б усе одно запустили?
Якщо засновник відповідає списком із 8 фіч — він не готовий. Якщо відповідає «ці три сценарії, решта почекає» — зелене світло.
2. Якщо запуститься рівно те, що описано — з якою ймовірністю ви захочете переписати це з нуля через 18 місяців?
Засновник, який каже «скоріше за все високою», каже, що MVP — це одноразовий прототип. Нормально — але тоді плануємо відповідно (швидше, дешевше, менше полірування). Засновник, який каже «низькою, це має масштабуватися до першої тисячі клієнтів», — потрібна інша ціна та інша архітектура.
3. Хто керуватиме продуктом після запуску?
Якщо відповідь «ви, мабуть?» — пауза. Засновник, що планує передати операції після запуску, потребує набагато більшої кількості документації, передачі й підтримки, ніж той, хто сам буде оператором. Це теж частина обсягу.
Чого не класти у бриф
Не кладіть у односторінковий:
- Детальні описи UI («кнопка має бути синьою з градієнтом»). Це область Figma.
- Повні списки фіч із під-фічами. Якщо не вміщується в три сценарії — друга фаза.
- Маркетингові тексти для готового продукту. Це ви напишете на 8-му тижні.
- Користувацькі персони понад «хто» в одному реченні. Збережіть 40-слайдовий персонаж-дек на потім.
- Аналіз конкурентів. Якщо він впливає на ваше «хто × дія × результат», — один рядок. Інакше — ні.
Бриф — для розробки, не для інвесторської презентації.
Типові заперечення
«Це сильно спрощує. Мій продукт складніший».
Більшість MVP — не складні. Вправа зі спрощення змушує знайти ядро. Якщо після чесної спроби спростити не вийшло — проєкт більший, ніж MVP, і бриф у великого проєкту інший (потрібна фазована дорожня карта, а не односторінковий). У будь-якому разі, односторінковий бриф показує, в якій ситуації ви насправді.
«Я поки не знаю достатньо, щоб це написати».
Тоді спочатку зробіть discovery-етап. 1–2 тижні, фіксована ціна, результат — бриф. Стартувати розробку без брифу дорожче, ніж заплатити за бриф.
«Мій розробник сказав, що йому це не потрібно».
Запитайте, як він називає ціну без брифу. Чесна відповідь: «вгадую і закладаю 30% зверху». Нормально для маленької роботи. Для MVP — ви платите за запас і все одно отримуєте здогад. Наполягайте на брифі — сама вправа читання брифу розробником витягне його питання до підписання договору.
Що з ним робити
Надішліть 2–3 розробникам. Попросіть розбивку за віхами і фіксовану ціну у кожного. Порівняйте ціни й питання, які кожен поставив після прочитання брифу. Той, хто поставив найточніші питання, зазвичай і відвантажує.
Якщо хочете другу думку по брифу перед надсиланням — надішліть ваш, я прочитаю і дам одну сторінку зворотного звʼязку безкоштовно. Без зобовʼязань — якщо не підходимо, скажу і порекомендую когось іншого. Надішліть через контактну форму.