Как определить, нужно ли разрабатывать новую функцию.
В 2021 году я перешел от работы дизайнером продуктов в крупной компании к участию в команде стартапа - Logto.
Здесь я занимаюсь и продуктом, и дизайном. Это новая роль отличается от моего предыдущего опыта в хорошо структурированной компании с четкими процессами и методами сотрудничества. Кроме того, я потерял своего ближайшего коллегу, менеджера продукта. В результате, мне пришлось взять на себя несколько ролей, включая продукт, дизайн, исследования, маркетинг и даже управление проектами.
Моя команда и я часто оказываемся погруженными в самые сложные обсуждения, часто связанные с вопросом о необходимости внедрения определенных функций продукта и определении их объема.
В этих ситуациях мы все становимся страстно активными, высказываем наши мнения, с жаром и настойчивой позицией. Взгляды кажутся как варевом, созданным сложной машиной - в отличие от того, что записано в документах, они не организованы и не дисциплинированы.
Это связано с тем, что "интуиция" часто появляется до структурированного выражения, что приводит к кучам бессвязных обсуждений, перерастающих в философские баталии.
Мотивация написания этой статьи - организация руководящих принципов принятия решений. Эти принципы проистекают из моего личного опыта и размышлений о работе в стартапе, и это не своеобразное серебряное пуля. Я надеюсь предоставить идеи и практическую точку зрения для других предпринимателей или тех, кто занят продуктами, инжинирингом или дизайном.
Эта статья отлично подходит для чтения, если вы в следующей ситуации...
✅ Создание стартап-команды для разработки продуктов от 0 до 1, вместе с GTM (Go-To-Market) стратегиями, особенно для международного расширения.
✅ Расширение продуктов с 10 до 100 требует создания дорожной карты продукта.
✅ Руководители продуктов или сотрудники с планирующими обязанностями учатся быстро определять возможности.
✅ ICs учатся запускать новые инициативы в крупных организациях.
Эта статья НЕ отлично подходит для чтения, если вы в следующей ситуации...
❌ Неопределенные проекты, инициированные сверху вниз руководителями или руководством.
❌ Проекты, отдаленные от бизнес-целей, направленные на подтверждение влияния отдельного или независимого командного влияния.
❌ Высоко индивидуализированные требования к продукту, в основном сосредоточенные на крупных клиентах.
С абсолютной точки зрения, я даже считаю, что сохранение сосредоточенности является здравым смыслом, независимо от размера организации, так как ресурсы ограничены.
Ресурсы здесь не только финансовые ресурсы, но и время: в отношении времени как стартапы, так и крупные корпорации находятся в равных условиях.
В большинстве случаев мы должны сосредоточиться на создании масштабируемых, важных функций, которые соответствуют потребностям наших целевых пользователей и образу клиента. Продукт должен быть "убийцей боль" а не "витамином".
Сохраняя фокус, удается легче и естественнее поддерживать ясное прозиционирование продукта и улучшать понимание клиентами. Продукт стабильно продвигается к своему видению, постепенно расширяя проблемное пространство, которое он решает здоровым образом, стимулируя органический рост.
У нас не обязательно должно быть решение каждой проблемы; мы должны сохранять свою точку зрения и иметь мужество сказать нет.
Итак, давайте напишем о разных типах "сигналов" для определения, стоит ли "эту функцию разрабатывать".
Этот концепт, "поверхностные сигналы", представляет более поверхностные сигналы, которые могут служить в качестве ссылки, но до принятия решений еще далеко.
Недавно я охотно изучаю политическую науку, сравнение - способ, близкий к политическому анализу, целью которого является получение "возможностей". Более широкий взгляд может предложить новые идеи, поэтому в нашем текущем контексте изучение различных продуктов имеет смысл.
Однако, если мы слишком полагаемся на анализ конкурентов, это, как правило, приводит к принятию решений о продукте, которые не имеют стратегического мышления. Важно учитывать, почему конкурент не внедрил функцию - не соответствует ли она их ценностям, целевым пользователям, стратегическим приоритетам или ресурсам?
Итак, анализ конкурентов должен предоставлять информацию, а не абсолютное принятие решений. Это только часть процесса сбора информации для принятия решений.
Специалисты по продуктам, которые умеют понимать точки зрения пользователей и использовать сценарный вывод, могут быстро подтвердить или обнаружить новые сценарии. Однако это только гипотеза и требует дальнейшей работы в реальной среде внедрения продукта на рынок.
Хотя вывод возможных сценариев ценен, опираясь только на этот подход, можно привести к созданию "универсального" или громоздкого продукта до достижения соответствия продукта и рынка, что затрудняет последующие итерации и корректировки.
Простая аналогия - относиться к каждому выводимому пользовательскому сценарию как к стартап-проекту 0-1, учитывая мини-стратегии выхода на рынок, привнося маркетинговые перспективы и задавая трудные вопросы. Эта многомерная оценка выходит за рамки потребностей пользователей и опыта.
Часто высокочастотная обратная связь от пользователей становится руководящим принципом для разработки функций и дизайна продуктов. Однако этот руководящий принцип иногда может быть ловушкой. По мере того как я развиваюсь и работаю над большим количеством проектов, я создаю эту рамку для работы с обратной связью от пользователей,
Определите проблему и безумно и постоянно пересматривайте ее
Этот процесс будет включать много размышлений, обратного хода и дебатов, что потребует некоторого времени и усилий. Не думайте, что этот процесс бессмысленен, потому что через обсуждения он развернется и обнаружит некоторые "скрытые айсберги". Моя команда и я, как правило, легко спорили бесконечно о том, что правильно, а что нет, и о потенциальных решениях, что не хорошо. Теперь мы больше согласованы в определении того, где каждый из нас видит проблемы, и сосредоточены на решении проблем. Этот процесс очень ценный.
Устойчивое мнение против необоснованного мнения
Очень важно определить, должна ли эта функция/сценарий применяться с устойчивым или необоснованным подходом. Например, Notion - продукт с устойчивым мнением; Google Docs вроде устойчив; Microsoft Word не имеет устойчивого мнения. Для создателей SaaS, которые стремятся инновировать старую парадигму, лучше использовать устойчивый подход. Устойчивые продукты разделяют и фильтруют пользователей, и те, кто согласен с ними, с энтузиазмом выражают свою поддержку. Это чрезвычайно полезно, чтобы помочь продукту на ранней стадии найти первоначальных пользователей и создать легко понимаемое повествование.
Если вы идете с устойчивым подходом, попробуйте решить проблему с одним решением на сценарий. Если появляется альтернативное решение (Решение B для данного Сценария A), рассмотрите, действительно ли Решение A решает проблемы. Если нет, давайте пересмотрим Решение A, а не просто введем другое решение.
Продуктовые принципы Intercom вдохновили этот подход: "Создание продукта, который по умолчанию устойчив, но гибок внутри."
Признайте, что пользователи могут предложить продвинутые задачи для решения
Некоторые пользователи могут предложить использовать функцию, предназначенную для сценария A, чтобы решить сценарий B. Обнаружение этих подводных камней важно; не стоит инвестировать избыточной энергии в недостойные проблемы.
Единственная ситуация, заслуживающая внимания, - когда Решение B указывает на реальную потребность, а не просто на альтернативу Решению A. Это означает, что Решение B решает "новорожденную проблему", тесно связанную с видением и миссией продукта. Этот сигнал ценен, когда компания хочет расти дальше и обнаружить свою следующую фазу значительного расширения.
Избежание усложнения продукта не связано с игнорированием решения сложных проблем, но это напоминание о том, что расплата между "сложным, всеохватывающим" продуктом и "простым, удобным для пользователя" опытом нереалистична в реальном мире. Если вы игнорируете то, как все работает вместе (системное мышление) и лишь акцентируете внимание на исправлении проблем фрагментарного пользовательского опыта, результатом будет плохо спроектированный продукт.
Сложные продукты порождают цепную реакцию, затрудняют самообслуживание и удлиняют время, необходимое для осознания ценности продукта.
Дизайн инструментов для бизнеса (2B) в какой-то мере философский: он включает создание ментальных моделей параллельно с пользователями и установку структуры, которая может антиципировать поведение пользователя. Сложность часто возникает из-за несогласованных и неструктурированных архитектур, стараясь удовлетворить требования путем склеивания взаимодействий, что приводит к созданию продуктов, которые "выживают", а не предлагают отличные пользовательские сценарии.
Особенности, которые усложняют продукт, от требования до решения, - все плохие сигналы.
Хотя это может не помочь вам бесспорно сказать нет, это важный момент, требующий четких торгов.
Другими словами, создание функций, которые не соответствуют позиционированию продукта, повреждает и размывает образ продукта. Например, Logto - это инструмент для разработчиков, который в этот момент сосредоточен на управлении личностью. Если я скажу, давайте построим функцию маркетингового инструмента, это плохая стратегия.
Этот взгляд исходит из деловой цели компании или организации. Я видел много деятельности, которую осуществляют в промышленности или в большом корпоративном окружении, например:
В относительно стабильном операционном состоянии эти сценарии ценны и должны быть поощрены и поддержаны. Однако в сложной обстановке стартапов такие проекты требуют значительных ресурсов и времени для подтверждения ценности, что указывает на приверженность профессиональным устремлениям, а не бизнес-успеху. Это подчеркивает противоречие между личными устремлениями, убеждениями в карьере и коммерческими целями.
Несмотря на то, что инициирование проектов самостоятельно заслуживает похвалы, важно признать, что чрезмерное посвящение чему-то может не принести заслуженного возврата: я использую свой молоток, чтобы найти гвозди, затем использую линейку, чтобы измерить, насколько глубоки мои отверстия и насколько большой мой радиус - это может быть не настолько важно в общем контексте. На самом деле человек, нанимающий меня для забивания гвоздей, просто нуждается в способе повесить картину, и мне не нужно доказывать, насколько я умею обращаться с гвоздем.
Эта абстрактная, но важная точка может быть конкретно оценена: при рассмотрении функции задайте себе вопрос, будут ли пользователи существенно разочарованы, если у продукта ее не будет, что может привести к их уходу. Например, рассмотрим текущее позиционирование нашего продукта Logto для решения проблем authentication, authorization и управления пользователями/организациями. Чем ближе связана функция с этими аспектами, тем выше ее приоритет. Если у Logto нет определенной функции, насколько разочарованы будут наши пользователи? Если ответ да, это предполагает, что приоритет высок, и это наша миссия обеспечить отличный опыт разработчика для этой проблемы.
В Кремниевой долине часто подчеркиваются исследования пользователей и оценка возможностей за их практичность и строгость. Эти два аспекта указывают на то, что функция стоит исследовать и разрабатывать, когда они предоставляют положительные идеи.
Это понятие подразумевает низкие зависящие фрукты, которые приносят огромное количество радости и благ вкладывая минимальные усилия, что делает их частью личности и бренда продукта.
Среди всех анализов рациональное мышление необходимо, но также важно оставить место для интуиции. Если вы уверены, что функция является будущим, несмотря на отсутствие рациональных данных или валидации рынка, она стоит исследования.
Другие неясные функции, позволить им развиваться, и мы можем наблюдать "сигналы" со временем естественным образом.
В течение разработки продукта, предпринимательства и собеседований по приему на работу на пост продукта вас могут встретить много умозаиностимыми вопросами, в особенности в Кремниевой долине, как тема, которую я упомянул выше, должны ли мы строить эту функцию?
Хотя такие вопросы могут не иметь универсальных принципов, они требуют тщательного выполнения и обдумывания в конкретных ситуациях. Однако разложение больших и неопределенных вопросов на конкретные ответы - это навык, который строители оттачивают на протяжении своей карьеры и сверхсила для создания отличных продуктов.
Я надеюсь, что представленные рефлекции могут вдохновить ваш подход к мышлению продукта в стартапе. В Logto мы высоко ценим создание продуктов, которые любят разработчики. Мы будем рады обменяться нашими взглядами на подобные темы.