Баканов про ...
2.3K subscribers
51 photos
1 video
1 file
125 links
Привет, я Денис.

Уже 15 лет в ИТ, а в 2021 закончил MBA в РАНХиГС.

В канале рассказываю про опыт запуска стартапа и разработку ИТ-продуктов, делюсь полезными ссылками и мыслями.

Создаю крутые решения в своей студии https://apeek.ru

TG: @dbknv
Download Telegram
Искать инвестиции в РФ или за пределами?

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

В прошлом проекте мы хотели изменить подход к обучению софт-скилам для руководителей и лидеров. Мы сделали ставку на обучение через симуляторы. Похожие механики используются при обучении продактов в GoPractice & SkillSetter.

Свой стартап мы развивали по методологии Lean Startup. В основе это подхода лежит базовый концепт: сначала находим аудиторию, верифицируем их и только после этого давим на газ и заливаем деньгами. Такой подход позволил нам сохранить сотни тысяч рублей личных инвестиций. Мы использовали NoCode/LowCode решения, которые ускоряют проверку гипотез без необходимости разрабатывать продукт. А на финальных стадиях мы гнали настоящий трафик из рекламных кампаний. Ух, мы могли покупать рекламу в [запрещенных социальных сетях]. Славное было время и воронка продаж предсказуемая. 


Мы не добежали до этого шага, так что дальше будут рассуждения.


Когда найден сегмент с сильной болью и есть понимание, как делать продукт – нужно вливать деньги в разработку. Мы планировали потратить от 1 млн руб. собственных инвестиций. За это время мы бы успели собрать MVP, измерить метрики, посмотреть рабочие механики и воронку продаж. И дальше идти за большими инвестициями в seed-stage, а потом в Stage A раунды


Seed-stage
На этом этапе ищется инвестор, кто верит в три вещи:
• команду
• проект
• существующий рынок для этого продукта


Stage A
На этом этапе команда доказала, что они могут не только создать продукт, но и продавать его. И самое важное: привлечь запланированное количество клиентов. Если все получилось, то можно идти за следующим траншем инвестиций – Stage A. Он позволит масштабировать продукт и расширить воронку продаж для привлечения новых клиентов.


Последние два года такой венчурные инвестиции со скрипом и болью работали в РФ. Даже появились компании-стратеги, которые были готовы покупать стартапы (Сбер, Яндекс, ВК). Но кажется, что этот инструмент сломался.

Как выкручиваться из этой ситуации сейчас? Выводить продукт сразу на международный рынок? #product
Известные мне ограничения юнит экономики

Думаю, что любой продакт или предприниматель, который делает цифровые продукты знаком с термином юнит экономики. В ИТ-продуктах любят цифры, метрики и измерять все доступное. А юнит-экономика – это симбиоз метрик и денег в проекте. То есть наиболее важная часть продукта.

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


Ограниченные сверху

Average Price – это цена вашего продукта, по которой он уже продается. Задается рыночной стоимостью у конкурентов.

Average Payment Count – ограничен JTBD сценарием. Какие-то продукты покупают для ежедневного использования, другие же раз в год или реже.

Margin – ваша маржа, которая заложена в продукт. У нее есть нижняя планка – это издержки, необходимые для создания продукта.

Таким образом, Average Margin Per User, который рассчитывается по формуле AvPrice*AvPaymentCount*COGS, уже сильно зажат другими метриками. А следовательно, чтобы увеличить выручку, необходимо поработать с этими тремя метриками. Но на практике сделать это непросто, так как есть ограничения рынка. 


Еще важные метрики

Conversion 1 – это конверсия пользователя в первую покупку. Кстати, ее почти всегда считают неправильно.

User Acquisition – можно получить из аналитики. А можно получить экспериментальным путем.


Таким образом, зона сходимости экономики сильно ограничена и даже свободные параметры, тоже ограничены и задают малое количество сценариев развития продукта. Например, вы не сможете увеличить конверсию в покупку с 3% до 70% или поднять средний чек в 10 раз. 

Предварительный расчет юнит-экономики и точек роста помогает в двух случаях
• задать целевые метрики Conv.1, AMPU, Margin, User Acq
• найти плечи метрик – когда нужно последовательно работать сначала с одной метрикой, а затем с другой. 

