Продукт, IT и жизнь / Александра Кочанова

Как продакту чувствовать себя уверенно?

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

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

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

И весь прикол работы продакта, как раз в том, что однозначного ответа, хорошо твое решение или нет, может и не случиться. Проверяя гипотезу, вы можете наткнуться на то, что какие-то метрики выросли, а какие-то безнадёжно просели. И вот чтобы вам не прятаться как улитка в домик и не отказываться от каждого своего решения которое не стало на 100% успешным, вам нужны хорошие аргументы на старте и продуманные стратегии, что делать в случае если произойдёт непредвиденное.

Начнём с того, что любое продуктовое решение формируется с проблемы. Нельзя просто прийти и сказать «а хочу попробовать сделать вот так, будет лучше». Лучше может и будет. Но зачем, если все и сейчас хорошо. Поэтому всегда начинаем с проблемы. Есть проблема у бизнеса или проблема у пользователя. В идеале проблема бизнеса должна быть приземлена на проблему пользователя. То есть нельзя просто размышлять так, что вот у бизнеса недостаточна выручка, давайте подумаем как ещё продавать получше.

Нет, нужно понять, как приземлить проблему бизнеса на проблему пользователя. У бизнеса недостаточная выручка, значит пользователь почему-то не хочет платить за продукт. И дальше мы начинаем исследовать, где и почему он не хочет платить. Может быть он не хочет платить больше, или он выбирает самые дешёвые тарифы, и так далее. То есть в идеале, всё равно всегда мы должны прийти к тому чтобы решить проблему пользователя. Это теория хорошего продуктового подхода.

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

Если вы точно можете объяснить, что проблема действительно существует, что она достаточно крупных масштабов и что её решение может принести хороший доход или рост других метрик (а все равно косвенно влияет на доход 😁), то это уже пол дела к тому, чтобы команда, с которой вы будете заниматься реализацией, вам доверяла.

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

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

Продолжение

www.group-telegram.com/jp/product_and_life.com/1013

275 viewsedited  Dec 19 at 05:51

Как продакту чувствовать себя уверенно?

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

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

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

И весь прикол работы продакта, как раз в том, что однозначного ответа, хорошо твое решение или нет, может и не случиться. Проверяя гипотезу, вы можете наткнуться на то, что какие-то метрики выросли, а какие-то безнадёжно просели. И вот чтобы вам не прятаться как улитка в домик и не отказываться от каждого своего решения которое не стало на 100% успешным, вам нужны хорошие аргументы на старте и продуманные стратегии, что делать в случае если произойдёт непредвиденное.

Начнём с того, что любое продуктовое решение формируется с проблемы. Нельзя просто прийти и сказать «а хочу попробовать сделать вот так, будет лучше». Лучше может и будет. Но зачем, если все и сейчас хорошо. Поэтому всегда начинаем с проблемы. Есть проблема у бизнеса или проблема у пользователя. В идеале проблема бизнеса должна быть приземлена на проблему пользователя. То есть нельзя просто размышлять так, что вот у бизнеса недостаточна выручка, давайте подумаем как ещё продавать получше.

Нет, нужно понять, как приземлить проблему бизнеса на проблему пользователя. У бизнеса недостаточная выручка, значит пользователь почему-то не хочет платить за продукт. И дальше мы начинаем исследовать, где и почему он не хочет платить. Может быть он не хочет платить больше, или он выбирает самые дешёвые тарифы, и так далее. То есть в идеале, всё равно всегда мы должны прийти к тому чтобы решить проблему пользователя. Это теория хорошего продуктового подхода.

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

Если вы точно можете объяснить, что проблема действительно существует, что она достаточно крупных масштабов и что её решение может принести хороший доход или рост других метрик (а все равно косвенно влияет на доход 😁), то это уже пол дела к тому, чтобы команда, с которой вы будете заниматься реализацией, вам доверяла.

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

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

Продолжение

BY Продукт, IT и жизнь / Александра Кочанова