Срочный сбор, продакты⚠️ Тимлиды говорят, что вы балуетесь. Ладно, это все шутки, но нам есть, что обсудить. Я на конференции TeamLead рассказывала про shift-left в продукт — процесс, где разработка подключается с самых ранних стадий, еще на этапе генерации проблем. И знаете что? По вопросам из зала стало понятно, что процесс не работает не только со стороны разработки, глядите сами: Вопрос 1: а что нам делать, если разработка изначально бизнес-ориентированная, продакт скидывает в команду идеи, но не может сказать, зачем и что мы делаем? Вопрос 2: а как предложить продакту сделать фичу, чтобы не задеть его авторитет? Вопросы визуально разные, а корневая проблема тут одна: в discovery отсутствует сам процесс discovery. Процесс получается такой: Придумать фичу на базе ценного мнения → бросить в разработку Понятное дело, что в таком сетапе можно сильно оскорбиться, что у кого-то есть мнение, отличное от наделенных правом решать за продукт, а после придумывания фичи можно считать задачу завершенной. Го придумывать новые. В действительности же, задача продакта и продуктовой команды — решать проблемы пользователя, как я писала в прошлом посте. Если рассматривать процесс с точки зрения здорового discovery, то выглядит он как double diamond: 💎 сигнал и его валидация, генерация проблем, 💎 выбор проблемы, которую стоит решать, 💎 генерация множества решений, а не одной гениальной фичи, которую уже придумали, 💎 выбор оптимального решения, а не «я продакт, я знаю» В такой парадигме абсолютно все равно, кто что предложил по пути, если решение оптимальное и проблема решилась — это продуктовый успех. Х продуктовых успехов дадут продуктовый авторитет, а Х*N — грейдап. Можно начать прямо сейчас со статьи про double diamond. 🐳 — интересно 👾 — мое ценное мнение ценнее, чем double diamond, могу объяснить ❤️‍🔥 — читаю, нравится