#kano #model #features #prioritization

Объяснение модели Кано: анализ и примеры

Модель Кано – метод, используемый для оценки эмоциональной реакции потребителей на отдельные фичи продукта. Все фичи можно разделить 5 категорий: нежелательные, неважные, обязательные, одномерные и привлекательные. О чем статья:

👉 Что такое модель Кано
👉 5 категорий модели Кано
👉 Проведение опроса клиентов для Кано-анализа
👉 Использование результатов

#marketing #targeting #facebook

Эффективный таргетинг: как попасть в свою целевую аудиторию

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

👉 Тестирование сегментов: тогда и сейчас
👉 Копии адсетов, чтобы «попасть в пласт»: тогда и сейчас
👉 Детальный таргетинг: тогда и сейчас
👉 Как правильно использовать детальный таргетинг и Lookalike

​​#abtests #abtesting #cheatsheet

A/A/B-тестирование – процесс, при котором пользователей делят на три части: первую и вторую направляют на продукт без изменений, а третью с изменениями.

Что это дает:

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

#ux #usability #design

10 правил юзабилити. Разбираемся на примерах

Ребята из Forte Group решили разобраться в 10-ти правилах эвристики, на которых зиждется весь User Experience. Чтобы ваш продукт не превратилось в головоломку, проверьте его на следование 10 правилами юзабилити:

☝️ Видимость статуса системы
☝️ Схожесть системы с реальным миром
☝️ Свобода действий для пользователя
☝️ Следование стандартам (привычкам)
☝️ Предотвращение ошибок
☝️ Узнаваемость и простота восприятия
☝️ Гибкость интерфейса
☝️ Простота и минимализм
☝️ Понимание проблем и их решение
☝️ Справочные материалы и онбординг

#audience #marketing #startup

Как составить портрет целевой аудитории для стартапа?

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

👉 Что такое портрет целевой аудитории
👉 Сегментация целевой аудитории
👉 Способы определения целевой аудитории

​​#cheatsheet #model #habits

9x Effect – эффект, характиризующий сложность смены привычки для потенциальных пользователей вашего продукта.

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

#mobileapps #market #research

Как новые привычки пользователей влияют на рынок приложений в 2020-м году

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

#abtests #abtesting #advice

Ухудшающие A/B тесты – cамый недооцененный инструмент менеджера продукта

Ухудшающий A/B тест – это такой экперимент, при котором тестируемую область в продукте не улучшают, а наоборот, ухудшают: замедляют, делают менее отзывчивой и т. д.
Если соответствующие метрики не падают, то и улучшать данную область, скорее всего, не имеет смысла.

Что еще вы надете в статье:

👉 Три стадии эволюции A/B тестирования в компаниях
👉 Примеры использования ухудшающих A/B тестов
👉 Аргументы против ухудшающих A/B тестов
👉 Неумышленные ухудшающие A/B тесты

#custdev #mvp #pmf

Как найти продукт, соответствующий рынку: пошаговое руководство

Исчерпывающий гайд по запуску продукта:

👉 Что такое PMF (product-market fit)?
👉 Почему так сложно сделать стартап успешным?
👉 Какие шаги необходимо предпринять, чтобы определить, соответствует ли продукт рынку?
👉 Как оценивать результат и правильность своих действий?

#pitchdeck #investing

Несколько важных правил хорошего питчдека

О чем статья:

👉 Иногда сам продукт — идеальный питч-дек
👉 Чем меньше оформления — тем лу…
👉 Если нужно объяснять — не нужно объяснять

#graphics #unit #map #economics

Полная карта юнит-экономики 🔥

Она поможет увидеть взаимосвязь между метриками и четко понять, как, изменяя одну из метрик, мы влияем на конечный результат.

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

#automation #apps #marketing

15 мобильных приложений для маркетологов, которые ценят каждую минуту

👉 Hootsuite – инструмент для управления контентом в социальных сетях, который позволяет планировать публикацию постов, а также отслеживать активность в аккаунтах.
👉 Planoly – визуальный планировщик для Instagram. Приложение показывает, как будет смотреться каждый отдельный пост в сочетании с другими публикациями в аккаунте.
👉 Mention – приложение, которое помогает находить и отслеживать упоминания бренда по всему интернету.
👉 Asana – инструмент для командного управления проектами.
👉 Canva – пригодится тем, кто ищет инструмент для быстрого и удобного создания визуального контента.

