Сегодня расскажу о блоге SVPG и его авторе Марти Кейган.
В блоге много классных статей на тему продукта и управления командой, например Product teams vs feature teams, Empowered product teams или Four big risks. Плюс Марти автор двух книг на тему разработки продукта, INSPIRED и EMPOWERED1.
Я не берусь пересказать 40+ опыта автора в одной короткой статье, поэтому выбрал для рассылки несколько тезисов из его лекции Product is hard.
Как обычно, курсивом авторский текст и дальше мои комментарии.
To motivate developers show them customers in pain
Одно дело, когда вы как продакт рассказываете разработчику, что нужно сделать и совсем другое – когда он наблюдает это сам в записи юзер сессии, на созвоне в zoom или в чате поддержки. Тогда объяснять ничего уже не надо. :)
Don't celebrate release itself, celebrate results it achieves.
Пользователю все равно, сколько story points вы сделали за этот спринт или как отсортированы карточки в вашем беклоге в Asana.
Любой релиз хорош настолько, насколько он влияет на бизнес-метрики и/или помогает нам лучше понять наших пользователей, чтобы применить это понимание в следующем спринте.
Solving business problems instead of building features from the roadmap
Выполнение задач “из беклога” часто создает у команды ложное ощущение прогресса – “мы выполнили 9 из 10 проектов, запланированных на этот квартал ⇒ мы молодцы”.
Nobody cares.
Единственное, что имеет значение – создание ценности для пользователя.
If your backlog longer than a month it’s probably because of technical debt
Игра с техническим долгом это игра с огнем.
Если вы не можете быстро отреагировать на новый запрос рынка или повторить фичу, которую анонсировал ваш конкурент, потому что любые изменения в продукте требуют x10 усилий и занимают непредсказуемое время из-за технического долга – это проблема.
Моя любимая мантра на эту тему: “фича на 15 минут должна занимать 15 минут от идеи до продакшн”. Если простые фичи занимают от получаса до недели – вы не можете ничего. Это значит нужно отложить все другие задачи и чинить разработку, потому что у вас ее по факту нет.
Most agile teams are really practicing Waterfall
Чтобы не было waterfall:
Валидация бизнес-рисков до начала разработки vs после релиза
Оценка успеха в терминах бизнес-метрик vs фич
Инженеры участвуют на этапе discovery vs идут по готовому PRD от ПМ
PM must talk to customers if he wants to make product decision, otherwise there is little reason to believe his thinking is solid.
‘Nuff said.
См. также:
ALL CAPS это к автору :)