А это уже помогает в сортировке и приоритизации гипотез в роадмепе продукта. #product
Перестаем ломать процесс онбординга

Onboarding  – это процесс адаптации и обучения пользователя работе с приложением. Онбординг в мобильном приложении или на веб-сайте должен придерживаться двух правил: 
• быть максимально простым
• помогать пользователю конкретный момент, а не заранее

Главная задача нового пользователя – получить ценность от использования продукта сразу. Одни пользователи справляются с этой задачей интуитивно (на основе прошлого опыта), другим же требуется обучение на старте. 

Онбординг обучает пользователя взаимодействию с приложением. Если пойти дальше, то необходимо проектировать UX/UI так, чтобы пользователю вообще ничего не потребовалось изучать дополнительно. А решать свою задачу он смог бы сразу после регистрации. Но мы часто создаем сложные приложения с большим функционалом и уровнями абстракций. Если не рассказать про них, то пользователь ничего не поймет и уйдет.

Чтобы определить, что включить в онбординг, нужно разложить процесс использования продукта на CJM (Customer Journey Map). А дальше выбрать наиболее важные компоненты, без которых клиент точно не разберется с приложением. Помогать пользователю сначала нужно с базовыми концептами и терминологией вашего приложения. 

Я бы выделил четыре основных механики:
• пошаговые руководства
• учебные пособия 
• образцы данных в полях
• советы

В завершение добавлю, что тайминг невероятно важен. Не нужно заранее напихивать пользователю 20 советов и заставлять проходить визард из 15 шагов. Это не работает, так как когнитивная нагрузка слишком большая, а ценность продукта еще неясна. Сначала доносим ценность продукта и лишь затем нагружаем пользователя своими подсказками. 

И последнее: мозг с трудом запоминает больше трех-пяти шагов. Не делайте длинные обучающие экраны. Лучше их разбить на несколько коротких и показывать каждый в нужный момент. #product
Рассмотрим три понятия: желание, проблема и боль.

Желание
Вот было бы классно научиться планировать личные финансы. Человек с таким желанием, скорее всего, ничего дополнительно не сделает. Вероятно, хватит на переход по первым трем ссылкам в поисковой выдаче. В идеальной ситуации человек даже найдет список литературы для изучения. Но по факту, через месяц, ничего в его жизни особо не изменится. Это как после новогодних праздников поставить себе задачу ходить в спортивный зал.

Проблема
У человека с трудом хватает денег от зарплаты до зарплаты. И вроде бы зарплата хорошая и деньги есть, но к концу месяца приходится экономить. То есть человек вроде страдает, но не очень. Да, проблема тут есть и он ее осознает. Но потерпеть нужно всего недельку и деньги снова появятся. И история пойдет по кругу.

Боль
Человек покупает квартиру в ипотеку. Допустим, что на первую половину ему достались деньги по наследству. А вторую часть он берет в банке под проценты. Через месяц он понимает, что его финансов хватает только на 20 дней в месяц. А платеж в банк съедает 50% от его зарплаты. И вот этот человек будет очень мотивирован найти решение из ситуации: зарабатывать больше, найти вторую работу или оптимизировать траты. Он самостоятельно, без внешнего пинка сделает всю работу по поиску сам и найдет решение.

Чем дальше человек двигается от стадии желание к стадии боль, тем активней его погружение в решение этой задачи. Хорошо, когда мы знаем боли своих клиентов. Тогда продавать продукт им проще. А если мы знаем только хотелки, то такие клиенты будут постоянно говорить: а давайте еще вот это и вот это добавим в предложение, а мне не хватает такого функционала и вот эта кнопка не того цвета. #product
Развивать бизнес по цифрам или довериться сотрудникам?

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

Сейчас читаю книгу "Открывая организации будущего", в которой описывается архетипы организаций от янтарной до бирюзовой.

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

Оранжевые – нацелены на эффективность, опираются на советы экспертов, строят логические цепочки "что+если". Пример: крупные международные компании.

Зеленые – жизнь не только работа, сохраняет меритократию, инвестируют в обучение сотрудников, вкладываются в культуру компании и ценности для сотрудников.

