Как построить стартап по принципам стоиков. Часть 8: организовываем продакт-менеджмент

Часть 1, Часть 2, Часть 3, Часть 4, Часть 5, Часть 6, Часть 7, Часть 8, Часть 9, Часть 10

Еще раз возвращаемся к фатальным ошибкам стартапов. Портал CB Insights самой главной неудачей назвал отсутствие запросов рынка на продукт стартапа (no market need). 

И дело не в том, что с самого начала инициатива была надуманной (хотя такое тоже может быть). Вся суть в развитии: сначала идеи и целей, потом — MVP, а затем — уже работающего продукта. Иными словами, суть — в управлении продуктами, product management.

Важное замечание: эта статья максимально нейтральна к разным методологиям (популярным нынче agile, scrum, спринтам и прочим) и основана на собственном опыте познания, мнение может отличаться от вашего. Но вы можете попробовать это дома.

Что такое product management

Product management — это относительно новая система знаний, которая сочетает маркетинг, технологическую базу и теорию менеджмента и привносит свои подходы. 

Адекватнее всего, с моей точки зрения, оценивать product management как «дочку» этих трех дисциплин, новое поколение — не научное-«тейлоровско-друкеровское», а прикладное постмодерновое. 

Цель — построить наиболее эффективные и органические бизнес-процессы для решения болей клиентов через продукт и поддерживать процессы в хорошем состоянии. 

Бизнес-процессы — это составная часть цикла product management. Цикл приблизительно можно разделить на этапы:

• постановка целей;
• выявление и проверка гипотез;
• работа с усовершенствованием MVP проверенных и валидированных гипотез;
• полноценное внедрение;
• корректировка целей — постановка новых;
• и дальше заново по пунктам.

Какие принципы должны учитываться на всех этапах?

• Обязательное «раскапывание» болей клиента как основа для всего цикла.
• Важность скорости и быстрой проработки гипотез.
• Отсутствие «перфекционизма» при валидировании гипотез, готовность к отказу от них.

Постановка целей

И тут работает все: и SMART-принцип, и допущение «отказываться от целей из-за изменения контекста — это нормально»... Но я бы хотела более подробнее остановиться на «ребенке» KPI — OKR (Objectives and Key Results). 

Разобраться, как это работает, мне помогла Наринэ Варданян, product manager сети клиник «Севергрупп Медицина». Эта компания — далеко не стартап, но продакт-команда внутри — быстро развивающееся направление с опорой на собственно разработанные технологические продукты. 

Так вот, об OKR. Как следует из названия, есть две части: цели и ключевые результаты. Первый элемент может быть обязательным или «вдохновляющим». 

• Пример цели обязательной: уменьшить количество возвратов товаров на 25% в этом квартале. 
• Пример цели вдохновляющей: стать в этом году тем приложением, которым Леонардо Ди Каприо будет пользоваться каждый день и расскажет об этом хотя бы одному СМИ. 

Второй элемент включает каскад показательных метрик. Как мы узнаем, что цель достигнута полностью или частично? Через три-пять ключевых результатов. 

Например, получить более двух тысяч оценок 5.0 в App Store до 10 декабря или стать партнерами экологических организаций, где участвует Леонардо Ди Каприо.

Что при этом важно?

• Все люди в компании видят цели друг друга.
• Обратная связь (один на один с руководителем или тимлидом) происходит как можно чаще (оптимально — раз в неделю). Если есть препятствия сценарию А, то он оперативно меняется на А* или В.

Выявление и проверка гипотез

Вот тут начинается самое интересное: все agile, scrum и другие семейства обитают в основном здесь. Эти методологии нацелены на способы создания и развития идей, разделения команд. Этот момент я пропускаю, чтобы не задеть ничьи чувства. 

Зато остановлюсь на рекомендациях для мягко работающего цикла product management «всех возрастов»:

• раскопка гипотез благотворна на большой выборке — этому в значительной степени способствуют онлайн-инструменты (Google Forms, аналитика «Яндекс.Метрики» и Google Analytics, таргетинг);
• по статистике, подтверждается только одна из десяти гипотез (10% конверсии — это нормально!);
• лучше всего проверять минимум одну гипотезу в неделю (идеальный сценарий);
• при этом в единый момент времени работать только над одной гипотезой (последовательный, не параллельный подход);
• общий посыл — чем проще, тем лучше. На этом этапе главенствует регулярность, а не глубина или перфекционизм (чтобы не тратить все волевые ресурсы «в стол»).

Да, это идеальная картина, а как все выглядит на самом деле? 

Я поговорила со стартапом стадии А Sizolution, который занимается определением оптимального размера одежды и обуви для онлайн-ритейлеров. Проект сейчас активно развивается на немецкоязычных рынках. 

Сооснователь проекта Ваге Таамазян рассказал, как у них выстраивается управление продуктом — и, в частности, формирование гипотез и перевод их в реальные действия. Если вкратце, то:

• источниками циклов становятся запросы клиентов (В2В) и собственный wish list, куда любой сотрудник может написать выведанные инсайты (и который подвергается инвентаризации примерно раз в пару месяцев).
• Все процессы ведутся в Trello, на разных досках.
• Каждый день все доски просматриваются (15-20 минут около экрана компьютера product manager).
• Все продуктовые гипотезы выходят в отдельные проекты, циклы (например, введение продукта на измерение размера обуви) или в процессы (например, мониторинг точности алгоритмов).
• Как только появился отдельный product manager, команда села и свели все продукты в единый приоритетный лист, а также приоритизировали все открытые инициативы.

И еще один кейс — стартап SegmentStream стадии А+, который занимается сквозной маркетинговой аналитикой для e-commerce. Проект прошел программу SAP Techstars в Берлине, а в 2020 году планирует активно развиваться на рынке Великобритании. 

Сооснователь и Product Owner Олег Катрышев поделился тем, как выстроены процессы, связанные с управлением гипотезами. 

• Главное правило — не делать вещи, которые не нужны рынку. При появлении новой идеи гораздо выгоднее потратить две недели на общение с текущими и потенциальными клиентами, чем начать писать код. Лучше вообще никакой код не писать.
• С другой стороны — важно не делать все, что от вас просит рынок. Иначе продукт может превратиться в агентство. На мой взгляд, лучшие продукты рождаются на пересечение самобытного видения команды и потребностей рынка.
• Ритуалы. Так как календари у всех разрываются от встреч — очень сложно и эмоционально затратно каждый раз планировать синки команд продукта, разработки, продаж, поддержки. Лучше сразу запланировать на несколько месяцев вперед периодические встречи. У нас это — синк продуктовой команды со всеми другими командами, sprint-planning, product-demo.
• Product-demo — полезная вещь. За один час в две недели вся компания понимает, что мы успели сделать за этот короткий срок, как этим пользоваться, продавать и какая потенциальная польза есть для клиентов.
• Важная вещь, которую уяснили в ходе программы TechStars: продукт — это не просто набор фич, технических составляющих. Важно учитывать и аудиторию, цену, упаковку, документацию, расходы на будущую поддержку.

Отличия налицо, но основа одна и та же: скорость, регулярность, основа — запросы от клиентов и их потребности.

Работа с MVP и полноценное внедрение

На этих этапах много ситуативного, поэтому можно выделить только общие рекомендации:

• если нужен pivot или любая коррекция на этом этапе, то это нормально. Главное — это решение и уточнение решения боли клиента;
• уточнение решения может быть на узкой выборке, экстенсивный подход может или не дать ответов, или сделать это поверхностнее и менее доверительно;
• здесь высокая скорость уже не так важна, можно добавить «щепотку» перфекционизма.

Большой бизнес vs стартап: есть ли разница?

Интересно было мнение обеих сторон. И вот что я услышала: большой бизнес не видит особой разницы, а вот стартапы не торопятся с суждениями. Основными отличиями становятся материальная мотивация и скорость. И эти пункты могут стать критическими в функционировании команды. 

Однако и та, и другая стороны сталкивались с тем, что у каждого человека свое понимание product management. Поэтому сложно делать категоричные выводы, стоит смотреть на свою команду, контекст и динамику изменений самого продукта.

Фото в тексте и на обложке: Unsplash