The post has been translated automatically. Original language: Russian
A common situation is that a product manager suggests an idea, the team develops a solution within two weeks, and the feature is released, but there is no result. Users did not notice the changes, the metrics remained at the same level, and in retrospect, the team states: "the idea looked logical."
As a rule, the reason is not the quality of the implementation, but the fact that the idea itself was not worth implementing — at least in its original form. It was possible to establish this in advance by spending not a development sprint, but one or two days testing the hypothesis. Hypothesis testing is often perceived as a lower priority, because intuitively you want to move on to development faster, rather than questioning your own idea.
Product Discovery is a set of practices that allow you to test a hypothesis before you spend development resources on it, rather than after.
From cheap to expensive: the path of one hypothesis
It is not necessary to choose one verification method — the methods are arranged in a natural sequence, and moving to the next level is advisable only if the previous one did not give an unambiguous answer.
The first stage is an interview with users. This is the least expensive and fastest way: 5-8 short interviews with real users take one or two days. It is important to formulate questions not about a hypothetical attitude to a future function, but about current behavior — how users solve the problem now, what difficulties they are experiencing, and how much time they spend on it. People tend to inaccurately predict their own future behavior, but they accurately describe their past experiences.
If interviews have confirmed the existence of a problem, but it remains unclear how users will react to a specific solution, an imitation is used — for example, a fake door button leading to a function that has not yet been implemented, with a fixed number of transitions, or a prototype in Figma, demonstrated instead of the finished product. This method requires more resources than an interview, but it remains significantly cheaper than a full-fledged development and allows you to get data on the real interest of users, and not just the declared one.
Only after confirming the hypothesis in the first two stages is it advisable to switch to a limited launch — the function is implemented, but not all users become available: for example, 5% of the audience, with the ability to quickly disable through a flag. Formally, this already goes beyond the boundaries of discovery in a narrow sense, but it is this stage that allows us to obtain data on actual usage, rather than assumptions about it.
The general principle is that the less expensive the verification method, the earlier it should be applied. Going straight to a limited launch is impractical if several interviews already answer the question about the relevance of the idea.
Practical steps
- Formulate a hypothesis, not an idea. Instead of "add a filter based on price" — "we assume that users do not find the right product due to the lack of a filter, which leads to N% failures." A hypothesis can be tested; an idea can only be realized.
- Determine the confirmation criteria in advance. For example: "if 6 out of 10 users in an interview independently mention this problem, the hypothesis is considered confirmed." This approach excludes the interpretation of the results after the fact in favor of the desired conclusion.
- Start with the least expensive method. Even with high confidence in the idea, five user interviews require fewer resources than one day of development, and they avoid weeks of work on an unclaimed solution.
- Share discovery and idea promotion. If the interview is conducted by a person who is personally interested in a positive result, there is a risk of an unconscious influence on the respondents' answers. Preferably, the questions should be asked by an employee who has no personal interest in a particular outcome.
- Record both confirmed and rejected hypotheses. Information about rejected hypotheses is valuable in its own right: it allows you not to waste time re-checking solutions that have already been studied.
Product Discovery should not be considered as a formality or a delay before the "main work" — it is a mechanism that allows you to identify erroneous decisions with minimal costs. Two days of interviews with the result "the idea was not confirmed" are significantly cheaper than two weeks of development with a similar result. The general pattern is that the later the inconsistency of an idea is revealed, the higher the associated costs.
Распространенная ситуация: продакт-менеджер предлагает идею, команда в течение двух недель разрабатывает решение, фича выходит в релиз — а результата нет. Пользователи не заметили изменений, метрики остались на прежнем уровне, и на ретроспективе команда констатирует: «идея выглядела логичной».
Как правило, причина не в качестве реализации, а в том, что саму идею не стоило реализовывать — по крайней мере, в изначальном виде. Установить это можно было заранее, потратив не спринт разработки, а один-два дня на проверку гипотезы. Проверка гипотез часто воспринимается как менее приоритетная задача, поскольку интуитивно хочется быстрее перейти к разработке, а не подвергать сомнению собственную идею.
Product Discovery — это набор практик, позволяющих проверить гипотезу до того, как на нее потрачены ресурсы разработки, а не после.
От дешевого к дорогому: путь одной гипотезы
Не обязательно выбирать один способ проверки — методы выстраиваются в естественную последовательность, и переход на следующий уровень целесообразен только в том случае, если предыдущий не дал однозначного ответа.
Первый этап — интервью с пользователями. Это наименее затратный и самый быстрый способ: 5–8 коротких интервью с реальными пользователями занимают один-два дня. Важно формулировать вопросы не о гипотетическом отношении к будущей функции, а о текущем поведении — как пользователи решают задачу сейчас, какие сложности испытывают, сколько времени на это тратят. Люди склонны неточно прогнозировать собственное будущее поведение, но достаточно точно описывают уже имевший место опыт.
Если интервью подтвердили наличие проблемы, но остается неясным, как пользователи отреагируют на конкретное решение, применяется имитация — например, fake door-кнопка, ведущая к еще не реализованной функции, с фиксацией количества переходов, либо прототип в Figma, демонстрируемый вместо готового продукта. Этот метод требует больше ресурсов, чем интервью, но остается существенно дешевле полноценной разработки и позволяет получить данные о реальном интересе пользователей, а не только декларируемом.
Только после подтверждения гипотезы на первых двух этапах целесообразен переход к ограниченному запуску — функция реализуется, но становится доступна не всем пользователям: например, 5% аудитории, с возможностью быстрого отключения через флаг. Формально это уже выходит за границы discovery в узком смысле, однако именно этот этап позволяет получить данные о реальном использовании, а не предположения о нем.
Общий принцип: чем менее затратен способ проверки, тем раньше его следует применять. Переход сразу к ограниченному запуску нецелесообразен, если несколько интервью уже дают ответ на вопрос о востребованности идеи.
Практические шаги
- Формулируйте гипотезу, а не идею. Вместо «добавим фильтр по цене» — «мы предполагаем, что пользователи не находят нужный товар из-за отсутствия фильтра, что приводит к N% отказов». Гипотезу можно проверить; идею можно только реализовать.
- Заранее определяйте критерий подтверждения. Например: «если 6 из 10 пользователей на интервью самостоятельно упомянут данную проблему, гипотеза считается подтвержденной». Такой подход исключает интерпретацию результатов постфактум в пользу желаемого вывода.
- Начинайте с наименее затратного метода. Даже при высокой уверенности в идее пять интервью с пользователями требуют меньше ресурсов, чем один день разработки, и позволяют избежать недель работы над невостребованным решением.
- Разделяйте discovery и продвижение идеи. Если интервью проводит человек, лично заинтересованный в положительном результате, есть риск неосознанного влияния на ответы респондентов. Предпочтительно, чтобы вопросы задавал сотрудник, не имеющий личной заинтересованности в конкретном исходе.
- Фиксируйте не только подтвержденные, но и отклоненные гипотезы. Информация об отклоненных гипотезах представляет самостоятельную ценность: она позволяет не тратить время на повторную проверку уже изученных решений.
Product Discovery не следует рассматривать как формальность или задержку перед «основной работой» — это механизм, позволяющий выявлять ошибочные решения с минимальными издержками. Два дня интервью с результатом «идея не подтвердилась» обходятся значительно дешевле, чем две недели разработки с аналогичным результатом. Общая закономерность: чем позже выявляется несостоятельность идеи, тем выше связанные с этим издержки.
Share
