Большой клиент просит фичу: как не превратить продуктовую команду в заказную разработку

База

Программный комитет ещё не принял решения по этому докладу

Целевая аудитория

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

Тезисы

В B2B (и на внутренней разработке тоже) большой клиент может попросить фичу, которая принесёт сделку прямо сейчас. Проблема в том, что через год продукт может оказаться набором исключений для пяти крупнейших клиентов.

На примерах B2B-продуктов Яндекса разберу, как мы отделяли запрос клиента от реальной продуктовой потребности и принимали решение: делать фичу частью продукта, дать конфигурацию, решить задачу интеграцией, сделать отдельное решение или отказаться.

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

Участники уйдут с матрицей разбора, которую можно использовать на следующем планировании.

Евгений Загуменнов

Яндекс

- Последние 6 лет в Яндексе
- Запустил и руководит Yandex Crowd Solutions - помогаем крупнейшим компаниям обучать ИИ модели и реализовывать комплексные проекты с большими данными
- Ранее вывел на рынок и отвечал за линейку продуктов Яндекса для разработки и совместной работы (Яндекс Трекер, Вики, Формы, Managed GitLab). До этого развивал B2B-продукты в medtech и работал в консалтинге.
-