ПОЧЕМУ РАЗРАБОТЧИК ДОЛЖЕН ВЛАДЕТЬ ПРОДУКТОМ И КАК ЭТО СДЕЛАЕТ ЕГО СЧАСТЛИВЫМ
👨🏼💻➡️📱
В английском языке есть отличное слово ownership, которое в контексте рассматриваемой темы означает что-то вроде «хозяйское отношение» и «ощущение причастности».
Каждый разработчик должен помнить, что он часть:
✨ бизнеса компании,
✨ продукта компании.
Соответственно, задача разработчика — развивать бизнес компании и улучшать продукт. Такая установка означает, что разработчик должен:
⚡️ знать продукт и его предметную область;
⚡️ знать пользователей своего продукта;
⚡️ понимать, как работает этот бизнес;
⚡️ разбираться в метриках продукта;
⚡️ знать, в какую сторону растёт продукт и бизнес;
⚡️ понимать, что делают другие отделы компании.
Всё вместе это называется «продуктовым» или «бизнесовым» мышлением. Добавляем личную заинтересованность и проактивность, а главное, ответственность за успехи и провалы — и получаем «владение» продуктом.
Такой подход будет требовать значительных личных усилий. Зачем это компании и зачем это вам?
Преимущества для компании
📌 Доведение дел до конца
📌 Правильные архитектурные решения
📌 Помощь product owner в нахождении оптимальной реализации фичи
📌 Большая эффективность и креативность
📌 Проактивность
Преимущества для вас
📌 Вы будете более ценным для бизнеса
📌 Вы будете работать в лучших местах
📌 Вы будете счастливее)
🍀 Source >>>
#development #efficiency #product #psychology #strategy
👨🏼💻➡️📱
В английском языке есть отличное слово ownership, которое в контексте рассматриваемой темы означает что-то вроде «хозяйское отношение» и «ощущение причастности».
Каждый разработчик должен помнить, что он часть:
✨ бизнеса компании,
✨ продукта компании.
Соответственно, задача разработчика — развивать бизнес компании и улучшать продукт. Такая установка означает, что разработчик должен:
⚡️ знать продукт и его предметную область;
⚡️ знать пользователей своего продукта;
⚡️ понимать, как работает этот бизнес;
⚡️ разбираться в метриках продукта;
⚡️ знать, в какую сторону растёт продукт и бизнес;
⚡️ понимать, что делают другие отделы компании.
Всё вместе это называется «продуктовым» или «бизнесовым» мышлением. Добавляем личную заинтересованность и проактивность, а главное, ответственность за успехи и провалы — и получаем «владение» продуктом.
Такой подход будет требовать значительных личных усилий. Зачем это компании и зачем это вам?
Преимущества для компании
📌 Доведение дел до конца
📌 Правильные архитектурные решения
📌 Помощь product owner в нахождении оптимальной реализации фичи
📌 Большая эффективность и креативность
📌 Проактивность
Преимущества для вас
📌 Вы будете более ценным для бизнеса
📌 Вы будете работать в лучших местах
📌 Вы будете счастливее)
🍀 Source >>>
#development #efficiency #product #psychology #strategy
HOW TO ADD PRODUCT FEATURES WITHOUT MAKING IT MORE COMPLEX
🚀
It’s easy add features to a design or product. It’s really really hard to do that without also making the product more complex.
Adding functionality whilst reducing complexity is very very difficult, and often requires some very drastic changes beneath the surface.
Your job as a product or designer requires you to constantly be fighting a war between adding in features whilst simultaneously improving user experience (sounds like an oxymoron). But whilst we can’t all be Steve Jobs, we can definitely implement some basic design principles that will help us in our struggles between better vs simpler.
There’s one key principle that can have some very powerful effects on how you approach your design & product work, especially when you can’t easily simplify — that is the concept of: Default Valid vs Default Invalid.
By default, when you call a taxi company, and ask for a taxi to take you downtown, your request is invalid. It’s invalid because they don’t know where you are. Compare that to the Uber app. When you open the Uber app and put in ‘downtown’ as your destination, your request is default valid. Because the app knows where you are. It’s not forcing you to enter that in before you can proceed with your request. Even if your GPS is tripping balls and thinks you’re a block over from where you actually are, and you have to move the pin back to where you actually are, it still feels like less work than entering in your current location.
When your product or interface is default invalid, subconsciously what you’re saying to your user is “you need to do X amount of work before you can even start using this service”. Compare that to when you take the default valid approach, you’re saying to your user “you don’t need to do anything, you can get started right away! But feel free to customise it to better suit your needs once you’re in.”
⚠️ Those are two very, very different messages.
Thinking about ‘default valid’ in your own projects
❓ What other products can you think of that implement this kind of design logic? How do you think it impacts its users?
❓ Are there opportunities for you to implement this in your own projects?
❓ Is absolute accuracy and up-front user information more important for you or is higher conversion rates / product adoption?
❓ If you’re lacking user-supplied information, what ways can you infer that through other means (device metrics, estimates from existing data, machine learning predictive algorithms)?
❓ What’s the quickest and simplest way to A/B test this against the current version?
🍀 Source >>>
#case #design #efficiency #product #psychology #strategy #ux
🚀
It’s easy add features to a design or product. It’s really really hard to do that without also making the product more complex.
Adding functionality whilst reducing complexity is very very difficult, and often requires some very drastic changes beneath the surface.
Your job as a product or designer requires you to constantly be fighting a war between adding in features whilst simultaneously improving user experience (sounds like an oxymoron). But whilst we can’t all be Steve Jobs, we can definitely implement some basic design principles that will help us in our struggles between better vs simpler.
There’s one key principle that can have some very powerful effects on how you approach your design & product work, especially when you can’t easily simplify — that is the concept of: Default Valid vs Default Invalid.
By default, when you call a taxi company, and ask for a taxi to take you downtown, your request is invalid. It’s invalid because they don’t know where you are. Compare that to the Uber app. When you open the Uber app and put in ‘downtown’ as your destination, your request is default valid. Because the app knows where you are. It’s not forcing you to enter that in before you can proceed with your request. Even if your GPS is tripping balls and thinks you’re a block over from where you actually are, and you have to move the pin back to where you actually are, it still feels like less work than entering in your current location.
When your product or interface is default invalid, subconsciously what you’re saying to your user is “you need to do X amount of work before you can even start using this service”. Compare that to when you take the default valid approach, you’re saying to your user “you don’t need to do anything, you can get started right away! But feel free to customise it to better suit your needs once you’re in.”
⚠️ Those are two very, very different messages.
Thinking about ‘default valid’ in your own projects
❓ What other products can you think of that implement this kind of design logic? How do you think it impacts its users?
❓ Are there opportunities for you to implement this in your own projects?
❓ Is absolute accuracy and up-front user information more important for you or is higher conversion rates / product adoption?
❓ If you’re lacking user-supplied information, what ways can you infer that through other means (device metrics, estimates from existing data, machine learning predictive algorithms)?
❓ What’s the quickest and simplest way to A/B test this against the current version?
🍀 Source >>>
#case #design #efficiency #product #psychology #strategy #ux
КАК ПОДХОДИТЬ К ЗАДАЧЕ ПОИСКА СЕГМЕНТА
🔭🔮🔬
Работы существуют исключительно во внутренней реальности человека и снаружи их очень тяжело увидеть. Люди разные, люди бывают в огромном количестве контекстов, у разных людей разный прошлый опыт.
Нам нужен достаточно точный инструмент изучения внутреннего мира человека: все контексты, триггеры, особенности психики, прошлый опыт и эмоции, люди обычно проактивно не рассказывают.
НО!
У нас есть очень сильный сигнал, через который мы можем зацепить и достать работы: это затраты человеком энергии и денег. Мозг человека постоянно стремится экономить энергию и если есть возможность не тратить энергию—мозг не будет это делать. Вы можете быть практически уверены, что у человека есть работа, если он потратил:
✨ энергию физически куда-то съездить, что-то сделать руками, делать что-то в течение какого-то времени
✨ деньги = энергия, которая была потрачена чтобы заработать эту сумму денег
✨ когнитивную/эмоциональную энергию = долго про что-то думал, переживал, тревожился, боялся, сомневался, выбирал, размышлял..
Поэтому самый лучший способ убедиться что есть сегмент людей с конкретной работой = найти людей, которые УЖЕ выполняют эту работу с каким-то решением, и, в идеале, платят много денег за выполнение этой работы, так знание о том, что люди УЖЕ платят деньги и инвестируют энергию, вы сможете найти работы.
Всем, кто ищет сегмент для нового продукта я без конца повторяю как мантру: "На этапе поиска сегмента мы забываем про свой продукт". Людям не нужны продукты, люди не думают в категориях продуктов. Людям важно получать конкретный результат чтобы чувствовать себя по-другому.
Если вы будете держать в голове свой чудесный продукт, то вы с высокой вероятностью совершите одну из двух ошибок:
⚡️ Вы бессознательно будете стремиться подтвердить гипотезу вашего потрясающего и волшебного продукта
⚡️ Вы будете игнорировать работы, для которых ваш продукт не подходит
Сегмент = люди объединённые работой! На этапе поиска сегмента ваш продукт является отправной точкой чтобы придумать гипотезу работы, а дальше вы забываете его и работаете только на уровне работ. До тех пор, пока не убедитесь, что вы составили достаточно полную картину сегментов, у вас готова логика выбора сегментов про это раздел "Продуктовая стратегия" И только тогда вы сможете начать перебирать для каких работ какое решение вы можете сделать, чтобы перетащить клиентов с текущих решений.
В итоге, гипотеза продукта, которая у вас родится в конце исследования для поиска сегмента, обычно ооочень сильно отличается от исходной гипотезы.
И в этом, вся красота и суть исследования для поиска сегмента.
🍀 Original >>>
🍀 Source >>>
#development #efficiency #methodology #mr #product #strategy #tools
🔭🔮🔬
Работы существуют исключительно во внутренней реальности человека и снаружи их очень тяжело увидеть. Люди разные, люди бывают в огромном количестве контекстов, у разных людей разный прошлый опыт.
Нам нужен достаточно точный инструмент изучения внутреннего мира человека: все контексты, триггеры, особенности психики, прошлый опыт и эмоции, люди обычно проактивно не рассказывают.
НО!
У нас есть очень сильный сигнал, через который мы можем зацепить и достать работы: это затраты человеком энергии и денег. Мозг человека постоянно стремится экономить энергию и если есть возможность не тратить энергию—мозг не будет это делать. Вы можете быть практически уверены, что у человека есть работа, если он потратил:
✨ энергию физически куда-то съездить, что-то сделать руками, делать что-то в течение какого-то времени
✨ деньги = энергия, которая была потрачена чтобы заработать эту сумму денег
✨ когнитивную/эмоциональную энергию = долго про что-то думал, переживал, тревожился, боялся, сомневался, выбирал, размышлял..
Поэтому самый лучший способ убедиться что есть сегмент людей с конкретной работой = найти людей, которые УЖЕ выполняют эту работу с каким-то решением, и, в идеале, платят много денег за выполнение этой работы, так знание о том, что люди УЖЕ платят деньги и инвестируют энергию, вы сможете найти работы.
Всем, кто ищет сегмент для нового продукта я без конца повторяю как мантру: "На этапе поиска сегмента мы забываем про свой продукт". Людям не нужны продукты, люди не думают в категориях продуктов. Людям важно получать конкретный результат чтобы чувствовать себя по-другому.
Если вы будете держать в голове свой чудесный продукт, то вы с высокой вероятностью совершите одну из двух ошибок:
⚡️ Вы бессознательно будете стремиться подтвердить гипотезу вашего потрясающего и волшебного продукта
⚡️ Вы будете игнорировать работы, для которых ваш продукт не подходит
Сегмент = люди объединённые работой! На этапе поиска сегмента ваш продукт является отправной точкой чтобы придумать гипотезу работы, а дальше вы забываете его и работаете только на уровне работ. До тех пор, пока не убедитесь, что вы составили достаточно полную картину сегментов, у вас готова логика выбора сегментов про это раздел "Продуктовая стратегия" И только тогда вы сможете начать перебирать для каких работ какое решение вы можете сделать, чтобы перетащить клиентов с текущих решений.
В итоге, гипотеза продукта, которая у вас родится в конце исследования для поиска сегмента, обычно ооочень сильно отличается от исходной гипотезы.
И в этом, вся красота и суть исследования для поиска сегмента.
🍀 Original >>>
🍀 Source >>>
#development #efficiency #methodology #mr #product #strategy #tools
КАК ПРАВИЛЬНО ПОСТАВИТЬ ЗАДАЧУ ДЛЯ РАЗРАБОТКИ
💎
«Эти разработчики опять ничего не поняли!» — возмущается заказчик мобильного приложения. Но мы все знаем, что у разработчиков тонкая душевная организация и куча злых мемов на случай недопонимания с заказчиком. Чтобы не попасть в череду уточнений, согласований и — самое плохое — исправлений ошибок, нужно просто грамотно написать задачу для специалистов.
В данной статье описывается опыт с упором на специфику работы компании (автора статьи) именно в их сфере – разработки мобильных приложений на заказ, но при этом у них есть несколько собственных продуктов в виде приложений. Если вы не увидите тут идеальных лично для вас процессов, то не переживайте, это вполне нормально, но в любом случае авторы считают, что описанное в той или иной мере может быть применимо в разных областях создания программного обеспечения.
Шаги описания задачи
⚡️ Получите все необходимые требования. Убедитесь, что сами понимаете, что требуется реализовать.
⚡️ Подберите правильное название задачи.
⚡️ В самом начале описания задачи поясните разработчику ценность изменения.
⚡️ Добавьте путь до изменяемого экрана, если это не очевидно.
⚡️ Добавьте ссылки на макеты, если фича визуальная. Если есть разные состояния в зависимости от условий, описываемых в задаче, то добавьте ссылки в контексте конкретного кейса.
⚡️ Добавьте дополнительные ссылки на артефакты, которые требуются для выполнения задачи.
⚡️ Если предполагается переиспользование для реализации, явно укажите это.
⚡️ Укажите, если в будущем будет переиспользоваться, масштабироваться или меняться результат задачи.
⚡️ Если необходимо сохранение данных для будущего использования, укажите.
⚡️ Опишите функционально задачу и убедитесь в отсутствии пробелов в логике.
⚡️ Опишите всю необходимую информацию по сетевым запросам (запрос, ответ, что парсим, опциональность; не описывать неиспользуемые поля и указать, что их не парсим).
⚡️ Укажите, если данные получаются при каком-то условии — например, касаются только авторизованных пользователей, специальных заказов или аккаунтов и т.д.
⚡️ Укажите прошлые локальные данные, если они используются.
⚡️ Пропишите логику загрузки данных: есть ли постраничная подгрузка, активити и т.д.
⚡️ Укажите логику для пустых данных.
⚡️ Опишите разные форматы отображения для разных региональных параметров, форматов дат и т.д.
⚡️ Пропишите логику для обработки специальных ошибок.
⚡️ Если требуются какие-то ключи, то добавьте их для каждого типа сборки – QA/RC/Release.
⚡️ Убедитесь, что разработчики имеют доступ ко всем необходимым артефактам или сервисам.
⚡️ Добавьте аналитику по данной функции (возможно в другой задаче – подумайте и не забудьте).
⚡️ Дополните базовый чек-лист.
⚡️ Свяжите с задачей для другой платформы и другими задачами, если есть такая зависимость.
🏁 Перечитайте всю задачу от начала до конца!
Важно приучить себя мысленно продумывать все эти шаги, чтобы потом на автомате учитывать все потребности и возможности для облегчения разработки. Хорошо описанная задача экономит время всем: будет меньше вопросов, ускорится тестирование и т.д.
🍀 Source >>>
#case #development #efficiency #product #tools
💎
«Эти разработчики опять ничего не поняли!» — возмущается заказчик мобильного приложения. Но мы все знаем, что у разработчиков тонкая душевная организация и куча злых мемов на случай недопонимания с заказчиком. Чтобы не попасть в череду уточнений, согласований и — самое плохое — исправлений ошибок, нужно просто грамотно написать задачу для специалистов.
В данной статье описывается опыт с упором на специфику работы компании (автора статьи) именно в их сфере – разработки мобильных приложений на заказ, но при этом у них есть несколько собственных продуктов в виде приложений. Если вы не увидите тут идеальных лично для вас процессов, то не переживайте, это вполне нормально, но в любом случае авторы считают, что описанное в той или иной мере может быть применимо в разных областях создания программного обеспечения.
Шаги описания задачи
⚡️ Получите все необходимые требования. Убедитесь, что сами понимаете, что требуется реализовать.
⚡️ Подберите правильное название задачи.
⚡️ В самом начале описания задачи поясните разработчику ценность изменения.
⚡️ Добавьте путь до изменяемого экрана, если это не очевидно.
⚡️ Добавьте ссылки на макеты, если фича визуальная. Если есть разные состояния в зависимости от условий, описываемых в задаче, то добавьте ссылки в контексте конкретного кейса.
⚡️ Добавьте дополнительные ссылки на артефакты, которые требуются для выполнения задачи.
⚡️ Если предполагается переиспользование для реализации, явно укажите это.
⚡️ Укажите, если в будущем будет переиспользоваться, масштабироваться или меняться результат задачи.
⚡️ Если необходимо сохранение данных для будущего использования, укажите.
⚡️ Опишите функционально задачу и убедитесь в отсутствии пробелов в логике.
⚡️ Опишите всю необходимую информацию по сетевым запросам (запрос, ответ, что парсим, опциональность; не описывать неиспользуемые поля и указать, что их не парсим).
⚡️ Укажите, если данные получаются при каком-то условии — например, касаются только авторизованных пользователей, специальных заказов или аккаунтов и т.д.
⚡️ Укажите прошлые локальные данные, если они используются.
⚡️ Пропишите логику загрузки данных: есть ли постраничная подгрузка, активити и т.д.
⚡️ Укажите логику для пустых данных.
⚡️ Опишите разные форматы отображения для разных региональных параметров, форматов дат и т.д.
⚡️ Пропишите логику для обработки специальных ошибок.
⚡️ Если требуются какие-то ключи, то добавьте их для каждого типа сборки – QA/RC/Release.
⚡️ Убедитесь, что разработчики имеют доступ ко всем необходимым артефактам или сервисам.
⚡️ Добавьте аналитику по данной функции (возможно в другой задаче – подумайте и не забудьте).
⚡️ Дополните базовый чек-лист.
⚡️ Свяжите с задачей для другой платформы и другими задачами, если есть такая зависимость.
🏁 Перечитайте всю задачу от начала до конца!
Важно приучить себя мысленно продумывать все эти шаги, чтобы потом на автомате учитывать все потребности и возможности для облегчения разработки. Хорошо описанная задача экономит время всем: будет меньше вопросов, ускорится тестирование и т.д.
🍀 Source >>>
#case #development #efficiency #product #tools
EVERYTHING YOU NEED TO KNOW ABOUT SKELETON SCREENS
☠️📲
Skeleton screens in different shapes and sizes are seemingly found everywhere across the web and apps — anywhere humans are forced to wait.
Research summary (TL;DR)
⚡️ Skeleton screens (as splash screens), when used to indicate that a screen is loading, are perceived as being shorter in duration when compared against a blank screen (our control) and a spinner — but not by much
⚡️ Skeleton screens should not block gradual content loads (real content should replace skeleton objects immediately when the data is available). The vast majority of skeleton screens in use today are splash screens, and not skeleton screens in the original way described by Luke Wroblewski
⚡️ When designing skeleton screens, it’s recommended using motion to further decrease perceived duration time
⚡️ Skeleton screens that leverage motion that moves from left to right (e.g. a wave or shimmer like animation, much like Facebook or Google uses) are perceived as shorter in duration than skeletons that pulse (opacity fading in and out)
⚡️ Skeleton screens using motion that is slow and steady are perceived as shorter in duration than skeleton screens that use fast or rapid motion
⚡️ The sample sizes in this study are too small to conclude anything definitively, but they do provide useful hints as to how we could design waiting experiences
As Peter Conrad best put it, “Modernity is about the acceleration of time”. From pure personal observation, the truth of this seems self-evident. Our culture’s patience thins daily, our walking pace has seemingly quickened to near jogging speeds, and our waning tolerance for all things even mildly idle in nature has given way to an entire industry of productivity pundits.
In this human rebuke of slowness will undoubtedly arise new anxieties and irrational impulses. And perhaps new ways to stanch our fear that time is slipping from our grasp — as we sit and quietly contemplate skeleton screens.
🍀 Source >>>
#analytics #case #design #efficiency #experiment #product #psychology
☠️📲
Skeleton screens in different shapes and sizes are seemingly found everywhere across the web and apps — anywhere humans are forced to wait.
Research summary (TL;DR)
⚡️ Skeleton screens (as splash screens), when used to indicate that a screen is loading, are perceived as being shorter in duration when compared against a blank screen (our control) and a spinner — but not by much
⚡️ Skeleton screens should not block gradual content loads (real content should replace skeleton objects immediately when the data is available). The vast majority of skeleton screens in use today are splash screens, and not skeleton screens in the original way described by Luke Wroblewski
⚡️ When designing skeleton screens, it’s recommended using motion to further decrease perceived duration time
⚡️ Skeleton screens that leverage motion that moves from left to right (e.g. a wave or shimmer like animation, much like Facebook or Google uses) are perceived as shorter in duration than skeletons that pulse (opacity fading in and out)
⚡️ Skeleton screens using motion that is slow and steady are perceived as shorter in duration than skeleton screens that use fast or rapid motion
⚡️ The sample sizes in this study are too small to conclude anything definitively, but they do provide useful hints as to how we could design waiting experiences
As Peter Conrad best put it, “Modernity is about the acceleration of time”. From pure personal observation, the truth of this seems self-evident. Our culture’s patience thins daily, our walking pace has seemingly quickened to near jogging speeds, and our waning tolerance for all things even mildly idle in nature has given way to an entire industry of productivity pundits.
In this human rebuke of slowness will undoubtedly arise new anxieties and irrational impulses. And perhaps new ways to stanch our fear that time is slipping from our grasp — as we sit and quietly contemplate skeleton screens.
🍀 Source >>>
#analytics #case #design #efficiency #experiment #product #psychology
СТАРТАП ДНЯ ОТ САШИ ГОРНОГО > УМНЫЕ PUSH В ПРИЛОЖЕНИЯХ ОТ NGROW
🤖📲
Если человек установил ваше приложение – это только полдела. Пока оно просто висит на девятом экране смартфона, вы ещё не зарабатываете. Важно, чтобы пользователь его запустил. И чуть ли не единственный простой способ увеличить количество запусков – пуш-уведомления. Пришлем ему “вы давно не занимались”, или “дарим промокод”, или “появился новый контент” – авось на что-то он и клюнет.
Компании типа OneSignal давно сделали для этого удобные SDK. Программист один раз вставляет их в приложение, а дальше маркетолог в админке настраивает кому, когда и что отправить. Американский “с русскими корнями” #стартапдня nGrow обещает быть ещё лучше.
Техническая новизна – отсутствие SDK. Программист приложения не нужен вообще. Информация о событиях берется из интеграции с Amplitude или другой аналитикой, отправка идет через Firebase или тот же OneSignal, если он уже подключен. Добавление nGrow в проект занимает не больше рабочего дня и не требует раскладки в стор.
Содержательная новизна – искусственный интеллект. Умные Алгоритмы следят за метриками в подключенной аналитике и отправляют Push в правильное время и в правильной последовательности, чтобы добиться роста нужных показателей. Основатели стартапа утверждают, что это дает прирост в десятки процентов по сравнению с жестким расписанием, которое задает живой человек в обычных системах.
Зимой nGrow прошел Y Combinator, за свою историю компания привлекла около 2 миллионов долларов инвестиций.
🍀 Source >>>
🗂 Use cases >>>
#advertising #case #efficiency #marketing #mobile #product #technology #tools #ux
🤖📲
Если человек установил ваше приложение – это только полдела. Пока оно просто висит на девятом экране смартфона, вы ещё не зарабатываете. Важно, чтобы пользователь его запустил. И чуть ли не единственный простой способ увеличить количество запусков – пуш-уведомления. Пришлем ему “вы давно не занимались”, или “дарим промокод”, или “появился новый контент” – авось на что-то он и клюнет.
Компании типа OneSignal давно сделали для этого удобные SDK. Программист один раз вставляет их в приложение, а дальше маркетолог в админке настраивает кому, когда и что отправить. Американский “с русскими корнями” #стартапдня nGrow обещает быть ещё лучше.
Техническая новизна – отсутствие SDK. Программист приложения не нужен вообще. Информация о событиях берется из интеграции с Amplitude или другой аналитикой, отправка идет через Firebase или тот же OneSignal, если он уже подключен. Добавление nGrow в проект занимает не больше рабочего дня и не требует раскладки в стор.
Содержательная новизна – искусственный интеллект. Умные Алгоритмы следят за метриками в подключенной аналитике и отправляют Push в правильное время и в правильной последовательности, чтобы добиться роста нужных показателей. Основатели стартапа утверждают, что это дает прирост в десятки процентов по сравнению с жестким расписанием, которое задает живой человек в обычных системах.
Зимой nGrow прошел Y Combinator, за свою историю компания привлекла около 2 миллионов долларов инвестиций.
🍀 Source >>>
🗂 Use cases >>>
#advertising #case #efficiency #marketing #mobile #product #technology #tools #ux
ANALYTICS AND PRODUCT-MARKET FIT. DOES THIS PRODUCT HAVE PRODUCT-MARKET FIT?
🔎🗺
✨ This playbook clearly defines product-market fit (PMF) — the value that a given product provides in addressing a specific market segment’s need — and outlines why this must be addressed early in product development.
✨ There are three vital signs that measure PMF: stable retention, sustainable growth and deep engagement.
✨ We also address common misconceptions many people may have about PMF, clarifying that it’s not about everyone in your market, it can change over time and that it’s not a binary metric.
When developing new products, the big question we seek to answer is, “Does this product have product-market fit?” We are constantly experimenting with new and exciting products and features as we aim to better address people’s diverse needs and provide them with more value.
However, as we introduce new products and features, we must also hold ourselves accountable to a high bar of product quality. To use a Silicon Valley motto, are we building something people want?
Analytics plays a central role in addressing this question. Doing so fits squarely within our core principle of bringing an independent voice and analytical perspective into decision-making.
But how can our analytics teams answer such a broad and ambiguous question?
We do so by analyzing data on people’s use of the product. Ultimately, people vote with their feet. If they are interested in your product, they will use it. If they like your product, they will come back to it. By analyzing this data, we can better understand the value of our products.
Through a collaborative effort between data scientists, data engineers, product growth analysts, product managers, and other key stakeholders, we developed this playbook that guides analytics teams through quantitatively evaluating product-market fit.
Our aim is to simplify and demystify this often confusing topic.
While our focus is quantitative, your product doesn’t need thousands or millions of users in order to make use of data and quantitatively evaluate product-market fit. As Alex Schultz has noted, you can use data even with tens or hundreds of users.
And of course, qualitative insights, such as from interviews and surveys, also play a critical role in understanding our products and evaluating their “product-market fit”. We focus here on the analytics playbook.
📌 Putting this all together, we arrive at a comprehensive picture of a product’s value to the market. Highly valuable products — those with a high degree of product-market fit — keep people coming back (retention), sustainably acquire new people (growth) and are used regularly or for long stretches (engagement).
Products that fall short on one of more of these measures should be improved before further scaling. Our playbook provides actionable recommendations for products that map to each end-state. For example, products that are highly retentive but not growing sustainably should focus on acquisition — specifically the “new” and “resurrected” components of the net growth formula.
Overall, product-market fit is a central concept that enforces a high bar of product quality.
We hope that others find this useful for building better products that people love.
🍀 Source >>>
#analytics #efficiency #likbez #methodology #product #strategy #tools
🔎🗺
✨ This playbook clearly defines product-market fit (PMF) — the value that a given product provides in addressing a specific market segment’s need — and outlines why this must be addressed early in product development.
✨ There are three vital signs that measure PMF: stable retention, sustainable growth and deep engagement.
✨ We also address common misconceptions many people may have about PMF, clarifying that it’s not about everyone in your market, it can change over time and that it’s not a binary metric.
When developing new products, the big question we seek to answer is, “Does this product have product-market fit?” We are constantly experimenting with new and exciting products and features as we aim to better address people’s diverse needs and provide them with more value.
However, as we introduce new products and features, we must also hold ourselves accountable to a high bar of product quality. To use a Silicon Valley motto, are we building something people want?
Analytics plays a central role in addressing this question. Doing so fits squarely within our core principle of bringing an independent voice and analytical perspective into decision-making.
But how can our analytics teams answer such a broad and ambiguous question?
We do so by analyzing data on people’s use of the product. Ultimately, people vote with their feet. If they are interested in your product, they will use it. If they like your product, they will come back to it. By analyzing this data, we can better understand the value of our products.
Through a collaborative effort between data scientists, data engineers, product growth analysts, product managers, and other key stakeholders, we developed this playbook that guides analytics teams through quantitatively evaluating product-market fit.
Our aim is to simplify and demystify this often confusing topic.
While our focus is quantitative, your product doesn’t need thousands or millions of users in order to make use of data and quantitatively evaluate product-market fit. As Alex Schultz has noted, you can use data even with tens or hundreds of users.
And of course, qualitative insights, such as from interviews and surveys, also play a critical role in understanding our products and evaluating their “product-market fit”. We focus here on the analytics playbook.
📌 Putting this all together, we arrive at a comprehensive picture of a product’s value to the market. Highly valuable products — those with a high degree of product-market fit — keep people coming back (retention), sustainably acquire new people (growth) and are used regularly or for long stretches (engagement).
Products that fall short on one of more of these measures should be improved before further scaling. Our playbook provides actionable recommendations for products that map to each end-state. For example, products that are highly retentive but not growing sustainably should focus on acquisition — specifically the “new” and “resurrected” components of the net growth formula.
Overall, product-market fit is a central concept that enforces a high bar of product quality.
We hope that others find this useful for building better products that people love.
🍀 Source >>>
#analytics #efficiency #likbez #methodology #product #strategy #tools
DESIGNOPS, СТРЕМИТЕЛЬНО ВОРВАВШИЙСЯ В ТРЕНД by Юра Ветров
👩🏻💻🎨
Баззворд «DesignOps» грозится вытеснить «UX-стратегию» и другие термины для описания дизайн-менеджмента. Он периодически всплывал в последние годы, но с подачи методички «DesignOps Handbook» от InVision ворвался на вершину хайпа. При этом нового смысла не создаётся — скорее переупаковали то, о чём последние лет пять рассказывали под маркой UX-стратегии, дизайн-менеджмента и дизайн-лидерства.
Ops, I did it again! Дизайнеры, как цыгане, постоянно кочуют от тренда к тренду и любят новые блестящие штуки ― термин и концепцию DevOps уже натягивают на дизайн-системы (Design Systems Ops) и пользовательские исследования (ResearchOps). Jared Spool говорит, что «что-нибудь»-ops — это новое «что-нибудь»-мышление.
Поскольку термин только-только начинает входить в обиход, многие понимают под ним разные вещи — кто-то только команду дизайн-системы, кто-то — вообще все методы работы. Но у других терминов тоже есть проблемы — UX-стратегию понимают и как планирование редизайна продукта, так и комплексные изменения в организации, которая выпускает продукты. А дизайн-менеджмент и дизайн-лидерство слишком общие.
Чёрт, это попахивает терминологическим спором, самой бесполезной тратой времени после создания погодного чат-бота. Но так уж устроен рынок ИТ — всегда будут появляться новые горячие слова для подбадривания продаж услуг консультантов. Да и не все обновления терминов плохи. В конце прошлого года тренд отметил TechRadar, что достаточно серьёзное подтверждение потенциально широкого интереса.
Хотя DesignOps просто переупаковывает уже известные подходы, термин поставил очень грамотный фокус — развивать дизайн-процессы, инструменты, методы и практики под масштабирование. Т.е. инициативная группа улучшает инфраструктуру компании для реализации хорошего дизайна, чтобы ими мог легко воспользоваться любой дизайнер в компании. Это то, что отличает его от остальных. Централизованные дизайн-команды и так живут по этому принципу; в более современной модели а-ля Spotify речь об отдельной команде, которая работает с остальными по внедрению лучших практик.
🍀 DesignOps Handbook in PDF >>>
🍀 Source (RUS) >>>
🍀 Original (ENG) >>>
#design #efficiency #methodology #product #tools #ux
👩🏻💻🎨
Баззворд «DesignOps» грозится вытеснить «UX-стратегию» и другие термины для описания дизайн-менеджмента. Он периодически всплывал в последние годы, но с подачи методички «DesignOps Handbook» от InVision ворвался на вершину хайпа. При этом нового смысла не создаётся — скорее переупаковали то, о чём последние лет пять рассказывали под маркой UX-стратегии, дизайн-менеджмента и дизайн-лидерства.
Ops, I did it again! Дизайнеры, как цыгане, постоянно кочуют от тренда к тренду и любят новые блестящие штуки ― термин и концепцию DevOps уже натягивают на дизайн-системы (Design Systems Ops) и пользовательские исследования (ResearchOps). Jared Spool говорит, что «что-нибудь»-ops — это новое «что-нибудь»-мышление.
Поскольку термин только-только начинает входить в обиход, многие понимают под ним разные вещи — кто-то только команду дизайн-системы, кто-то — вообще все методы работы. Но у других терминов тоже есть проблемы — UX-стратегию понимают и как планирование редизайна продукта, так и комплексные изменения в организации, которая выпускает продукты. А дизайн-менеджмент и дизайн-лидерство слишком общие.
Чёрт, это попахивает терминологическим спором, самой бесполезной тратой времени после создания погодного чат-бота. Но так уж устроен рынок ИТ — всегда будут появляться новые горячие слова для подбадривания продаж услуг консультантов. Да и не все обновления терминов плохи. В конце прошлого года тренд отметил TechRadar, что достаточно серьёзное подтверждение потенциально широкого интереса.
Хотя DesignOps просто переупаковывает уже известные подходы, термин поставил очень грамотный фокус — развивать дизайн-процессы, инструменты, методы и практики под масштабирование. Т.е. инициативная группа улучшает инфраструктуру компании для реализации хорошего дизайна, чтобы ими мог легко воспользоваться любой дизайнер в компании. Это то, что отличает его от остальных. Централизованные дизайн-команды и так живут по этому принципу; в более современной модели а-ля Spotify речь об отдельной команде, которая работает с остальными по внедрению лучших практик.
🍀 DesignOps Handbook in PDF >>>
🍀 Source (RUS) >>>
🍀 Original (ENG) >>>
#design #efficiency #methodology #product #tools #ux
NO-CODE ДЛЯ ВСЕХ: КАК ИСПОЛЬЗОВАТЬ ДАННЫЕ И ИИ БЕЗ АРМИИ РАЗРАБОТЧИКОВ by Джонатон Рейли
🤖🚫👨🏼💻
Технологии часто развиваются по одной и той же схеме. Сначала ее использует небольшая группа ученых, затем к ним присоединяются инженеры, способные разобраться в технических сложностях и терминах, и наконец она становится настолько удобной для пользователя, что ей может пользоваться кто угодно.
Сейчас к этому последнему этапу подходит технология разработки ПО. Когда-то сложные текстовые команды DOS сменились удобными окнами Windows и Mac OS, а теперь на смену языкам программирования приходят новые no-code-платформы с простым интерфейсом. Их влияние может оказаться огромным. Раньше, чтобы создать приложение, нужно было нанимать команду разработчиков, а теперь любой человек с браузером может сам воплотить свою идею в жизнь. Иными словами, мощные технологии, которые раньше были доступны только крупным и обеспеченным компаниям, теперь могут себе позволить и фирмы меньшего размера.
Но еще важнее, что no-code-платформы позволяют внедрить искусственный интеллект, одну из самых революционных технологий этого поколения, не нанимая армию разработчиков и специалистов по данным с огромными зарплатами. Небольшие компании, у которых тоже может быть огромное количество данных, смогут использовать все преимущества ИИ — например, разработать новый клиентский опыт (как автономный автомобиль Tesla), увеличить выручку (как P&G, начавшая рассчитывать рекламные расходы на основе ИИ) или максимизировать эффективность (как цепь поставок Walmart).
Но малому бизнесу сложно даже понять, как и где можно внедрить эту новую технологию. Крупные компании уже разобрались, зачем им нужны данные. Однако они начинали с небольших задач, а не с гигантских мегапроектов — и малому бизнесу стоит поступать так же. Вот что следует учитывать.
1️⃣ Работайте с уже имеющимися данными. Из них часто можно извлечь больше пользы, чем кажется.
2️⃣ Выбирайте важные задачи, оптимизация которых приведет к росту.
3️⃣ Начните с того, что уже получилось у многих других — например, оптимизируйте воронку продаж или снизьте отток клиентов, чтобы ваша команда научилась применять ИИ к широкому набору случаев.
4️⃣ Если какой-то ИИ-проект не дает вам 10-кратной окупаемости, не стесняйтесь от него отказаться: хороших приложений хватает.
No-code-разработка помогает сотрудникам изобретать креативные способы использовать данные, чтобы улучшить или оптимизировать свою работу, а, следовательно, и бизнес компании в целом.
ИИ может принести пользу во всех подразделениях компании, а преимущество no-code-платформ заключается в том, что они не ограничены никакими узкими задачами. С их помощью можно, например, рассчитать требуемую частоту обслуживания станков и понять, какие из них близки к поломке, обнаружить первые признаки недовольства клиентов и снизить отток или решить проблему текучки сотрудников. ИИ может искать паттерны не только в цифрах, но и в тексте: анализировать записи или расшифровки разговоров в сочетании с данными об истории продаж и рекламы, чтобы компаниям было легче автоматизировать сложные процессы.
Для многих организаций работа с no-code-платформой сводится к поиску нужной задачи — и нужной платформы.
🍀 Source >>>
#dev #efficiency #likbez #strategy #technology #tools
🤖🚫👨🏼💻
Технологии часто развиваются по одной и той же схеме. Сначала ее использует небольшая группа ученых, затем к ним присоединяются инженеры, способные разобраться в технических сложностях и терминах, и наконец она становится настолько удобной для пользователя, что ей может пользоваться кто угодно.
Сейчас к этому последнему этапу подходит технология разработки ПО. Когда-то сложные текстовые команды DOS сменились удобными окнами Windows и Mac OS, а теперь на смену языкам программирования приходят новые no-code-платформы с простым интерфейсом. Их влияние может оказаться огромным. Раньше, чтобы создать приложение, нужно было нанимать команду разработчиков, а теперь любой человек с браузером может сам воплотить свою идею в жизнь. Иными словами, мощные технологии, которые раньше были доступны только крупным и обеспеченным компаниям, теперь могут себе позволить и фирмы меньшего размера.
Но еще важнее, что no-code-платформы позволяют внедрить искусственный интеллект, одну из самых революционных технологий этого поколения, не нанимая армию разработчиков и специалистов по данным с огромными зарплатами. Небольшие компании, у которых тоже может быть огромное количество данных, смогут использовать все преимущества ИИ — например, разработать новый клиентский опыт (как автономный автомобиль Tesla), увеличить выручку (как P&G, начавшая рассчитывать рекламные расходы на основе ИИ) или максимизировать эффективность (как цепь поставок Walmart).
Но малому бизнесу сложно даже понять, как и где можно внедрить эту новую технологию. Крупные компании уже разобрались, зачем им нужны данные. Однако они начинали с небольших задач, а не с гигантских мегапроектов — и малому бизнесу стоит поступать так же. Вот что следует учитывать.
1️⃣ Работайте с уже имеющимися данными. Из них часто можно извлечь больше пользы, чем кажется.
2️⃣ Выбирайте важные задачи, оптимизация которых приведет к росту.
3️⃣ Начните с того, что уже получилось у многих других — например, оптимизируйте воронку продаж или снизьте отток клиентов, чтобы ваша команда научилась применять ИИ к широкому набору случаев.
4️⃣ Если какой-то ИИ-проект не дает вам 10-кратной окупаемости, не стесняйтесь от него отказаться: хороших приложений хватает.
No-code-разработка помогает сотрудникам изобретать креативные способы использовать данные, чтобы улучшить или оптимизировать свою работу, а, следовательно, и бизнес компании в целом.
ИИ может принести пользу во всех подразделениях компании, а преимущество no-code-платформ заключается в том, что они не ограничены никакими узкими задачами. С их помощью можно, например, рассчитать требуемую частоту обслуживания станков и понять, какие из них близки к поломке, обнаружить первые признаки недовольства клиентов и снизить отток или решить проблему текучки сотрудников. ИИ может искать паттерны не только в цифрах, но и в тексте: анализировать записи или расшифровки разговоров в сочетании с данными об истории продаж и рекламы, чтобы компаниям было легче автоматизировать сложные процессы.
Для многих организаций работа с no-code-платформой сводится к поиску нужной задачи — и нужной платформы.
🍀 Source >>>
#dev #efficiency #likbez #strategy #technology #tools
ПОДБОРКА ПРЕЗЕНТАЦИЙ ПРО ДИЗАЙН С THE DESIGNOPS SUMMIT (старенькое, но актуальное) - КОММЕНТАРИИ by Юра Ветров
🗃🔮
1. Leisa Reichelt (Atlassian) ― Здорово о том, как структура и методы работы дизайн-команды зависят от головной компании.
2. Brennan Hartich (Intuit) ― Очень простая и понятная метрика оценки продуктивности дизайн-команды ― сколько времени дизайнер тратит непосредственно на дизайн. Она облегчает инвестиции в дизайн-менеджмент.
3. Chris Moses (athenahealth) ― Крутейший подход к формированию и разбору дизайн-долга.
4. Алёна Югина (Shopify) ― Системный подход к инсайт-системе.
5. Jason Mesut ― Карта компетенций продуктового дизайнера на базе его недавней статьи.
6. Courney Kaplan (Facebook) ― Про опыт Design Program Management (популярный термин на конференции) и стремительный рост дизайн-команды (с 2 до 300 дизайнеров за 5 лет).
7. Maria Skaaden (Bekk) ― Единственный кейс, но очень толковый.
8. Doug Powell (IBM) ― Как управлять 1800 дизайнерами и измерять успешность дизайн-организации.
🍀 Source >>>
#case #design #efficiency #event #presentation #product #tools
🗃🔮
1. Leisa Reichelt (Atlassian) ― Здорово о том, как структура и методы работы дизайн-команды зависят от головной компании.
2. Brennan Hartich (Intuit) ― Очень простая и понятная метрика оценки продуктивности дизайн-команды ― сколько времени дизайнер тратит непосредственно на дизайн. Она облегчает инвестиции в дизайн-менеджмент.
3. Chris Moses (athenahealth) ― Крутейший подход к формированию и разбору дизайн-долга.
4. Алёна Югина (Shopify) ― Системный подход к инсайт-системе.
5. Jason Mesut ― Карта компетенций продуктового дизайнера на базе его недавней статьи.
6. Courney Kaplan (Facebook) ― Про опыт Design Program Management (популярный термин на конференции) и стремительный рост дизайн-команды (с 2 до 300 дизайнеров за 5 лет).
7. Maria Skaaden (Bekk) ― Единственный кейс, но очень толковый.
8. Doug Powell (IBM) ― Как управлять 1800 дизайнерами и измерять успешность дизайн-организации.
🍀 Source >>>
#case #design #efficiency #event #presentation #product #tools
