Product Discovery на кастомных проектах

В предыдущей статье мы обрисовали некоторые черты, которые отличают хорошую команду, работающую над product discovery, от отличной. Но что это вообще за процесс такой, чем он так важен? И что нужно иметь в виду при работе над кастомным проектом?

Product discovery - это начальный этап разработки продукта. Несмотря на название, на этом этапе нужно не только выяснить, что должен из себя представлять продукт, но и зачем его создавать в принципе.

Продукт или его новая функция должны решить какую-то проблему пользователя. Цель команды - разобраться в этой проблеме настолько глубоко, чтобы качественно организовать дальнейшую разработку. Настоящая сложность в том, чтобы внимательно сосредоточиться на проблеме как таковой, прежде чем переходить к поиску решения, и накопить достаточно объективных данных, чтобы принимать непредвзятые решения. Только так от product discovery будет толк.

Это логичный подход для тех, кто занимается собственным проектом, но что насчет разработки на заказ? Если клиенты буквально говорят, что они хотят получить, и ставят сжатые сроки, зачем тратить время на вопросы “а зачем?” вместо “как?”, верно?

Не верно.

Во-первых, собрать требования клиента не значит понять их. А без понимания шансов сделать достойный продукт маловато.

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

Итак, product discovery нужен в общем-то любому проекту, который целит в создание полезного и коммерчески успешного продукта, кастомные проекты - не исключение. И все же при кастомной разработке процесс немного отличается. В этой статье мы расскажем о нашем подходе и о том, почему этот этап повышает шансы успешно запустить продукт.

1 the customer can contribute to the development process significantly min

Заказчик может внести значительный вклад в процесс разработки

Inventale запускает высокотехнологичные проекты на основе методов машинного обучения и искусственного интеллекта с 2015 года. У команды за плечами десятки проектов, созданных с целью за секунды выполнять задачи, решение которых обычно занимает до нескольких часов или вовсе не выполнимо для человека. Наш опыт позволяет с ходу оценить основные технические требования проекта.

Наши клиенты, напротив, являются экспертами в совсем других областях, которые они хотят улучшить с помощью технологий. Они находят потребности пользователей и бизнес-возможности, а зарываться в мелочах процесса разработки - уже наша забота. Мы не ждем, что партнер подготовит для нас пошаговый план проекта, а составляем его вместе.

Партнер знает свой рынок и перспективы продукта. Мы эксперты в продуктовой разработке. Наше сотрудничество - все, что нужно, чтобы создать отличное решение. Поэтому мы активно привлекаем наших клиентов к product development как экспертов. Вместе мы можем разработать свежую концепцию продукта, установить адекватные требования и подобрать оптимальные характеристики.

2 custom project development entails some extra needs and limitations min

Разработка на заказ влечет дополнительные сложности и ограничения

Product discovery - трудоемкий процесс. Команда постоянно переключается между постановкой проблемы и поиском решения, и таких проблем нужно проанализировать очень много. При этом работа над кастомным проектом ничуть не легче.

Команда разработчиков не имеет власти над бюджетом, техническими возможностями и сроками клиента. Следовательно, разработчики должны придумать, как выполнить работу за ограниченное время, в рамках ограниченного бюджета и с доступными партнеру инструментами.

В 99% случаев клиент не будет конечным пользователем продукта, а значит команде надо проработать двойной объем проблем и установок, часто конфликтующих между собой.

Маневрировать в этом хаосе - отдельный вид искусства, но и его можно постичь. Секрет в планировании, фокусе, расстановке приоритетов и адаптивности (ладно, может, секретов и многовато):

  • У продукта всегда есть первостепенная цель, и планирование должно гарантировать ее достижение. Но поскольку ничто не идет точно по плану, рекомендуем планировать с запасом.
  • В ходе product discovery изначально нужно разобрать много вопросов, а в процессе обсуждений возникнет еще куча побочных неясностей. Чтобы дискуссия не затерялась в дебрях второстепенных вопросов, нужно удерживать фокус на главном.
  • Время - деньги, и у каждой проблемы своя цена. Тратьте время на задачу в соответствии с ее важностью: иногда бюджет можно безболезненно сократить, а иногда стоит расщедриться.
  • Вероятно, самый важный момент: цель product discovery не в том, чтобы найти идеальное решение, а в том, чтобы найти решение, идеально подходящее для данных несовершенных обстоятельств. Другими словами, адаптировать то, что имеется, чтобы получить то, что нужно.

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

3 the product discovery team should include both people who know the end users and will develop the product min

В команде product discovery должны быть и те, кто знает конечного пользователя, и те, кто участвует в разработке

Product discovery - ключевой этап разработки, так как определение цели продукта, архитектуры и дизайна напрямую влияют на успех проекта. Немудрено, что состав команды на этом этапе не менее важен.

