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

В этой статье вы узнаете о «пиратских» метриках AARRR, которые помогают стартапам и SaaS компаниям настроить механику привлечения и удержания клиентов.
Это отличная методика для измерения и оптимизации эффективности в каждой точке воронки продаж. Достоинство AARRR в простоте и доступности внедрения: никаких технических знаний. Как ее использовать и почему она так называется?

Когда-то девизом компании была фраза «Don't be evil». Времена изменились.



В день когда я покидал пост главы отдела международных отношений в Google, я не мог не вспоминать свой первый день в компании. Тогда я сменил офис, отделанный деревянными панелями, костюм и галстук, а так же работу в качестве заместителя главы администрации губернатора Шварцнеггера на ноутбук, джинсы и обещание, что я сделаю мир лучше, под простым, но таким сильным лозунгом «Don't be evil».

Перевод статьи подготовлен специально для студентов курса «Product Manager IT-проектов»

---

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

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

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

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

Product Manager очень часто выступает первым представителем продукта или сервиса для внешнего мира. Для этого успешному PM требуется опыт, энтузиазм и, конечно, профессиональные управленческие навыки, коммуникативные и другие способности. Набор этих качеств помогает специалисту грамотно представить продукт и вывести его на рынок.

Вдохновение попробовать себя в качестве менеджера продукта может посетить любого члена команды. Обязательно ли для этого иметь специальное образование, если такое вообще найдется в ближайшем доступе? И достаточно ли просто “горящих глаз” и большого желания, чтобы стать успешным product manager? Истории многих крупных компаний и стартапов показывают, что можно.

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

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

Вам приходилось испытывать сильные эмоции на работе? Как насчёт страха, внезапно захлестнувшего ваш мозг? Легко потом работать эффективно? Если ваша организация уже внедрила agile, но с вами такое всё еще случается – что-то идёт не так.

Меня зовут Артем Зарафьянц, и я руковожу одним из отделов разработки СХД Dell Technologies в Санкт-Петербурге. Работаю 12 лет, с открытия нашего офиса. В 2007 году, начиная работу над VNXe, мы стали использовать agile на уровне команды – тогда не сложилось. Наш процесс столкнулся с ватерфоллом на глобальном уровне и постепенно угас. VNXe мы выпускали без agile: конечно же, успешно (как и всё масштабное в нашей корпорации), однако медленно, дорого и на стрессе. Примерно 6 лет назад наша инженерная организация (несколько тысяч сотрудников) начала систематическое внедрение agile at scale сверху. В то время я уже был менеджером и получил второе (из трёх) высшее образование – по психологии. Это помогло мне осознанно пройти через опыт внедрения agile, и я готов им поделиться.

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

Совсем скоро состоится релиз новой версии хостинговой панели Plesk под названием Plesk Onyx. Начиная с этой версии Plesk прекращает поддержку 32-битной архитектуры. Решение об этом было принято после рассмотрения нескольких ключевых аспектов. Индустрия разработки ПО постепенно движется к повсеместному переходу на 64-битные сборки. Многие производители софта уже отказались от 32-битной версии своих продуктов, и новые шаги в этом направлении происходят непрерывно. Дистрибутив RHEL 7, используемый в качестве основы CentOS, выпускается только для 64-разрядных систем – а между тем CentOS является одной из самых популярных среди пользователей Plesk операционных систем. Кроме того, сторонники 32-разрядных ОС лишают себя возможности воспользоваться такой функциональностью Plesk, как работа с Docker и MongoDB, в силу того, что эти продукты могут быть установлены только на 64-разрядные операционные системы.

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

Окей, гугл – как понять, кого именно необходимо оповестить? «Отзовитесь, динозавры!» Без статистики использования продукта здесь не справиться, но чтобы получить из неё что-то внятное, придется потрудиться.

Всем привет, недавно мы писали о том, как учились быть Data Driven с Симулятором GoPractice! В этом выпуске продолжим тему анализа данных и поговорим о выстраивании процесса работы с аналитикой в команде Plesk.

Plesk — сложный продукт с 20-летним бэкграундом и эффективно собирать необходимую статистику мы умели не всегда. В течение долгого времени мы смотрели на данные только ретроспективно, а решения принимали на основе субъективных ощущений «как должно быть». В прошлом у нас уже были печальные последствия такого подхода, — в 2012 году мы поменяли дизайн, желая сделать как лучше, а получили волну негативного фидбека, отказ обновляться на последнюю версию продукта и отток клиентов.

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

Для начала об авторе – я более 20 лет проработал в ИТ в трех компаниях: EMC, IBM, Sun (в алфавитном порядке). Начинал как системный инженер сразу после университета, потом был старшим инженером, техническим консультантом, руководителем технических консультантов и, наконец, техническим директором, руководившим командой пресейлов и архитекторов всего более 70-ти человек. Кроме того, год я был лидером продавцов через партнеров (Channel Sales Leader), распределенных по Центральной и Восточной Европе. Ниже я попытаюсь поделиться своим опытом именно, как руководителя и, дабы не возникало не правильных или не нужных ассоциаций, я буду приводить примеры из практики во время работы на компанию ABC (тоже три буквы). Возможно, изложение несколько однобоко, поскольку все мои работодатели – крупные международные компании, и я работал в их региональных офисах. Ну, тогда с этой спецификой я не могу ничего поделать и то, что читатель сочтет не приемлемым и не правильным пусть и останется таковым персонально для него.

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