Больше приложений вы найдете по ссылке.

#feedback #rating #repeat

Взломать фидбек в мобильном приложении: получаем инсайты и повышаем рейтинг

Отзывы и оценки в сторах несут не только декоративную функцию. Они напрямую влияют на конверсию и количество пользователей приложения.

В статье рассматриваются следующие моменты:

👉 На что может влиять рейтиг приложения
👉 Как и зачем собирать фидбек в приложении
👉 Хитрый лайфхак по механике сбора фидбека
👉 Подборка вопросов, которые можно задать пользователям

Учтите, что мобильный фидбек – это не замена рейтингам и отзывам в магазинах приложений, в идеальном мире они должны работать рука об руку.

#case #wellness

Кейс: как мы набивали шишки с Mental Wellness мобильным приложением

В статье автор рассказывает об истории создания одного из наших продукта Mental Mirror и попытке выхода на mental wellness рынок.

Основные хедлайны:

👉 Предыстория
👉 Исследование и Early Adopters
👉 Разработка продукта
👉 Proof of concept
👉 Результаты
👉 Новые гипотезы и итерация

#sales #pretotyping #mvp

20 способов продавать с первого дня. Как быстро и дешево проверить свою идею?

👉 Ручные продажи и Custumer Development
👉 Landing Pages + Трафик
👉 Промопсты в Fb или VK на целевую аудиторию
👉 Реклама или рассылки с A/B — тестированием
👉 Краудфандинг. Boomstarter, Kickstarter и т. п.
👉 Объясняющее видео и его промо
👉 Конструктор готовых модулей WordPress
👉 Интеграции с помощью Zapier
👉 Тесты и опросы в Typeform
👉 Сбор сообщества
👉 Ручное моделирование функционала/консьерж
👉 Цифровой прототип/мокап
👉 Бумажный прототип (или на 3d-принтере)
👉 Одна простая функция
👉 Предзаказ и 100% гарантия возврата
👉 Бесплатная помощь, бесплатные консультации
👉 Мероприятия, вебинары
👉 Лидогенерация для других
👉 Гостевые посты
👉 Бесплатные доски объявлений/блоги и т. п.

#ab #abtesting

Ошибки I и II типа во время AB-тестирования

💡 Ошибки первого типа также известны как альфа-ошибки или ложные срабатывания.
💡 Ошибки второго типа называют бета-ошибками или ложноотрицательными результатами.

Из статьи вы также узнаете про последствия таких ошибок и способы их избежать.

​​Минутка юмора 😋

👉 Новый Agile Manifesto | Часть 1

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

❌ Люди и взаимодействие важнее процессов и инструментов.
✅ Команда и ответственность важнее индивидуумов и взаимодействия.

Почему старое – неактуально? Потому что раньше, чтобы стать разработчиком, нужно было разбираться не только в структурах данных и алгоритмах, но и немножко сечь в архитектуре. Порог входа в специальность был намного выше, чем сейчас (почти 20 лет назад): инструментарий языков был беднее, фреймворков было меньше, технологии были сложнее. Чтобы изучать тему, приходилось вникать самому или общаться на форумах. В таких условиях хороший разработчик действительно был "высокомотивированным специалистом", который должен уметь взаимодействовать с такими же, как и он, профессионалами.

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

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

Да и сами команды теперь нужно трактовать намного шире. Это уже не просто совокупность разработчиков, тестировщиков, архитекторов или других технических специалистов, но и продактов, маркетологов, UX-специалистов, аналитиков и т. д., потому что подход к построению продуктов стал другим.

❌ Работающий продукт важнее исчерпывающей документации.
✅ Бизнес ценность важнее работающего продукта.

Концепция "работающего продукта" была выдвинута в первом манифесте в ответ на долгий цикл проектирования (читай написания документации) и разработки ПО, когда первую работающую версию продукта получали ближе к концу проекта. И пока работали в таком ключе над проектом, кто-то более гибкий уже запускал продукт и получал прибыль.

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

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

