Обожаю как «Rus Hanneman» из сериала «Silicon Valley» рекламирует Andrew Gazdecki и его MicroAcquire.
Сегодня на Продакт Ханте Эндрю запустил новый тул – MicroMRR by MicroAcquire – аналитика SaaS стартапов.
И как всегда – видео с Расом Ханнеманом, который очень смешно анонсирует продукт: https://youtu.be/sH0w8Z3UWao
Я так понял, что на платформе Cameo можно заказывать такие ролики у известных людей. Это уже не первый ролик с этим актёром, рекламирующим MicroAcuire.
Сегодня на Продакт Ханте Эндрю запустил новый тул – MicroMRR by MicroAcquire – аналитика SaaS стартапов.
И как всегда – видео с Расом Ханнеманом, который очень смешно анонсирует продукт: https://youtu.be/sH0w8Z3UWao
Я так понял, что на платформе Cameo можно заказывать такие ролики у известных людей. Это уже не первый ролик с этим актёром, рекламирующим MicroAcuire.
История как мы зафейлили MVP нашего Getlanding.io.
Мы потратили 3 месяца на разработку MVP который оказался никому не нужным и совершенно не решающим никаких проблем. У нас 0 клиентов. Пользователям, которые пришли на закрытую бету, он не понравился. Мы были немного расстроены и расфокусированы последние пару недель и думали что делать дальше.
Почему так получилось и какие уроки мы извлекли? Читайте на Indie Hackers (на английском): https://www.indiehackers.com/post/how-we-failed-the-mvp-of-getlanding-5827768d22.
Мы потратили 3 месяца на разработку MVP который оказался никому не нужным и совершенно не решающим никаких проблем. У нас 0 клиентов. Пользователям, которые пришли на закрытую бету, он не понравился. Мы были немного расстроены и расфокусированы последние пару недель и думали что делать дальше.
Почему так получилось и какие уроки мы извлекли? Читайте на Indie Hackers (на английском): https://www.indiehackers.com/post/how-we-failed-the-mvp-of-getlanding-5827768d22.
Indie Hackers
How we failed the MVP of Getlanding
Hey Indie Hackers! I'm Alexey, and with my co-founder Gleb, we're building Getlanding.io, a landing page generator for startups. We are bootstrapping no...
Ну наконец-то! GPT-3 теперь доступен девелоперам без листа ожиадания.
Правда есть ограничения по странам, но это уже не проблема.
Пост: https://openai.com/blog/api-no-waitlist/
Правда есть ограничения по странам, но это уже не проблема.
Пост: https://openai.com/blog/api-no-waitlist/
Стартап Саммари
О продуктовых командах #саммари из книги «Как создать продукт, который полюбят. Скотт Хёрф» 1. Наёмники создают то, что от них требуют. 2. А продуктовые команды действуют как миссионеры. Они верят в продукт и от всей души хотят решить проблемы потребителей.…
У кого-нибудь есть опыт со «Спринтом», который разработал Джейк Кнапп из Google Ventures?
Перечитываю книгу "Sprint: how to solve big problems and test new ideas in just five days" by Jake Knapp.
Вдохновился методом и мне интересно, есть ли тут кто-нибудь, кто пробовал эту методу в действии и может поделиться опытом?
Перечитываю книгу "Sprint: how to solve big problems and test new ideas in just five days" by Jake Knapp.
Вдохновился методом и мне интересно, есть ли тут кто-нибудь, кто пробовал эту методу в действии и может поделиться опытом?
Некоторым людям необходимо вести заметки по каждой Zoom-встрече. Команда что-то обсудила или продакт провёл интервью – нужно зафиксировать о чём была речь.
Делать заметки во время разговора многие не любят или не могут. Это отвлекает от разговора.
Делать заметки после разговора - тоже проблема. Надо вспоминать о чём была речь. В общем всё это долго, муторно, да и часто просто нет на это времени.
На Product Hunt запустился Fathom. Работают над решением этой проблемы. Обещают, мол, больше никаких заметок во время Zoom-звонков.
Я с продуктом пока не знаком, но на первый взгляд всё выглядит довольно хорошо. Тул записывает видео-встречу, транскрибиует в текст и помогает “разметить” встречу разными метками. Типа, 2 раза упомянул про проблему, 1 раз описал ситуацию, было 3 позитивных момента и т.д.
После встречи сразу же можно перечитать удобно транскрибированную встречу в тексте, всё проанализировать и там же написать саммари.
Ну и как обычно есть всякие интеграции со Slack и CRM, чтобы отправлять туда всё добро в 1 клик.
Fathom – участник Y Combinator (W21) и на Product Hunt его поддержали Майкл Сайбел, Гарри Тан, Райан Хувер и другие чуваки из коммьюнити. С 800+ апвоутами он занял первое место дня за 8 декабря.
Кому проблема актуальна - пробуйте, делитесь опытом. Кто уже пробовал – поделитесь опытом в комментах. Интересно.
Сайт проекта fathom.video
Делать заметки во время разговора многие не любят или не могут. Это отвлекает от разговора.
Делать заметки после разговора - тоже проблема. Надо вспоминать о чём была речь. В общем всё это долго, муторно, да и часто просто нет на это времени.
На Product Hunt запустился Fathom. Работают над решением этой проблемы. Обещают, мол, больше никаких заметок во время Zoom-звонков.
Я с продуктом пока не знаком, но на первый взгляд всё выглядит довольно хорошо. Тул записывает видео-встречу, транскрибиует в текст и помогает “разметить” встречу разными метками. Типа, 2 раза упомянул про проблему, 1 раз описал ситуацию, было 3 позитивных момента и т.д.
После встречи сразу же можно перечитать удобно транскрибированную встречу в тексте, всё проанализировать и там же написать саммари.
Ну и как обычно есть всякие интеграции со Slack и CRM, чтобы отправлять туда всё добро в 1 клик.
Fathom – участник Y Combinator (W21) и на Product Hunt его поддержали Майкл Сайбел, Гарри Тан, Райан Хувер и другие чуваки из коммьюнити. С 800+ апвоутами он занял первое место дня за 8 декабря.
Кому проблема актуальна - пробуйте, делитесь опытом. Кто уже пробовал – поделитесь опытом в комментах. Интересно.
Сайт проекта fathom.video
www.fathom.ai
Fathom AI Notetaker - Never Take Notes Again
Fathom captures, transcribes, and summarizes Zoom, Google Meet, and Microsoft Teams calls. Free for individuals, with AI-powered CRM updates for teams.
Продутовые фреймворки
На канале у Яндекса наткнулся на видео, где @michailkarpov интересно рассказал про популярные продуктовые фреймворки.
Получился такой экскурс с понятными примерами и хорошими вопросами из зала.
Продактам и стартаперам будет интересно.
https://youtu.be/xUWXnxt2-8Q
На канале у Яндекса наткнулся на видео, где @michailkarpov интересно рассказал про популярные продуктовые фреймворки.
Получился такой экскурс с понятными примерами и хорошими вопросами из зала.
Продактам и стартаперам будет интересно.
https://youtu.be/xUWXnxt2-8Q
Осторожно с опросами
Когда требуется изучить пользователей, многие продакты и стартаперы идут делать опросы, а некоторые вообще проводят фокус-группы. Проведение опросов может показаться более эффективным способом чем проведение интервью, но на старте это плохой способ.
1. Опросы предполагают, что мы знаем правильные вопросы, которые нужно задать.
Как сделать опрос, который покроет все правильные вопросы, если мы сами их пока не знаем? Например, во время интервью с пользователями мы можем задавать уточняющие вопросы и изучать области, которые были за рамками нашего первоначального понимания. Интервью – это про ислледование того, чего мы не знаем.
2. Опросы предполагают, что мы ещё знаем и верные ответы.
В опросе нам нужно не только задать правильные вопросы, но и предоставить правильные ответы. Сколько раз вы отвечали [Другое] при прохождении опросов? Лучшие ответы и инсайты приходят благодаря задаванию открытых вопросов.
3. Мы не видим людей во время опросов.
Язык тела, мимика, выражение эмоций – это такие же полноценные сигналы для Problem/Solution Fit как и ответы на открытые вопросы.
4. Фокус-группы это вообще полнейшая ерунда.
Проблема фокус-групп в том, что они отражают групповое мышление, что вообще не даёт никакой пользы для большинства продуктов.
5. Опросы вполне эффективны для проверки того, что мы уже узнали на интервью.
Интервью - это качественное исследование, которое эффективно для поиска сигналов, чтобы подтвердить или опровергнуть гипотезы при небольшом размере выборки.
Опрос – это количественное исследование. Когда мы подвтердили гипотезы при помощи интервью, то можем использовать полученные знания для составления опроса и количественной проверки этих выводов. Цель опроса будет уже не узнать что-то новое, а показать масштабируемость или статистическую значимость результатов.
Навеяно книгой «Running Lean: Iterate from Plan A to a Plan That Works»
Когда требуется изучить пользователей, многие продакты и стартаперы идут делать опросы, а некоторые вообще проводят фокус-группы. Проведение опросов может показаться более эффективным способом чем проведение интервью, но на старте это плохой способ.
1. Опросы предполагают, что мы знаем правильные вопросы, которые нужно задать.
Как сделать опрос, который покроет все правильные вопросы, если мы сами их пока не знаем? Например, во время интервью с пользователями мы можем задавать уточняющие вопросы и изучать области, которые были за рамками нашего первоначального понимания. Интервью – это про ислледование того, чего мы не знаем.
2. Опросы предполагают, что мы ещё знаем и верные ответы.
В опросе нам нужно не только задать правильные вопросы, но и предоставить правильные ответы. Сколько раз вы отвечали [Другое] при прохождении опросов? Лучшие ответы и инсайты приходят благодаря задаванию открытых вопросов.
3. Мы не видим людей во время опросов.
Язык тела, мимика, выражение эмоций – это такие же полноценные сигналы для Problem/Solution Fit как и ответы на открытые вопросы.
4. Фокус-группы это вообще полнейшая ерунда.
Проблема фокус-групп в том, что они отражают групповое мышление, что вообще не даёт никакой пользы для большинства продуктов.
5. Опросы вполне эффективны для проверки того, что мы уже узнали на интервью.
Интервью - это качественное исследование, которое эффективно для поиска сигналов, чтобы подтвердить или опровергнуть гипотезы при небольшом размере выборки.
Опрос – это количественное исследование. Когда мы подвтердили гипотезы при помощи интервью, то можем использовать полученные знания для составления опроса и количественной проверки этих выводов. Цель опроса будет уже не узнать что-то новое, а показать масштабируемость или статистическую значимость результатов.
Навеяно книгой «Running Lean: Iterate from Plan A to a Plan That Works»
Монетизация продуктов
Вчера переслушал выпуск подкаста Make Sense про монетизацию продуктов с Евгением Некрасовым. Решил засаммарить. В пост не влезло, поэтому опубликовал на Телеграфе.
https://telegra.ph/Monetizaciya-produktov-02-02
Вчера переслушал выпуск подкаста Make Sense про монетизацию продуктов с Евгением Некрасовым. Решил засаммарить. В пост не влезло, поэтому опубликовал на Телеграфе.
https://telegra.ph/Monetizaciya-produktov-02-02
Telegraph
Монетизация продуктов
Вчера переслушал выпуск подкаста Make Sense про монетизацию продуктов с Евгением Некрасовым. Решил законспектировать. 1. Евгений имеет опыт работы в стартапах и больших компаниях, например работал в Avito. 2,5 года занимался чисто монетизацией в Uchi.ru.…
Начал читать новую книжку – Talking To Humans. Success starts with understanding your customer.
Понравилась иллюстрация. Вспомнил себя когда-то. 😂🤦♂️
На всякий случай перевод:
🧔Чувак слева: “Ты правда думаешь, что это крутая идея? Мне уже не терпится расказать моему ко-фаунедру, что мы можем увольняться с работы.”
👨🦱Чувак справа: “Я говорил об этом кофе со льдом, но да, ваша идея тоже крутая.”
Понравилась иллюстрация. Вспомнил себя когда-то. 😂🤦♂️
На всякий случай перевод:
🧔Чувак слева: “Ты правда думаешь, что это крутая идея? Мне уже не терпится расказать моему ко-фаунедру, что мы можем увольняться с работы.”
👨🦱Чувак справа: “Я говорил об этом кофе со льдом, но да, ваша идея тоже крутая.”
Только что был на встрече с Майклом Сайбелом (YC CEO), организованной Питерским универом ITMO.
Это была сессия вопросов и ответов и мне удалось задать ему вопрос.
Задал простой вопрос: как найти проблему, над которой действительно стоит работать?
Он ответил что-то типа:
1. Начни работать хоть над какой-нибудь проблемой. Над любой, которая кажется стоящей. В идеале – над своей.
2. Если нет своей проблемы, присоединись к кому-нибудь, у кого есть такая проблема и работай вместе с ними. Просто работай над чем-то интересным для себя.
3. Прими тот факт, что в стартапе ты постоянно будешь терпеть неудачи. Фейлов будет больше чем успехов.
4. Если будешь воспринимать эти неудачи как уроки, а не как провалы, то со временем наткнёшься на ту самую проблему в процессе работы, и построешь нужный продукт. Но это точно займёт годы.
5. Весёлые и радостные дни в работе фаундеров случаются редко. В основном это монотонная работа и постоянные фейлы.
Это была сессия вопросов и ответов и мне удалось задать ему вопрос.
Задал простой вопрос: как найти проблему, над которой действительно стоит работать?
Он ответил что-то типа:
1. Начни работать хоть над какой-нибудь проблемой. Над любой, которая кажется стоящей. В идеале – над своей.
2. Если нет своей проблемы, присоединись к кому-нибудь, у кого есть такая проблема и работай вместе с ними. Просто работай над чем-то интересным для себя.
3. Прими тот факт, что в стартапе ты постоянно будешь терпеть неудачи. Фейлов будет больше чем успехов.
4. Если будешь воспринимать эти неудачи как уроки, а не как провалы, то со временем наткнёшься на ту самую проблему в процессе работы, и построешь нужный продукт. Но это точно займёт годы.
5. Весёлые и радостные дни в работе фаундеров случаются редко. В основном это монотонная работа и постоянные фейлы.
Завтра кто-нибудь собирается на #producncon –The Largest Product Management Conference?
Там будут выступать продакт-хэды из известных компаний типа Tinder, Booking, Salesforce, Hopin, Slack, Google, Amazon, Apple, Workato, Sephora, Twilio, Gainsight, Product School.
Начало в 8 вечера по Мск.
Подумал, что можно после нее собраться и побрейнстормить, обсудить что понравилось больше всего.
Там будут выступать продакт-хэды из известных компаний типа Tinder, Booking, Salesforce, Hopin, Slack, Google, Amazon, Apple, Workato, Sephora, Twilio, Gainsight, Product School.
Начало в 8 вечера по Мск.
Подумал, что можно после нее собраться и побрейнстормить, обсудить что понравилось больше всего.
Eventbrite
#ProductCon Online: The Largest Product Management Conference
The largest Product Management conference series in the world.
Перед началом нового проекта, в Intercom заполняют одностраничный бриф на A4.
Так написано в книге «Intercom on Jobs To Be Done».
Пригодится всем, кто задумал новый проект или новую фичу. Поразмыслить над важными вопросами – лишним не будет.
Бриф в PDF: https://s3.amazonaws.com/marketing.intercomcdn.com/assets/Intercom-Job-Story-template.pdf
Так написано в книге «Intercom on Jobs To Be Done».
Пригодится всем, кто задумал новый проект или новую фичу. Поразмыслить над важными вопросами – лишним не будет.
Бриф в PDF: https://s3.amazonaws.com/marketing.intercomcdn.com/assets/Intercom-Job-Story-template.pdf
Что значит хороший рост стартапа?
Не влезло в пост, поэтому опубликовал через Telegraph:
https://telegra.ph/CHto-znachit-horoshij-rost-startapa-04-28
Не влезло в пост, поэтому опубликовал через Telegraph:
https://telegra.ph/CHto-znachit-horoshij-rost-startapa-04-28
Telegraph
Что значит хороший рост стартапа?
Рост от месяца к месяцу В стартапах ранних стадий, месячный рост не особо важный показатель, так как даже большие проценты — это пока ещё маленькие цифры. Например, рост в 10% или 20% при $100k ARR не имеет особой разницы. На ранней стадии, на месячный рост…
Проверяем гипотезы ценности и спроса ещё до разработки продукта
Понравилась статья Проверка гипотез спроса и ценности продукта без разработки в блоге GoPractice.
Summary:
1. Первая частая ошибка — бежать делать новый продукт/фичу, не проверив гипотезы спроса и ценности. Команды уверены в своей идее и не видят смысла её проверять, поэтому сразу начинают делать.
2. Вторая частая ошибка — искать подтверждение своим гипотезам, вместо того, чтобы их проверить. Проверку гипотез делают формально. В итоге принимают решения, исходя их своих первоначальных установок, а не на основе полученных фактов.
На это 2 причины:
а) Влюблённость/привязанность к идее отключает критическое мышление. Свойственно стартапам.
б) Проверка гипотез воспринимается как часть проекта, который в любом случае должен завершиться реализацией. Даже если результаты проверки говорят, что у продукта мало шансов, проект всё-равно завершается релизом. Свойственно корпорациям с развитой бюрократией.
3. Третья частая ошибка — проверять неважные/нерискованные гипотезы. Команды проверяют что-то типа внешнего вида продукта или неосновных функций, вместо проверки ключевых гипотез — спроса и ценности. В итоге теряют время и разочаровываются в процессе проверки гипотез.
4. Гипотеза спроса — одна из самых рискованных гипотез. Заинтересована ли потенциальная аудитория в решении этой проблемы? Есть ли спрос на решение этой проблемы? А такое решение будут использовать/покупать?
а) Чтобы протестировать спрос, нужно исследовать целевую аудиторию и её проблемы/задачи. А иногда и заинтересовать или даже "продать" продукт, которого ещё не существует.
б) Во множестве случаев подойдёт лэндинг с описанием и иллюстрациями продукта. Его можно показать потенциальным пользователям/покупателям. Например, скинуть в какую-нибудь группу/чат или написать пост/статью. Например, я так делал и постил на VC, Product Hunt, Indie Hackers, Reddit и YC Startup Sсhool Forum.
в) Иногда можно обойтись и без лэндинга и просто разместить объявление на площадке, где уже собрана потенциальная аудитория. Какие-нибудь Avito, Юла.
г) Если процесс "продажи" предполагает длительное общение с аудиторией, переписки, звонки, встречи и демо, то подойдёт лэндинг + запустить рекламу (таргет/контекст).
д) Если для принятия решния о "покупке" важно повзаимодействовать с продуктом, то можно сделать прототип, в котором будет только онбординг и экран оплаты. Без контента и функционала. No-code конструкторы в помощь.
е) Если нужно протестить новую фичу в сущесвтующем продукте, помогут "поддельные кнопки". Размещаем кнопки и смотрим как кликают.
5. Когда спрос подтверждён, важно проверить гипотезу ценности – тоже рискованная гипотеза, означающая, что задуманный продукт будет приносить реальную пользу/ценность.
а) Когда продукт создаёт добавочную ценность — это обычно означает, что он будет решать проблему/задачу людей "сильно" эффективнее, чем существующие альтернативы. Иначе у них не будет мотивации переключаться на наш продукт.
б) Дать людям попробовать что-то максимально похожее на будущий продукт в деле – самый лучший способ проверить гипотезу ценности. С этим помогают прототипы, которые можно сделать на no-code, не написав ни строчки кода.
в) Иногда, даже можно сымитировать работу продукта, делая всё руками.
г) Юзабилити-тестирование прототипа помогает увидеть процесс использования продукта пользователями, а последующие интервью помогают понять — есть ли ценность у исследуемого решения или нет.
6. Создавать новые продукты — не быстро и не дёшево.
7. Браться за разработку без подтверждения спроса и ценности – играть в лоттерею.
8. Продолжать разработку, когда стало ясно, что продукт не востребован или не создаёт добавочной ценности – нет смысла.
Понравилась статья Проверка гипотез спроса и ценности продукта без разработки в блоге GoPractice.
Summary:
1. Первая частая ошибка — бежать делать новый продукт/фичу, не проверив гипотезы спроса и ценности. Команды уверены в своей идее и не видят смысла её проверять, поэтому сразу начинают делать.
2. Вторая частая ошибка — искать подтверждение своим гипотезам, вместо того, чтобы их проверить. Проверку гипотез делают формально. В итоге принимают решения, исходя их своих первоначальных установок, а не на основе полученных фактов.
На это 2 причины:
а) Влюблённость/привязанность к идее отключает критическое мышление. Свойственно стартапам.
б) Проверка гипотез воспринимается как часть проекта, который в любом случае должен завершиться реализацией. Даже если результаты проверки говорят, что у продукта мало шансов, проект всё-равно завершается релизом. Свойственно корпорациям с развитой бюрократией.
3. Третья частая ошибка — проверять неважные/нерискованные гипотезы. Команды проверяют что-то типа внешнего вида продукта или неосновных функций, вместо проверки ключевых гипотез — спроса и ценности. В итоге теряют время и разочаровываются в процессе проверки гипотез.
4. Гипотеза спроса — одна из самых рискованных гипотез. Заинтересована ли потенциальная аудитория в решении этой проблемы? Есть ли спрос на решение этой проблемы? А такое решение будут использовать/покупать?
а) Чтобы протестировать спрос, нужно исследовать целевую аудиторию и её проблемы/задачи. А иногда и заинтересовать или даже "продать" продукт, которого ещё не существует.
б) Во множестве случаев подойдёт лэндинг с описанием и иллюстрациями продукта. Его можно показать потенциальным пользователям/покупателям. Например, скинуть в какую-нибудь группу/чат или написать пост/статью. Например, я так делал и постил на VC, Product Hunt, Indie Hackers, Reddit и YC Startup Sсhool Forum.
в) Иногда можно обойтись и без лэндинга и просто разместить объявление на площадке, где уже собрана потенциальная аудитория. Какие-нибудь Avito, Юла.
г) Если процесс "продажи" предполагает длительное общение с аудиторией, переписки, звонки, встречи и демо, то подойдёт лэндинг + запустить рекламу (таргет/контекст).
д) Если для принятия решния о "покупке" важно повзаимодействовать с продуктом, то можно сделать прототип, в котором будет только онбординг и экран оплаты. Без контента и функционала. No-code конструкторы в помощь.
е) Если нужно протестить новую фичу в сущесвтующем продукте, помогут "поддельные кнопки". Размещаем кнопки и смотрим как кликают.
5. Когда спрос подтверждён, важно проверить гипотезу ценности – тоже рискованная гипотеза, означающая, что задуманный продукт будет приносить реальную пользу/ценность.
а) Когда продукт создаёт добавочную ценность — это обычно означает, что он будет решать проблему/задачу людей "сильно" эффективнее, чем существующие альтернативы. Иначе у них не будет мотивации переключаться на наш продукт.
б) Дать людям попробовать что-то максимально похожее на будущий продукт в деле – самый лучший способ проверить гипотезу ценности. С этим помогают прототипы, которые можно сделать на no-code, не написав ни строчки кода.
в) Иногда, даже можно сымитировать работу продукта, делая всё руками.
г) Юзабилити-тестирование прототипа помогает увидеть процесс использования продукта пользователями, а последующие интервью помогают понять — есть ли ценность у исследуемого решения или нет.
6. Создавать новые продукты — не быстро и не дёшево.
7. Браться за разработку без подтверждения спроса и ценности – играть в лоттерею.
8. Продолжать разработку, когда стало ясно, что продукт не востребован или не создаёт добавочной ценности – нет смысла.
GoPractice
Проверка гипотез спроса и ценности продукта без разработки - GoPractice
Как проверить гипотезу спроса и гипотезу ценности продукта без его разработки? Как с этой задачей справлялись известные продукты?
Два типа продуктовой работы
1. Есть 2 типа продуктовой работы:
– Создание ценности
– Донесение ценности
2. В некоторых случаях продуктовые команды работают чисто над созданием ценности, а другие над донесением. Но чаще всего эти типы работ идут одновременно.
3. Основа продуктовой работы — увеличивать эффективность решения проблемы/задачи.
4. Для увеличения эффективности продукта важно понимать «jobs», на которые нанимается продукт и по каким важным параметрам его выбирают пользователи.
5. Наращивание добавочной ценности и силы product/market fit как раз происходит через увеличение разницы между этим параметрами относительно других способов решения.
6. Продуктовая работа делится на 2 процесса:
– Core Product Work — создание ценности. Через функционал и улучшение характеристик;
– Growth Work — оптимизация способов донесения ценности.
7. Перед командой продукта стоят 3 верхнеуровневых задачи:
– Создать ценность. Для этого нужно построить продукт, который решает проблему/задачу в X раз эффективнее альтернатив и найти product/market fit. Это Core Product Work.
– Донести созданную ценность до целевой аудитории как можно скорее. Это работа над воронкой и активацией. Growth Work.
– Делать так, чтобы пользователи получали эту ценность как можно чаще. Product & Growth Work.
8. В идеале работа должна вестись одновременно на двух направлениях:
– Часть команды ищет способы сделать продукт эффективнее. Затачивает его под потребности сегментов, либо улучшает его ключевые характеристики.
– Другая часть команды работает над оптимизацией воронки, чтобы эффективно доносить ценность.
9. Создание ценности и её донесение — два разных типа работы. Обычно у продактов есть перекос навыков в одну или другую сторону.
10. Создание ценности — более творческая работа. Здесь важно глубокое погружение и детальное понимание проблем/задач пользователей. Приходится принимать решения в условиях высокой неопределенности. В основе такой работы лежат качественные исследования.
11. Донесение ценности — более методичная работе, требующая высокого темпа проведения экспериментов, детальной оптимизации всех ключевых путей в продукте, умения выжимать максимум из небольшого куска продукта. В этой работе количественные исследования и анализ данных играют более важную роль.
12. Продакты, которые всю дорогу занимались только созданием ценности, когда берутся за продукт, требующий донесения ценности, склонны применять свои навыки и инструменты, которые раньше давали результат, но на этапе не подходят.
13. Так же и продакты, которые набили руку на донесении ценности, когда им достаётся продукт, где нужно её создавать, склонны заниматься улучшением онбординга, модели монетизации, оптимизировать воронку, и это тоже не то, что нужно.
14. В больших продуктах, эти типы работ выполняют разные команды:
– Core Product Team — отвечает за создание ценности;
– Growth Team — работает над оптимизацией и донесением созданной ценности.
По мотивам статьи Два типа продуктовой работы: создание ценности и донесение ценности от GoPractice.
#summary #gopractice #productwork
1. Есть 2 типа продуктовой работы:
– Создание ценности
– Донесение ценности
2. В некоторых случаях продуктовые команды работают чисто над созданием ценности, а другие над донесением. Но чаще всего эти типы работ идут одновременно.
3. Основа продуктовой работы — увеличивать эффективность решения проблемы/задачи.
4. Для увеличения эффективности продукта важно понимать «jobs», на которые нанимается продукт и по каким важным параметрам его выбирают пользователи.
5. Наращивание добавочной ценности и силы product/market fit как раз происходит через увеличение разницы между этим параметрами относительно других способов решения.
6. Продуктовая работа делится на 2 процесса:
– Core Product Work — создание ценности. Через функционал и улучшение характеристик;
– Growth Work — оптимизация способов донесения ценности.
7. Перед командой продукта стоят 3 верхнеуровневых задачи:
– Создать ценность. Для этого нужно построить продукт, который решает проблему/задачу в X раз эффективнее альтернатив и найти product/market fit. Это Core Product Work.
– Донести созданную ценность до целевой аудитории как можно скорее. Это работа над воронкой и активацией. Growth Work.
– Делать так, чтобы пользователи получали эту ценность как можно чаще. Product & Growth Work.
8. В идеале работа должна вестись одновременно на двух направлениях:
– Часть команды ищет способы сделать продукт эффективнее. Затачивает его под потребности сегментов, либо улучшает его ключевые характеристики.
– Другая часть команды работает над оптимизацией воронки, чтобы эффективно доносить ценность.
9. Создание ценности и её донесение — два разных типа работы. Обычно у продактов есть перекос навыков в одну или другую сторону.
10. Создание ценности — более творческая работа. Здесь важно глубокое погружение и детальное понимание проблем/задач пользователей. Приходится принимать решения в условиях высокой неопределенности. В основе такой работы лежат качественные исследования.
11. Донесение ценности — более методичная работе, требующая высокого темпа проведения экспериментов, детальной оптимизации всех ключевых путей в продукте, умения выжимать максимум из небольшого куска продукта. В этой работе количественные исследования и анализ данных играют более важную роль.
12. Продакты, которые всю дорогу занимались только созданием ценности, когда берутся за продукт, требующий донесения ценности, склонны применять свои навыки и инструменты, которые раньше давали результат, но на этапе не подходят.
13. Так же и продакты, которые набили руку на донесении ценности, когда им достаётся продукт, где нужно её создавать, склонны заниматься улучшением онбординга, модели монетизации, оптимизировать воронку, и это тоже не то, что нужно.
14. В больших продуктах, эти типы работ выполняют разные команды:
– Core Product Team — отвечает за создание ценности;
– Growth Team — работает над оптимизацией и донесением созданной ценности.
По мотивам статьи Два типа продуктовой работы: создание ценности и донесение ценности от GoPractice.
#summary #gopractice #productwork
Каким должен быть интерфейс для пользователя?
Первое, что пришло в голову – прочитать оригинал про эвристики Нильсена.
Есть такой Якоб Нильсен, который аж в 94 году описал общие принципы интерактивного дизайна. Называются они «10 Usability Heuristics for User Interface Design»
Названы они эвристиками, потому что это чисто эмпирически выведенные правила, а не какие-то инструкции по дизайну.
Разберу каждую эвристику в отдельном посте. Пишу своими словами, как я понял.
Кому тоже актуально — можем обсудить в личке @shashcoffe
#ux #ui
Первое, что пришло в голову – прочитать оригинал про эвристики Нильсена.
Есть такой Якоб Нильсен, который аж в 94 году описал общие принципы интерактивного дизайна. Называются они «10 Usability Heuristics for User Interface Design»
Названы они эвристиками, потому что это чисто эмпирически выведенные правила, а не какие-то инструкции по дизайну.
Разберу каждую эвристику в отдельном посте. Пишу своими словами, как я понял.
Кому тоже актуально — можем обсудить в личке @shashcoffe
#ux #ui
Эвристика #1, которая называется Visibility of system status.
#summary
1. Итерфейс должен информировать пользователя о том, что просиходит в данный момент. То есть, подсказывать ему теущий статус через какую-то обратную связь.
2. Когда пользователь понимает текущий статус системы, он понимает результат своих предыдущих и будущих действий. Предсказуемые взаимодействия вызывают доверие к продукту.
3. Пример такой эвристики — «Вы здесь» на навигационных картах городов и торговых центров. Это помогает пользователю понять где он сейчас находится и куда он может пойти.
4. Никакие действия пользователя в интерфейсе не должны происходить без понятного информирования.
5. Интерфейс должен давать максимально быструю обратную связь пользователю. В идеале — мгновенно.
6. Выстраивать доверие к продукту нужно через постоянную коммуникацию с пользователем.
Если есть что добавить по этой эвристике — пишите в личку.
#summary
1. Итерфейс должен информировать пользователя о том, что просиходит в данный момент. То есть, подсказывать ему теущий статус через какую-то обратную связь.
2. Когда пользователь понимает текущий статус системы, он понимает результат своих предыдущих и будущих действий. Предсказуемые взаимодействия вызывают доверие к продукту.
3. Пример такой эвристики — «Вы здесь» на навигационных картах городов и торговых центров. Это помогает пользователю понять где он сейчас находится и куда он может пойти.
4. Никакие действия пользователя в интерфейсе не должны происходить без понятного информирования.
5. Интерфейс должен давать максимально быструю обратную связь пользователю. В идеале — мгновенно.
6. Выстраивать доверие к продукту нужно через постоянную коммуникацию с пользователем.
Если есть что добавить по этой эвристике — пишите в личку.