В этой статье мы расскажем о нескольких моделях оценки применимости Agile и подробнее остановимся на одной их них — Agile Suitability Model, представленной в Agile Practice Guide от PMI и Agile Alliance.

Два года назад мы впервые решили собрать почти полсотни наших удаленных разработчиков и продактов вместе и познакомить друг с другом в приятной непринужденной обстановке. Так случился хакатон под Чеховым в Подмосковье, это было здорово, всем понравилось и все хотели еще. И мы продолжили собирать наших удаленных разработчиков вместе "вживую", только поменяли формат: теперь это не общий хакатон, а выезды отдельных команд. Это статья — о том, почему мы перешли на новый формат, как он у нас организован и какие результаты мы получили.

Всем привет. Мы продолжаем серию про управление клиентским опытом. (Р) — Роман Нохрин — Задает вопросы, (А) — Арсен Даллакян, управляющий партнер консалтинговой компании Russian Behavioral Unit — отвечает.

(Р) Последнее время во многих компаниях заметна трансформация подхода в управлении. Раньше вообще было не понятно что — как получалось. Потом появился сегментный подход. Решили, что «богатых» клиентов так обслуживаем, массовых клиентов – так. И прямо разделили команды, разделили все процессы.

Время шло и сейчас пришли к продуктовому подходу. Есть какой-то продукт, выделяется команда, делает его хорошо, все ОК. Но продуктов 500, отдел продаж один, начинается суета. Если это продукт, в котором нужно подключить разработчиков, то они не переиспользуют свой код между командами, во всех сторонах начинается хаос. Хочется понять: что делать и как этим эффективно управлять?

Привет, Хаброжители! В последние годы произошел всплеск интереса к дизайн-мышлению. Мы живем в эпоху, когда банки отказываются от традиционных банковских операций и переходят на цифровые деньги. На наших глазах рождаются стартапы, которые создают новые рынки, используя дизайн-экосистемы. Современные компании осуществляют цифровую трансформацию, чтобы по максимуму использовать современные методы обработки данных и быть на шаг впереди конкурентов. Книгу-героиню нашего сегодняшнего поста следует рассматривать как настоящую рабочую тетрадь. Это не руководство в привычном смысле, где описываются процессы.
Книга скорее дает вдохновляющий импульс для внедрения чего-то нового и реализации полного потенциала дизайн-мышления. Эта книга о том, как действовать, тестировать и размышлять. Авторы помогут вам: применить различные инструменты и методы дизайн-мышления в конкретных ситуациях; создать эффективную команду; ориентировать продукт на пользователя; ввести дизайн-мышление в организациях; научиться создавать цифровую продукцию; объединить дизайн-мышление с Big Data. В выбранном нами отрывке пойдёт речь об эффективном тестировании прототипа:

Если вдруг вы не знали, сегодня можно поднять сервер, запустить и откатить деплой, заскейлить кластер, просто отправив сообщение телеграм-боту.

Эдуард Медведев, CTO в Tungsten Labs (Германия), выступал на третьем дне Слёрма DevOps с темой «Автоматизация инфраструктуры с ChatOps» и рассказывал об интеграции мессенджеров с пайплайнами. А после выступления за чашкой кофе дал интервью.

Я рассчитывал на рассказ об интересной технологии, а в итоге разговор свернул на тему it-этики. О том, как человек превращается в лабораторную крысу, которая каждый день бежит в лабиринте алгоритмов аддикции и контроля внимания, как автоматизируется война, как торговля оружием и наркотиками выходит на новый уровень анонимности и доступности, как айтишники пишут код, разрушающий общество и личность — и прикрываются старым как мир «мы просто выполняли заказ».

Всем привет. Это очередной выпуск про управление клиентским опытом. (Р) — Роман Нохрин — Задает вопросы, (А) — Арсен Даллакян, управляющий партнер консалтинговой компании Russian Behavioral Unit — отвечает.

(Р) Последние годы самые популярные слова — agile, CJM, фреймворк. Услышал: «все внедряют agile" — не знаю, что это такое, но мне тоже надо. Все вешают на стены CJM – наверное, тоже надо на доске что-нибудь нарисовать. Что это за тренды и что с этим делать и делать ли?

В первом посте об аналитической системе Sports.ru и Tribuna.com мы рассказали о том, как используем нашу инфраструктуру в повседневной жизни: наполняем контентом рекомендательную систему, наблюдаем за бизнес-метриками, ищем среди пользовательского контента бриллианты, находим ответы на вопросы “Как работает лучше?” и “Почему?”, нарезаем пользователей для почтовых рассылок и строим красивые отчеты о деятельности компании. Всю техническую часть повествования мы скромно спрятали за этой схемой:



Читатели законно потребовали продолжить повествование со смешными котиками, а olegbunin пригласил рассказать о всем, что было скрыто, на РИТ++. Что ж, изложим некоторые технические детали – в продолжении веселого поста.

Привет, Хабр. Эта статья посвящена итогам четырехлетней разработки набора методов и инструментов обработки траекторий движения пользователей в приложении или на сайте. Автор разработки — Максим Годзи, который стоит во главе команды создателей продукта, он же — автор статьи. Сам продукт получил название Retentioneering, сейчас он преобразован в open-source библиотеку и размещен на Github, чтобы любой желающий мог им воспользоваться. Все это может быть интересно тем, кто связан с продуктовым и маркетинговым анализом, продвижением и развитием продукта. Кстати, на Хабре уже публиковалась статья об одном из кейсов работы с Retentioneering. В новом материале рассказывается о том, на что способен продукт и как его можно использовать.

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