Бирюзовые – самая хайповая тема для обсуждения сейчас. Самоуправляемые и без жесткой организационной структуры.


В бирюзовых компаниях сотрудники самостоятельно оценивают и выбирают себе задачи. В работе опираются на взаимную помощь. Внутри компании организовываются десятки небольших групп, которые договариваются друг с другом и внутри себя. Публичные примеры:

Valve. Разработчик игр и магазина Steam. У них один из самых высоких показателей выручки на сотрудника в мире (Не могу найти точную цифру, но она кратно выше, чем у MAMAA)

Zapos. Онлайн-магазин обуви с лучшим сервисом для своих клиентов. Основатель сам рассказывает, что их сотрудники в колл-центрах могут загуглить недостающие позиции в корзине клиента и заказать ему. А еще они платят около $3000 за то, чтобы новичок не вышел на работу после испытательного срока.

Вкусвилл. Ретейлер с вкусной едой и лучшим сервисом. Мой личный опыт подтверждает, что они сильно опережают в этом конкурентов в РФ.


Мы в своем агентстве практикуем ритуалы из бирюзовых компаний. Ведь наши сотрудники самые ценные, а их мнение полезно для поиска точек роста.

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

Организации – это сложные и комплексные системы, в которых сложно предсказать, как одно действие повлияет на другое. Важно уметь подстраиваться в процессе работы. Находить точки роста из состояния здесь и сейчас, делать развороты и пробовать новые подходы. Если бизнес перестал экспериментировать, то он просто доживает. Его обгонят конкуренты, которые готовы рисковать.

Это как с катанием на велосипеде в лесу. Есть план доехать до конца, но нет цели придумать жесткую последовательность действий (поворот руля на 5 градусов, потом три оборота педалей и так далее).  Также и в бизнесе. Цифры (ROI, ROMI, LTV, CAC) – это индикаторы, которые отражают состояние. Но опираться только на них в своих решениях нельзя. Нужно смотреть на ситуацию шире. #product
Создаем привычку пользоваться продуктом

Когда мы работаем над созданием продукта, то нам нужно балансировать между сухой математикой (метриками) и интуитивным видением. Важно не забывать, что главное – это приносить пользу людям. Ведь они центр продукта, без них не будет, ни метрик, ни цифр, не выручки. Не будет ничего. Продукта тоже не будет. 


Создаем привычку-ритуал

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


Стать лучшим другом

Этот способ подойдет для B2B продуктов. Когда компания выстраивает канал связи с клиентом. Помогает с его с рутинными задачами, подсказывает, что нужно делать. Я недавно открыл ИП и счет в одном желтом банке. Так они мне подарили книгу "Бизнес без MBA". Ха-ха, а ведь MBA то у меня уже есть. Но сама книга прям хороша – рассказывает про базовые ошибки начинающих предпринимателей: общению с клиентами, юнит-экономике, кассовых разрывах, ведению переговоров. А суть-то бесплатной книги простая – максимально долго удержать нового клиента. Банку нет никакого смысла потерять платящего проценты предпринимателя. Через бесплатную книгу они увеличивают собственный LTV. При этом они решают проблемы своих клиентов. Win-Win.


Узнать своих пользователей

Кажется, что тут все просто. Анализируем поведение своих пользователей. На основе привычек добавляем ценность вашему продукту →  увеличиваем привычку использование продукта. Как думаете, зачем банки запустили формат историй в своих приложениях?


Уменьшать когнитивную нагрузку

Мало кто любит нагружать специально мозг. Эволюция нас приучила к тому, что мы запоминаем просты ходы. А они нас уже приводят в желаемое состояние. Этим можно пользоваться и создавать новые привычки у пользователей. При проектировании важно учитывать простоту использования. Каждый дополнительный шаг, требующий нагрузки, снижает конверсию. 


Игровые механики

Ачивки, достижения, игровой процесс. Это помогает мозгу расслабиться и не думать. А еще мы любим награды. Помните FourSquare, в которым можно было стать мэром города, ресторана или бара? Игровая механика в чистом виде.


А какие инструменты вы замечаете в продуктах? #product
Запустить MVP и не превратить в техдолг

