уже на ранних этапах разработки; однако низкая потребительская ценность обычно выявляется только после запуска продукта. Google Buzz и Google Wave являются реальными примерами проектов с низкой рентабельностью инвестиций. На реализацию каждого из них разработчик потратил много часов, но оба проекта были закрыты вскоре после запуска, когда по реакции пользователей стало понятно, что они не несут в себе ожидаемой потребительской ценности.
Хорошие продуктовые команды стремятся выдвигать идеи, подобные идее G, представленной на Рисунке 6.1, – то есть такие, которые создают высокую потребительскую ценность при минимальных затратах. Отличные же продуктовые команды способны, помимо этого, разбивать подобные идеи на фрагменты, отсекать наименее ценные из них и находить креативные способы создания высокой потребительской ценности с меньшими усилиями, чем планировалось изначально. Такое достижение отражено на Рисунке 6.1 сдвигом идеи G влево.
У некоторых команд вызывает затруднение числовое определение потребительской ценности функции из-за того, что, по их мнению, такая оценка получается недостаточно точной. Однако по этому поводу не стоит излишне беспокоиться, поскольку речь не идет о достижении уровня точности вплоть до десятых долей. Даже оценка затрат времени на разработку, скорее всего, не будет очень точной до тех пор, пока разработка функции не будет завершена. Вы не можете ожидать, что разработчики предоставят вам исчерпывающе точные данные, основываясь лишь на поверхностном описании функции. Точность оценок всегда будет прямо пропорциональна уровню детализации описания продукта. Суть приведенных выше расчетов заключается не столько в определении фактических значений рентабельности инвестиций, сколько в получении представления о том, как они соотносятся друг с другом. Этого будет вполне достаточно для того, чтобы сосредоточиться на реализации функций, имеющих самый высокий показатель рентабельности инвестиций по сравнению с остальными, и не тратить ресурсы на разработку функций с низким значением этого показателя.
Вы можете ранжировать свой список фрагментов функций по показателю предполагаемой рентабельности инвестиций, и это станет хорошей отправной точкой для принятия решения о том, какие блоки должны являться частью функционала кандидата в MVP. Однако строгое следование порядку ранжирования в некоторых случаях не позволяет создать полноценный MVP. Вполне возможно, что некоторые важные функции вам придется включить в его состав «вне очереди».
В качестве параметра «доход», участвующего в расчете ROI, может выступать показатель не только потребительской ценности, но ценности для вашего бизнеса. В этом случае вы можете использовать значение, выраженное в реальных деньгах. Оно будет отражать ожидаемый прирост выручки или ожидаемое снижение затрат. Предположим, например, что у вас есть действующий продукт и вы пытаетесь повысить коэффициент конверсии бесплатных пользователей в платных. При заданном уровне повышения коэффициента конверсии вы должны иметь представление об ожидаемом увеличении объема выручки. Это дает вам возможность связать каждую имеющуюся идею функции с ее ценностью, представленной уже в денежном выражении. В главах 13 и 14 обсуждаются способы повышения рентабельности инвестиций по мере улучшения показателей бизнеса и продукта.
Приблизительная оценка показателя ROI
Рассмотренная выше формула позволяет получить расчетное значение показателя рентабельности инвестиций. Однако вы также можете использовать этот инструмент для расстановки приоритетов разработки менее строгим образом. Если вы затрудняетесь с получением численных оценок потребительской ценности или затрат времени на разработку, вы можете оценить каждую имеющуюся идею функции по упрощенной шкале. В этом случае потребительская ценность и затраты оцениваются как высокие, средние или низкие. В результате вы получите матрицу размером три на три, как показано на Рисунке 6.2. Каждая из ваших идей для создания функций попадет в одну из девяти ячеек, соответствующую упрощенным оценкам ее параметров. Таким образом, даже не производя расчетов, вы сможете ранжировать эти девять ячеек на основе рентабельности инвестиций, как показано на рисунке. Таким образом, все идеи, попавшие в ячейку под номером 1, которой соответствует наибольшая ценность и наименьшие затраты, будут иметь более высокий приоритет, чем идеи, попавшие в ячейку под номером 2 и которые, в свою очередь, будут иметь более высокий приоритет по сравнению с идеями, оказавшимися в ячейке под номером 3, и так далее.
Если вы не уверены в своей способности сделать точную оценку создаваемой ценности и необходимых для этого затрат, просто используйте свои лучшие предположения, чтобы на их основе поместить каждую функцию в одну из девяти ячеек. Помните, что это всего лишь исходные гипотезы; вы сможете – и, скорее всего, будете – изменять их по мере получения результатов исследований и прохождения итераций разработки.
Рисунок 6.2. Приблизительная оценка показателя рентабельности инвестиций
Выбор кандидата в MVP
Как только вы закончите с фрагментацией, оценкой трудозатрат и расстановкой приоритетов, у вас появится возможность представить полученные результаты в простой табличной форме. В такой таблице (см. Рисунок 6.3) будут перечислены все преимущества вашего ценностного предложения, и напротив каждого из них указаны соответствующие функции в виде блоков, расставленных в приоритетном порядке.
На Рисунке 6.3 я изобразил основные фрагменты (блоки) функций для каждого преимущества. Они выстроены в порядке убывания приоритета, слева направо. Чтобы не вписывать в эти блоки названия фрагментов функций, я применил буквенно-цифровое обозначение. Так вам будет легче мысленно заменить их на фрагменты функций, относящиеся именно к вашему продукту. Обозначение «M1A» расшифровывается как «функциональный блок A для преимущества “Мастхэв 1”»; «P2B» означает «функциональный блок B для “Преимущества производительности 2”»; а «F2C» означает «функциональный блок C для “Фишки 2”». Вы можете заполнить аналогичную таблицу, используя соответствующие метки для преимуществ и фрагментов функций, относящихся к вашему продукту.
Рисунок 6.3. Лист функциональных блоков, расставленных по приоритету для каждого преимущества
После того как вы распределили свои функциональные блоки по преимуществам и расставили их в порядке приоритетности, наступает время для принятия непростых решений. Вы должны определиться с минимальным набором функций, которые предъявите целевым потребителям. Для этого следует просмотреть крайний левый ряд фрагментов функций и определить, какие из них, по вашему мнению, должны войти в состав кандидата в MVP. При этом вы должны основываться на ценностном предложении продукта. Для начала необходимо убедиться, что MVP включает все функции, которые вы отнесли к числу базовых (обязательных).
После этого следует сосредоточиться на главном преимуществе производительности, по которому вы намерены превзойти конкурентов. Для этого преимущества следует выбрать тот набор функциональных блоков, который, как вы считаете, способен убедить пользователей в том, что ваш продукт превосходит рыночные аналоги.
«Фишки» также являются тем, что выделяет ваш продукт в ряду ему подобных. Поэтому лучшая из имеющихся у вас «фишек» должна быть
