Делаем плохой продукт вместе: рецепт по шагам

Был такой голландский художник, Иероним Босх. Первые ассоциации на это имя обычно «а, это тот, кто такие страшилки рисовал». Действительно, его картины выглядят как кошмар или фильм ужасов, они показывают жизнь «по ту сторону» — с чертями, странными зверями, ножами.

Идея Босха заключалась в том, чтобы мотивировать зрителей жить правильно, порядочно, чтобы не оказаться на «той стороне». Именно поэтому он писал ее такой зловещей, чтобы все поняли, куда приведет непорядочная жизнь.

Сегодня я, Валерия Розова, хочу поиграть в Иеронима Босха. В поддержку своего интенсива для менеджеров продукта, на котором я учу ребят критически мыслить, структурировать свою работу и не делать в продукте лишнего, я напишу статью о том, как сделать плохой продукт. Почему я выбрала такую тему? Да потому что вокруг много чеклистов, методичек, конференций, блогов, телеграм-каналов про то, как нужно делать. Это побуждает людей суетиться, не всегда поддавать вещи критике, следить за трендами внимательнее, чем за своими пользователями или аналитикой своего продукта. Я надеюсь, что такой карикатурный формат побудит менеджеров продукта пересмотреть некоторые из своих действий и сфокусироваться на главном — на деньгах для бизнеса и на пользе для клиента.

Итак, делаем плохой продукт вместе по шагам.

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

Подход, который вы выбрали — инертный. Вы будете затыкать дырки и сублимировать деятельность, но это не отразится на метриках и развитии продукта. Убеждение, что стратегия — это для старичков, тоже неверное. Есть разные подходы к тому, как работать со стратегией. В том числе есть адаптивные модели работы, которые подразумевают частые изменения. Например, по такому подходу работает Zara, у которой цепи поставок, работа с дизайном и ассортиментом построены на принципе гибкости. Но если бы у них не было слаженной стратегии — вряд ли бы удалось так выстроить бизнес процессы.

Чем больше цель — тем выше можно прыгнуть. Несмотря на то, что мы только вчера запустили продукт, цель «быть первыми» точно приведет нас к успеху. Команда будет видеть, что у нас огромные амбиции, что мы нацелены на победу, а значит будет стараться на пределе возможностей.

Задача стратегии в том, чтобы сфокусировать и мотивировать команду. Фокус на «быть первыми» не работает, потому что он не говорит вашей команде, что им делать, чтобы быть этими первыми, а еще не говорит, в чем надо быть первыми. Таких булшит-стратегий множество, сотрудники продолжают хвататься за что попало, в итоге выходит лебедь, рак и щука. Стратегия должна быть конкретной, она должна рассказать, какую проблему мы будем решать или какую возможность преследовать, чтобы люди, которые на ежедневной основе принимают решения, могли делать это слаженно, сообща.

Разработка у нас в Trello, дизайнеры в Sketch, обычно 70% задач спринта не делаются, есть 30 фичей, которыми пользуются меньше 1% пользователей. Но мы так привыкли и смена парадигмы — огромный стресс для и так застрессованной команды. Лучше оставить все как есть, в конце концов, работа же идет как-то. Сейчас начнем менять, сломаем что-нибудь, я окажусь во всем виноват.

Конечно, окажетесь виноваты. А если ничего не будете менять — то будете виноваты еще больше, именно так работает ответственность за продукт. Никакие «исторически сложилось» не должны быть аргументом, если у вас есть логика, доказательства, лучшие практики. Если это «так сложилось» неэффективно, тратит время и силы, мешает клиентам, это надо вырывать с корнем, латать раны и идти дальше, тогда будет прогресс.

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

Кастдев не равен глубинному интервью. Customer Development — это методология разработки продукта, когда в основе твоих гипотез, фичей лежит мнение пользователя. Самый логичный и быстрый способ добыть это мнение — провести интервью. Наряду с customer development, можно выбрать competitors development и быть невероятно успешным продуктом. А вот глубинные интервью можно проводить при всех методологиях разработки, главное правильно.

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

Задача инструментов — быть удобными и приносить результат. Если этого не происходит — надо все на свете под себя адаптировать. Но, с другой стороны, тот, кто придумал методологии, не такой уж идиот. Мы продолжаем плотно сидеть на porter's five forces, rice, bcg matrix в случае, если работаем не над «пожар, туши все» и не над «надо вот эту микроштучку чуть-чуть потюнить». Короче, адаптация инструментов под себя — логичное решение. Только суть в том, что все адаптируют инструменты, так и не научившись их как следует использовать в оригинальном формате. Прежде чем прикручивать к скраму спринты длиною в годы и бесконечный бэклог, стоит разобраться, почему скрам сделали именно таким и какие функции выполняют все его атрибуты. Так же с выносом дизайна и аналитики на waterfall-формат разработки. Если вы это делаете, вы рушите свой скрам и его основы, поэтому создаются проблемы в продукте и растет time to market.

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

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

Наша задача — принимать взвешанные решения. А чтобы их взвешивать, нам нужны эксперименты. Только так можно найти истину, только так у меня будут доказательства, чтобы потом никто не обвинил меня в том, что мои решения не data-driven.

Конечно, данные и эксперименты — это основа продуктовой работы. Но почему-то творческая составляющая, умение быстро принимать решения, разумная и уместная экономия сил и ресурсов — больше не считаются ценностью и необходимыми атрибутами работы продакта. На смену data-driven пришел data-informed или data-insighted подход, суть которого в том, что данные нужно знать, но решения нужно принимать имея более широкую картину — и стратегию, и планы на будущее, и контекст конкурентов. Иногда эта картина заменяет надобность проведения дорогостоящего эксперимента.

Можно найти разные оправдания — он же b2b, для меня дороговато, да у меня нет детей, да я вообще не езжу на такси, дома мою и чиню все сам.

Думаю, лишние объяснения тут не пригодятся.

Статья подготовлена при поддержке моих учениц: Жени Барановой, Оксаны Баклановой, Оли Звегицевой, Анжелики Цукановой. Спасибо вам! Следующий поток интенсива стартует 12 мая.