Запуск первых прототипов связан со срезанием углов при разработке. Если можно, что-то не сделать, то лучше это не делать. На этапе первых прототипов запросто можно не делать личные кабинеты, настройки и даже полноценную авторизацию пользователей. Важно обрезать и выкинуть все вокруг главной ценности продукта. И только после того, как MVP сработала – можно вкладываться в жирок продукта. Главное не переборщить, как Nero CD Burner (если кто еще помнит такой комбайн для простой записи CD дисков). 

Если разрабатывать продукт быстро будут баги – это нормально, без этого никуда. Но важно помнить, что потом НЕ будет времени исправить. Уже будут живые пользователи, которые заходят в ваш продукт каждый день. И вот им совсем не прикольно получать сломанное приложение после обновлений. Работоспособность нужно поддерживать. А вы еще хотите расширять функционал, а это дополнительная разработка. При этом вектор развития продукта может меняться каждый месяц.

Самая лучшая технология – это та, с которой умеет работать именно ваша команда. Нет никакого смысла разрабатывать на каком-то хайповом языке или фреймворке. Используйте то, что умеете. Это придаст вам скорости в разработке. Я десятки раз видел, как команды ставили все на то, что вот эта супер новая технология исправит вообще все проблемы. И нет, она не исправляла. Приходилось также закапываться в детали. Но теперь у вас два стека или два ключевых ПО, от которых просто не можете отказаться без отката назад.

Если есть возможность – используйте силу комьюнити. Мы привлекали экспертов, самих разработчиков ПО, на индивидуальные консультации в наши проекты, когда у нас не получалось вывозить производительность. Это быстрей и дешевле, чем месяцами капаться самостоятельно и изобретать кастыли, заматывая их изолентой.  

В разработке сильно помогают фреймворки. И даже не один, а сразу несколько на одном проекте. Так продукт писать быстрей, но у этого решения есть расплата – производительность. Но с ней есть смысл заморачиваться, когда у вас уже лавина клиентов. А если их нет, то кому нужен ваш безупречно вылизанный код, который может выдержать 1 млн RPS?

И последнее: доставляйте ценность, а не фичи для клиентов. #product
Энергия пользователя

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

User Energy Framework используется для системного анализа и повышения активации в первую сессию. Интернет-компании используют Product Led модель продаж – это когда продукт сам себя продает. Получается, что в этом случае продажники особо не нужны. По такой модели работают, например, Dropbox, Notion, Evernote и еще куча всего. Суть Product Led – показать ценность продукта как можно быстрей для клиента. И если на классической продаже пользователю бывает сложно уйти от продавца, то в Product Led – достаточно закрыть вкладку.

Возвращаемся к энергии пользователей. В самом начале у клиента самое большое количество энергии. Пусть даже он совсем не устал за рабочий день и руководитель его не выбесил. Его бак энергии будет заполнен на 90%. И тут он переходит по рекламе в ваш продукт. Сначала его встречает лендинг и он пытается в нем разобраться: зачем мне нужен это продукт, почему текст непонятный, что вообще продукт делает. Вроде бы разобрался и захотел попробовать. Но тут его встречает форма регистрации на 12 обязательных полей и еще пароль нужно повторить два раза. 

Его энергия потихоньку начинает заканчиваться, а приложение раздражать. Каждый последующий шаг отнимает силы у пользователя. А каждый клик снижает конверсию. А сразу после входа у него обязательный онбординг на 8 экранов с минутным видео. Мы ведь разработали крутой и сложный продукт. Обязательно нужно научить и показать каждую фичу в самом начале, а то новый клиент не поймет ценности и уйдет. В итоге через 5 минут у пользователя уже нет сил, а продукт его раздражает. И он уходит.


Отнимают силы:
Когнитивная нагрузка. Нужно принимать сложное решение в моменте, произошла непонятная ситуация и нужно разбираться в причинах, нестандартный паттерн UX/UI. Например, пустой проект после регистрации, 20 непонятных кнопок, 6 уровней абстракций ведения проектов.

Физическая нагрузка. Сложная форма регистрации, как в примере выше. Нужно сокращать поля до самых важных, а остальную информацию можно запросить через неделю использования сервиса. 


Дают энергию:
Визуальные элементы. Они подбадривают и рассказывают, что у вас крутой продукт. Делаем более яркий UI и более просты элементы. Человек должен зацепиться за интерфейс и захотеть продолжать использование.