В итоге, даже разработав "гибко" продукт, в нем может тупо не оказаться бизнес-ценности. Поэтому именно поиск и разработка бизнес-ценности (product discovery) стала намного важнее самого программного обеспечения. И если команда концентрируется на первом, при этом не написав и строчки кода, это правильный подход.

👉 Новый Agile Manifesto | Часть 2

Продолжаем разбираться с новшествами второй версии Agile Manifesto:

❌ Сотрудничество с заказчиком важнее согласования условий контракта.
✅ Развитие партнерских отношений важнее сотрудничества с клиентом.

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

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

❌ Готовность к изменениям важнее следования первоначальному плану.
✅ Готовиться к изменениям важнее реакции на изменения.

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

Вспомним историю. Когда ПО строилось по "изначальным планам", выраженным в скучных технических заданиях, его разрабатывали долго. Но знаете... Оно работало! Оно реально работало. С переходом на гибкую разработку, реагирующую на изменения, мы получаем продукты быстрее, но их качество оставляет желать лучшего. В итоге, ПО, разрабатываемое таким образом, довольно быстро доходит до пределов возможностей своей бизнес-логики, утопая в техническом и архитектурном долге, после чего приходится пилить новый продукт, который сможет проблемы старой системы. Тем самым, та пресловутая гибкость, о которой говорится в манифесте, оборачивается жесткими ограничениями в развитии.

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

🔥 Стратегии, с помощью которых Dropbox, Netflix, Uber и другие популярные сервисы привлекли первых пользователей

Ленни Рачински провел исследование, как популярные потребительские приложения получили первых пользователей. На протяжении месяца он общался с основателями крупных компаний, собирал информацию в интервью, соцсетях и публикациях ИТ-изданий. Вот что получилось:

✅ Tinder искал пользователей в колледжах и студенческих организациях

На начальном этапе сооснователи Tinder Уитни Уолф и Джастин Матин ходили вокруг Университета Южной Калифорнии и рассказывали о сервисе в мужских и женских студенческих сообществах. Одинокие студенты и студентки интересовались поиском одиноких партнеров — и Tinder завирусился.


✅ Lyft и Uber ходили в офисы стартапов и транспортные узлы

Сотрудники Uber ходили по улицам и раздавали реферальные коды, а команда Lyft предлагала знакомым стартапам получить бесплатное мороженое, попутно с раздачей брикетов мороженого рассказывая о Lyft.


✅ Snapchat раздавал листовки в торговых центрах

Сооснователь и глава Snapchat Эван Шпигель раздавал в торговых центрах листовки и рассказывал людям интересные подробности о сервисе, а заодно — сразу скачивал им приложение и демонстрировал его возможности.


✅ Dropbox использовала Hacker News

Создатель облачного сервиса Дрю Хьюстон создал простое видео, в котором объяснял принцип работы Dropbox. В апреле 2007 года он опубликовал ролик на Hacker News с заголовком «My YC App: Dropbox — выбросите свою USB-флешку». Это привлекло первых пользователей.


✅ Netflix внедрялся в тематические сообщества

Менеджер Netflix Кори Бриджес называл себя не сотрудником Netflix, а маскировался под любителя кино и домашнего просмотра. Он присоединился к разговорам фанатов DVD и кинолюбителей, подружился с основными комментаторами и периодически рассказывал популярным членам сообществ, модераторам и владельцам сайтов о «новом великом сайте» — Netflix.


✅ Instagram нашел фотографов для создания хорошего впечатления

Основатели тщательно подбирали первых пользователей фотосервиса и разыскивали хороших фотографов и дизайнеров в Twitter. Они должны были создать правильный художественный тон, создавая качественный контент в Instagram, – и привлечь таким образом более простых пользователей. Это первая рекламная кампания Instagram, которая выразила концепцию соцсети ещё до того, как она была сформулирована официально.


✅ Product Hunt делал рассылку по журналистам и писал гостевые публикации в СМИ

Основатель сервиса Райан Гувер рассказывал о Product Hunt в гостевых публикациях на сайтах технологических изданий, аудитория которых интересуется стартапами и была готова пользоваться Product Hunt.