Будувати

Як провести десять розмов із користувачами й не підказувати їм потрібну відповідь

Підготувати список запитань, де жодне не містить вашого рішення. Запитувати про минулий досвід, а не про майбутні наміри. Замість «чи корисна вам була б функція X?» питати «як ви зараз вирішуєте завдання Y?». Записувати

Опубліковано 04.09.2026Оновлено 11.08.20266 хв читанняРедакція солана.укр
Редакційна ілюстрація до матеріалу для команд і builders
editorial illustrationБудувати
Авторство Редакція солана.укрАктуальність оновлено 11.08.2026Формат редакційний матеріал

Суть для читача

Підготувати список запитань, де жодне не містить вашого рішення. Запитувати про минулий досвід, а не про майбутні наміри. Замість «чи корисна вам була б функція X?» питати «як ви зараз вирішуєте завдання Y?». Записувати розмови або робити детальні нотатки одразу. Зупинятися, коли помічаєте, що ведете співрозмовника до відповіді, яку хочете почути. Десять таких розмов дають достатньо патернів, щоб побачити реальну проблему — або зрозуміти, що її немає.

Як виглядає механізм у дії

Чому прямі запитання не працюють

Коли ви питаєте «чи використали б ви продукт, який робить X?», людина майже завжди відповідає «так». Це не брехня — це соціальна ввічливість і когнітивна упередженість. Люди погано передбачають власну поведінку, особливо коли стикаються з абстрактним описом. Тому розмова має будуватися навколо того, що співрозмовник вже робив, а не того, що він міг би зробити.

Структура однієї розмови

Оптимальна тривалість — 20–30 хвилин. Більше — і людина втомлюється, менше — і ви не встигаєте вийти за поверхневі відповіді. Приблизний розподіл:

  • 2–3 хвилини — контекст: хто людина, чим займається, як стикнулася з темою розмови.
  • 15–20 хвилин — минулий досвід: як саме вона вирішувала завдання останнього разу, що робила до цього, що спробувала й відкинула, скільки часу чи грошей це забрало.
  • 5 хвилин — уточнення: що змінилося б, якби це завдання зникла; що найбільше дратує в поточному процесі.

Приклади запитань, які не підказують

Замість «чи хотіли б ви мати дашборд для відстеження транзакцій у Solana?»:

  • «Як ви зараз перевіряєте статус своїх переказів?»
  • «Згадайте останній раз, коли ви не змогли знайти транзакцію. Що ви робили?»
  • «Які інструменти ви вже пробували для цього? Що саме не сподобалося?»
  • «Якби ви могли змінити одну річ у тому, як ви зараз моніторите платежі, що б це було?»

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

Як не підказувати під час розмови

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

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

Скільки саме десяти

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

Для яких читачів це важливо

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

Команди, які готуються до гранту чи баунті. Грант не є гарантією попиту. Вимоги грантових програм часто фокусуються на технічній здійсненності, але продукт, який ніхто не використовує, не доводить цінність для екосистеми. Розмови з користувачами дають аргументи для обґрунтування проблеми в заявці — не вигадані, а почуті.

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

Ризики, які не можна ігнорувати

Підтверджуване упередження

Ви знаєте, що хочете почути, і несвідомо формулюєте запитання так, щоб отримати саме цю відповідь. Єдиний надійний спосіб боротися — писати запитання до розмови, показувати їх колезі з проханням знайти «підказки», і не відступати від сценарію під час бесіди.

«Я вже знаю користувачів»

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

Занадто широка аудиторія

«Трейдери на Solana» — це не аудиторія для розмов, це категорія. «Люди, які торгують на DEX і вручну ведуть таблицю угод» — це вже конкретніша група. Чим точніше ви визначите, кого запитуєте, тим менше розбіжностей у відповідях.

Спроба продати під час розмови

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

Обмеження методу

Розмови показують, чи існує проблема і як люди її описують. Вони не показують, чи люди заплатять за рішення. Для перевірки готовності платити потрібні інші інструменти — наприклад, лендинг до продукту, який збирає конкретні дії, а не лише слова.

Як перейти від пояснення до перевірки

Після десяти розмов у вас має бути список реальних проблем, які люди описують своїми словами, без вашої інтерпретації. Конкретний наступний крок:

  1. Згрупуйте згадані проблеми. Скільки різних проблем ви почули? Якщо всі десять людей називають одну й ту саму болючу точку — це сильний сигнал. Якщо кожен називає щось своє — можливо, ви запитували занадто широко.
  2. Перевірте частоту. Скільки людей зіткнулися з цією проблемою останнього місяця? Якщо проблема трапляється раз на рік — це не база для продукту.
  3. Сформулюйте гіпотезу без рішення. Не «людям потрібен дашборд», а «люди, які роблять більше п’яти транзакцій на день, витрачають 15–20 хвилин на ручний пошук конкретної операції в експлорері».
  4. Оберіть наступний інструмент перевірки. Якщо проблема підтверджена, але ви не впевнені в готовності платити — перехід до кількісної перевірки через лендинг або пре-рейтрастрацію. Якщо проблема не підтверджена — повернутися до загального процесу перевірки ідеї або переглянути, чи варто взагалі будувати в цьому напрямку.

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

Редакція солана.укр