Награда. Когда человек понимает, чего добился. Узнал что-то новое или получил признание. Например, показываем  онбордиг над продуктом. Это говорит, что осталось еще чуть-чуть и будет счастье. #product
Лучше проверить сырую идею, чем потом показать продуманную

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

Для начала стоит ответить всего на четыре вопроса:
• Какую задачу пользователя решаем?
• Как будем проверять гипотезу?
• Как будет выглядеть финальный продукт?
• Сколько ресурсов нужно для MVP?

Вроде бы это известные вопросы каждому продакт-менеджеру. Но часто хорошей идее на первых порах не хватает адекватного фидбека. Который помог бы скорректировать вектор развития с самого начала. А это уже позволит сэкономить ресурсы команды и время (бесценный ресурс) на старте. 


А вот их внутренний флоу:

• После одобрения идеи автор собирает MVP с минимальным использованием кода и представляет его на User Hour – внутренняя встреча со сторонними пользователями.

• Следующий этап – Ready for Dev. Это встреча продактов и дизайнеров, которые досконально анализируют идею продукта.

• Дальше – продуктовая встреча, где продакт рассказывает о состоянии сейчас. Показывает roadmap продукта на следующий год.

• Внутренний бета-тест. Любой из сотрудников может протестировать новый функционал до появления в паблике. На этом этапе собирается множество багов и улучшений со связанными продуктами. 

• Рассказ о продукте на всю компанию. На встрече собирается обмен мнением с топ-менеджерами, поиск точки роста и синергии с другими продуктами.

#product
Создаем привычку пользоваться продуктом

Когда с сервисом все хорошо, то заходить в приложение нет никакой необходимости. Помните еще то время, когда банк-клиенты были приложениями, в которых можно было только деньги переводить? Это, наверное, классический случай выхода приложения из "зоны комфорта". 

Чтобы заставить пользователя чаще открывать приложения – необходимо добавлять новый смысл взаимодействия. Клиент будет открывать приложение чаще → повышается вероятность дополнительных продаж → юнит-экономика становится сильней.

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

Одной из первых механик были пуши, которые вытаскивали пользователя из его контекста, завлекая его в приложение. Но пуши уже не работают так хорошо – слишком много мусорных нотификаций приходит каждый день. Поэтому пришлось искать новые каналы для повторного открытия приложения.

Если клиент открывает приложение раз в месяц, то достучаться до него очень сложно. У нас слишком мало касаний для рекламы. А чем чаще он открывает приложение, тем больше шансов сделать дополнительную продажу. Тут можно возразить, что это реклама, на которую я не подписывался. Справедливо. Но если предлагают внутри хороший продут за адекватные деньги, то почему бы и нет? 

Как думаете, что банки придумали? Да, это истории, как в Instagram. Сначала туда начали помещать просто новости компании, затем добавили аналитику именно по тебе, а потом сделали подобие блога с короткими историями. А может быть порядок был немного другой. Уже не вспомню, да и неважно это особо.

Клиенты стали заходить чаще, смотреть истории и рекламу. Retention вырос, MAU (Monthly Active Users) пошло в гору, а это фундамент крепкой юнит-экономики любого продукта. Пусть даже один процент пользователь перейдет по рекламе. Уже профит, который компании стоит в десятки раз дешевле, чем привлечение клиентов снаружи (контекстная реклама, интеграция с блогерами и тд). #product
Клиентский сервис как воронка продаж

Довольно часто на рынке присутствует десятки схожих продуктов или услуг. Например, для работы с электронным документооборотом (ЭДО) есть почти десяток облачных операторов. В целом они похожи между собой и выполняют одну и туже задачу. Где-то один лучше, а где-то другой. У каждого своя сильная сторона. 

Еще в 2018 году, когда я занимался развитием ЭДО в одной крупной компании – мне понравился клиентский сервис в Контуре. Отвечают быстро и по делу, практикуют омниканальность. Например, я писал им свои вопросы в Telegram и мне отвечали за 5 минут. При этом никаких этих умных ботов, которых нужно 10 раз попросить оператора, чтобы он наконец переключил на оператора. 

