Совмещаю работу в «Яндексе» и продакт-консалтинг: как, зачем и почему

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

Привет, меня зовут Данила Березин, и я технический проджект-менеджер в колонках с Алисой. До этого я работал в red_mad_robot, делал ТендерФлоу, реализовывал идеи других стартапов и одновременно получал продуктовую экспертизу «в полях». Мне интересны долгосрочные проекты, сложные задачи. Но иногда хочется переключаться на что-то ограниченное по времени и ресурсам. Поэтому я стал искать сторонние кейсы, где мог бы применить свою экспертизу и поработать с чем-то новым. Так занялся продуктовым консалтингом — помогаю небольшим проектам и стартапам.

Было непросто зайти в тему “с мороза”. У меня есть набор скиллов, но на старте много вопросов: как найти клиентов, где найти время качать пайплайн, на что сделать акцент при упаковке услуги, что важно вынести в условия. Я не понимал, как это засетапить. В процессе узнал, что я такой не один — есть комьюнити и разные возможности искать проекты.

Сегодня опишу весь путь на примере одного интересного кейса — как нашёл, как планировал время, о чём важно договориться на берегу, чтобы все оказались в выигрыше.

Итак, продуктовый консалтинг — это, пожалуй, уже комьюнити. Кейс, о котором пойдёт речь, я нашёл через друга — Никиту Абраменко, ex-CEO «Потока». Он решил объединить продактов, чтобы вместе искать интересные проекты. Так появился сервис GoExpert.pro. И меня позвали в мой первый проект — нужно было поработать с сервисом «Моё дело».

Как я выстроил работу:

1. мы чётко определили задачу и сроки;
2. оговорили, сколько времени я могу тратить на проект в день — это 1–2 часа;
   
3. обсудили оплату, составили план и приступили к работе.
   

Теперь самое интересное — как всё прошло с точки зрения продуктологии. Задача у заказчика была такая:

Ситуация довольно классическая для многих компаний в России.

Позволю себе обобщить эти проблемы и показать, как они работают у других клиентов на рынке.

1. Если выражаться языком продакта, у данного клиента не поставлен единый для всех команд Discovery process или, как часто бывает в множестве компаний, поставлен лоскутно. В чём тут боль? СЕО и акционерам нужно видеть существенный шаг в создании нового, который можно измерить. Когда единого процесса нет и команды бегут в разные стороны, сложно их сравнить. Если в компании 5–10 команд, у каждой свои процессы — это радикально усложняет администрирование и менеджмент.

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

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

Мы подготовили и согласовали общую для всех команд методологию Discovery, прописали чёткие шаги, дополнили обучающими материалами по Lean Startup и Cust Dev. Ниже прилагаю скрин фреймворка.

Мы использовали такой фрейм:

1. работа над гипотезами о масштабе и ценности;
2. Lean-канвас;
3. качественные исследования (как минимум, по 12 интервью на персону);
4. снова канвас;
5. User story map;
6. итоговая презентация продукта на рынке.

В нём нет ноу-хау, он содержит довольно известные методы, позволяет отслеживать этапы и чётко идти по шагам. Хорошо подготовить его на старте, тогда и стейкхолдер, и команда сразу понимают, что мы делаем.

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

С чем столкнулись команды по пути:

• Командам сложно выделять много времени на работу с новыми идеями
  —> от консультанта ожидается драйвинг и вовлечение команд и в случае чего эскалация проблем на стейкхолдера, как и в обычной проектной деятельности.
• Уровень продактов в командах различался, некоторых приходилось по ходу работы подтягивать
  —> провели обучающие воркшопы про cust dev, уделил внимание совместной работе над канвасами.
• По ходу дела одна из команд отвалилась, так как сложно было тянуть дополнительный объём работы
  —> стоит проговорить со стейкхолдером такую версию развития событий заранее, чтобы сформировать ожидания и избежать вопросов после.
  

Классная практика просить команду сразу упаковывать наработки в слайды итоговой презентации. Это помогает участникам собрать общую картинку и обнаружить слабые места продукта. Мне как консультанту — выставить чёткий дедлайн, согласовать результат и назначить демо-день для руководства. Заказчику — увидеть, что он получит и в какие сроки.

На выходе мы получили три проработанные бизнес-модели, команды защитили продукты на demo day, и теперь работа идёт уже без нас. Команды готовятся запускать MVP. Считаю, это хороший результат. Для меня это стало отличным опытом. Я протестировал для себя такой формат, понял, что это возможно совмещать с работой, заработал 250к за 2 месяца part time, получил удовольствие и кейс. И фидбек от клиента:

На этом всё. Буду рад ответить на ваши вопросы, рассказать про фреймворк, условия работы с клиентами, вообще про любые вопросы на эту тему. Пишите в комментарии или в личку.

See ya!