Есть два подхода к конфигурации команды для product discovery:

  1. Выделить отдельную команду, которая во всех проектах компании занимается исключительно product discovery и передает свои наработки команде разработчиков. Так команда может отточить свои навыки и щелкать планирование однотипных проектов как семечки.
  2. Обычная команда ведет проект от начала до конца, от product discovery до запуска на рынок. Это наш подход. Так команда экономит время, погружена в контекст и полностью контролирует процесс. Плюс, нет риска напортачить при передаче знаний от одной команды другой.

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

В зависимости от проекта можно подключить нерегулярных участников: сотрудников отдела продаж или работы с клиентами, CPO, возможно, даже инженеров DevOps и других специалистов. Кастомные проекты отличаются тем, что некоторые из этих ролей могут выполнять специалисты команды заказчика.

Еще одна тонкость заключается в том, что, опять же, конечный продукт должен удовлетворить как пользователей, так и владельцев. Вовлечение клиента обычно решает вопрос с владельцами, а вот для поиска болевых точек целевой аудитории потребуется помощь команды по работе с клиентами. Так что мы бы включили в основной состав специалистов, работающих с пользователями, на постоянной основе.

4 a proper product discovery opens an unhindered path to a successful mvp min

Надлежащий product discovery способствует успешному MVP

Даже из самых блестящих идей иногда рождаются неудачные продукты. По этой причине разработчики не торопятся с имплементацией, пока не проверят почву с помощью Minimum Viable Product - упрощенной версии будущего продукта, которая в идеале должна приносить пользу пользователю. А поскольку главную ценность продукта несут его основные функции, дизайн MVP зависит от приоритизации функций.

Как правило, при планировании MVP команда разработчиков и UX-специалисты выполняют целый ряд действий:

  • составляют карту пользовательских сценариев,
  • оценивают технические возможности и ограничения,
  • планируют запуск функций исходя из результатов предыдущих этапов,
  • координируют объем работ и план разработки с взаимосвязанными процессами на стороне клиента, например, маркетинговыми кампаниями.

Все эти шаги легко охватить еще на этапе product discovery, поскольку его цель - понять потребности пользователя, продумать сценарии использования продукта, оценить доступные инструменты и учесть это все при определении дизайна продукта. Результат анализа фиксируется в виде приоритизированного backlog-списка, что очень кстати для организации дальнейшей разработки. А участие в процессе заказчика в роли эксперта значительно облегчает координацию между командами.

По сути, если провести product discovery, то заодно и MVP будет практически готов.

В качестве бонуса простой совет по приоритизации функций: используйте матрицу влияния/усилий или ее вариации.

Матрица влияния/усилий

Группировка задач по четырем простым категориям помогает балансировать между технической сложностью и потенциальной пользой и при этом полагаться на объективные факты (или, по крайней мере, честные оценки), а не на догадки.

5 the product discovery team needs both leeway and timeframes min

Команде по поиску продуктов нужна свобода действий, но четкие сроки

Метод product discovery предполагает, что команда начинает вовсю работать над проектом без утвержденного дизайна продукта. Это позволяет сделать продукт лучше, так что пожертвовать определенностью - вполне оправданный шаг. Вот чем метод может смутить, особенно на кастомных проектах, так это тем, что без фиксированной цели сложно рассчитать точные сроки выполнения. Это может показаться особенно рискованным для команд, которые привыкли к классическим дорожным картам, графикам и каскадной модели разработки.

Однако творческая свобода не отменяет планирование. Опытная команда учитывает лимит возможностей клиента, и время - один из этих лимитов. Так что вместо отработки списка задач по расписаниям, спущенным сверху, команда выясняет, что можно сделать в принципе, и приоритизирует задачи так, чтобы уложиться в общие временные рамки. В остальном работа мало чем отличается. У команды все еще есть регулярные проверки, дедлайны и сроки сдачи-приема.

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

  • Команде нужны четкие дедлайны, чтобы понимать, насколько задача критична, когда она должна быть завершена и, следовательно, как глубоко ее анализировать.
  • Регулярные проверки помогают вовремя поймать проблемы, на которых команда застряла, и найти решение, не выбиваясь из графика.
  • Ну и наконец, команде нужно набить руку. Чем чаще команда использует этот метод, тем проще ей подстраивать его под себя.

Каждый проект и продукт уникальны, но все успешные схожи в одном: они угадали со временем выхода на рынок, аудиторией, используемыми технологиями и спецификой бизнеса. Чтобы наши проекты пополняли ряды успешных стартапов, мы прислушиваемся к мнению клиентов и работаем с ними сообща.

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

Светлана Петрянина
Светлана ПетрянинаКопирайтер