Ну, знаете этих голосовых ботов:
– Добрый день, задайте свой вопрос и мы постараемся ответить на него
– Не работает кнопка изменения тарифа в приложении (ну либо любой другой сложный вопрос)
– Не понял вас, попробуйте задать вопрос заново
– Оператор
– Подскажите по какому вопросу вас соединить с оператором
– Оператор

И так по кругу, много раз. Бесит. Часто в этом флоу вообще нельзя никак выскочить из голосового помощника. Кстати, для банков есть лайфхак – сказать "хочу оформить ипотеку" и сразу же получаешь живого человека. 

Итак, когда мне потребовалось для своего юр лица оформить ЭДО – я, естественно, пошел в Контур.Диадок. За первые месяцы у меня возникали вопросы, которые я за считаные минуты решал с живым человеком в чате TG. Все четко и прозрачно для меня. И вот мне потребовалось вести онлайн-бухгалтерию. Как думаете, кого я выбрал среди всех продуктов? Контур.Эльба. Мне нравится их сервис и первым делом дал им шанс.

Вот такая простая механика, как адекватная работа с потенциальным клиентом, позволяет компании увеличивать число активных пользователей. Еще год я не был их клиентом, а сейчас уже использую два продукта. #product
Открыто проверяем спрос на продукт
 
Как проверить новую идею на прочность? Экспериментальным путем. Проверять идем в закрытых чатиках – не нужно. Стейкхолдеры часто ошибаются в своих предсказаниях. А что еще хуже, то неохотно принимают обратную связь.
 
Особенно это присуще большим организациям, которые стараются казаться стартапами и быстрыми. Но это далеко не так. Сделать лендинг, посмотреть на него, собрать аналитику и изменить – это путь стартапа, который проходят за две недели. В крупной же компании неожиданно появляются десятки стейкхолдеров, Tone Of Voice, ценности компании. И ты уже не понимаешь, как каждое слово нужно согласовать с десятком людей. И ведь каждый считает, что его мнение важно. Оно и правда нужное, но совершенно не помогает в стремлении быть быстрым. 
  
Что нужно для проверки спроса на продукт:
• анализ рынка/клиентов
• глубинные интервью с целевой аудиторией
• стартап канва Остервальда
  
И самое главное – тестирование идей в бою. Нет никакого смысла целый год культивировать идею внутри себя. Лучше ее 4 раза выкатить в продакшен, словить все грабли и через год получить то, что реально нужно. 
  
Я не один раз ошибался на первых этапах: получал неправильную обратную связь, а следом разрабатывал не то, что нужно в продукте. Направление было правильное, но никто не мог представить, что именно вот это сценарий самый важный. А мы его перенесли в конец разработки. Причем этот график согласовали со стейкхолдерами. А потом очень быстро перекраивать весь релизный цикл. У кого-то бывает по-другому? #product
Как оценить, какие проблемы чинить

Мы, как продакт-менеджеры, часто проводим много интервью с респондентами. Запускаем CusDev и JTBD исследования и получаем из них много полезных знаний про проблемы клиентов. Часто хочется сразу бежать и исправлять все и сразу. Ведь несколько клиентов на нее пожаловались → она важная!
 
Но лучше сначала побыть немного аналитиком:
• Сначала оцениваем критичность задачи от 0 до 10
• Потом оцениваем частотность проблемы от 0 до 10
• Пытаемся понять, на какую метрику продукта она влияет
• Прикидываем, насколько именно исправление этой проблемы повлияет на метрику
• На основе изменения метрики получаем изменение выручки продукта (через юнит-экономическую модель)

А дальше выписываем все идеи, гипотезы предположения в табличку и сравниваем их между собой. Находим топ-идей и уходим в детальный разбор проблемы. Если нужно фиксим. 

Чинить нужно критичные и частотные проблемы. Тут логика простая: каждый раз, когда пользователь сталкивается с проблемой,  продукт его раздражает. А это следом закрепляет негативную ассоциацию с продуктом.
 
Еще важно не забывать про деньги. Встречаются ситуации, когда проблема действительно есть. Но ее исправления хотят пользователи из неплатящего сегмента (фримиум модель внутри большого платного продукта). А рядом может лежать проблема у платящей аудитории. Какую вы бы стали брать в работу первой? #product