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



Product roadmap требует четкого порядка. Только качественно разложив все «по полочкам» можно получить достойный и успешный релиз продукта. В этом случае не обойтись без удобного способа приоритизации.

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

Как вы знаете, в городе-курорте Самара мы время от времени проводим Фестиваль 404, куда приезжают разные люди и делятся опытом. Доклады записываем на видео и выкладываем совершенно бесплатно на свой канал youtube. Там накопилось много интересного и мы сделали небольшую подборку самого популярного видео докладов прошлых лет.

Вас ждут тонны полезной информации и реки ностальгических слёз!

Давайте представим, что вы управляете продуктом, который помогает малому бизнесу осуществлять техническую поддержку своих клиентов. Вы ищете способы увеличить степень вовлечённости (engagement) и возвращаемости (retention) своих клиентов. У вас есть две идеи:

• Дашборд, который позволит владельцам бизнеса мониторить статистику вовлечённости.
• Чат-бот, который поможет владельцам бизнеса автоматизировать коммуникацию с потребителями.

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

Что вы выберете?

Большая часть статей об A/B-тестах посвящена веб-разработке, и несмотря на актуальность этого инструмента и для других платформ, мобильная разработка несправедливо остаётся в стороне. Мы попытаемся эту несправедливость устранить, описав основные шаги и раскрыв особенности реализации и проведения A/B-тестов на мобильных платформах.

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

1. Забудьте о процессе, работайте на результат

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

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

Помните правила великого Кутузова, который четко и ясно видел стратегические цели? Он считал, что стратегия должна всегда превалировать над тактикой. Для победы вполне допустимо пожертвовать отдельной битвой, ведь «главное не крепость взять, а войну выиграть».

В статье будет приведено несколько терминов, а также примеры индустрий, где неграмотный менеджмент может привести к катастрофе.

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

Эта статья написана совместно с Питером Лайоном. Питер является вице-президентом Customer Success в компании Brightflag и сооснователем Customer Success Network

Каждый Customer Success менеджер (CSM) должен хорошо уметь выстраивать коммуникацию со своими клиентами. Это общий навык, но он потребует от вас постоянной работы над целым рядом своих поднавыков. Один из которых — способность эффективно готовить и задавать вопросы.

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

Привет, Хабр!

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

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

11 ноября провели у нас в офисе Product Management Meetup. Говорили про
продуктовую аналитику, скрам, способы элегантной монетизации и отдел дизайна.

Под катом — делимся видео и презентациями докладчиков.

Примечание автора спустя 42 года после публикации:

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

Любая организация, проектирующая систему (трактуется здесь шире, чем просто информационная система), неизбежно создаст такую модель, которая будет повторять коммуникационную структуру самой организации.

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

Предлагаю вам ознакомиться с материалом, а потом оглянуться и поискать его в других сферах.

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

Как комитеты создают новое?

Мелвин Конвей (Melvin E. Conway)
Оригинал PDF.

У меня есть нож, есть арбалет,
Они служат мне уже тысячу лет.

(с) КиШ

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

От переводчика:
Начало года — отличное время, чтобы вдумчиво оценить прошедший год. Окинуть широким взглядом происходящее и понять, как сделать 2019 год лучше, спокойнее и продуктивнее. В этом деле нам показалась полезной статья How To Slow Down to Go Faster Than Ever in Software Development, которую написал Lemi Orhan Ergin. А ее перевод мы публикуем ниже.

Ключевой проблемой любой организации являются изменения.

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

Если все эти проблемы объединить под одним словом, то словом этим будет «изменения». Именно с ними и проблемы. Тут вроде ничего доказывать не надо, все на поверхности лежит, но на всякий случай пару тезисов приведу.

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

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

Если у вас проблемы с автоматизацией, то вам нужны изменения. Очевидно? Вроде да. Или платформу сменить, или программный продукт другой взять, или программистов нанять, или программистов разогнать, или порядочного аутсорсера найти (ха-ха), или перестать пользоваться колхозным интегратором и нанять федерального, или послать федералов и найти в своей деревне увлеченного фаната, или пересмотреть управление ИТ-отделом, или изменить мотивацию программистов. Не важно, что именно, но что-то надо менять.

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

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



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

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

Тараканы Корпоративные (токсичность:☣☣☣)

Ареал обитания и повадки:
Заводятся в крупных корпорациях, в маленьких компаниях приживаются плохо. Тараканам нужно много бегать и утверждать переутверждение согласованных согласований. Максимум движений с отрицательной пользой.

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

Недавно YouTube объявил о больших изменениях на подписной платформе YouTube Premium (раньше она называлась YouTube Red): они отказываются от подписки и открывают премиум-контент бесплатно (но с рекламой) для всех пользователей YouTube. Издание USA Today опубликовало статью об этом под заголовком «Не все готовы платить за подписку. Не верите? Спросите YouTube». Согласно этой статье, люди устали от подписок — или, цитируя статью: «Пользователи сказали свое слово. Хватит уже этих подписок».

Есть множество подписных сервисов — и вполне вероятно, мы можем достичь точки насыщения. Однако я не думаю, что проблема у YouTube Premium была именно в этом: люди будут платить почти за все, что дает то, что кажется им ценным и вписывается в их представление о мире — ради этого они готовы даже залезть в долги. Поэтому кредитные карты так популярны.

Думаю, настоящая проблема с YouTube Premium была в том, что они решили повторить то, что делают другие сервисы потокового видео.

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

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

Переведено в Alconost

Денис Пушкин, Head of Product Marketing в Skyeng, рассказал о том, что вдохновляет его на создание и развитие продуктов.



Давайте начнем с того, чем занимается менеджер продукта — это три известных всем области:

1. IT-продукты — в основном сайты и мобильные приложения.
2. Операционка — операционные процессы в любых сервисах, например, в колл-центре или доставке еды.
3. Человек. Самые модные ребята в продуктовой тусовке прокачивают себя как продукт.

Этим списком все ограничиваются, потому что непонятно, а что еще можно прокачать как продукт. Но мне кажется, что менеджеры продукта думают слишком узко о том, чем они занимаются. Менеджер продукта — не профессия, а состояние души или mindset. Mindset — это набор ваших убеждений, которые вы применяете где угодно.

Как следует из названия, это продолжение серии статей про роли в scrum (часть 1 и часть 2). Сегодня рассмотрим следующую роль – scrum master. Как это ни парадоксально, успешность scrum во многом зависит от scrum мастера. Поэтому хочется снова призвать силу воображения и привести метафору (дисклеймер: пример никоим образом не должен оскорбить чьих-либо чувств). Есть культура, у которой есть свой культ, свои обряды, есть служители этого культа. Служителей можно разделить на различные классы:

• те, кто со своей культурой предпочитают быть один на один — отшельники, затворники, просветленные;
• те, кто выучили все правила, нашли лазейки, понимают, что и как делать, и используют культ в корыстных целях, наживаясь на людях, их страхах и предубеждениях;
• фанатики, которые пытаются насадить свою культуру к месту и не к месту. Для которых кроме их знаний, всё остальное ересь;
• те, кто искренне верит, чувствует и пытается поделиться, помочь и подарить это чудо людям; они рассказывают и объясняют, слушают и пытаются помочь.

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

Давайте разберемся, какие тревожные симптомы могут быть у SM.

Я больше 10 лет работаю с / в / для agile в сфере web-разработки. Из них больше всего пришлось иметь дело с самым популярным agile фреймворком — scrum (по данным VersionOne). Хочу поделиться с вами накопленными наблюдениями и выводами.

Начну с метафоры, так как иногда приходилось видеть внедрение scrum по такому сценарию:

• До scrum: «разработка» как младенец — она целеустремленна, но не умеет нормально ходить, а очень хочет научиться, чтобы добираться до цели.
• Внедрение: приходит учитель (scrum тренинги, курсы, agile coach и т.п.) и показывает, как ходить. Малыш счастлив, он двигается шагами! Топ-топ-топ. У нас спринты — мы ходим!
• После внедрения: терпеливые стейкхолдеры говорят: «Окей, погнали к цели», на что получают «не давите на команду, мы ходим!». Разработка выписывает интересные траектории и получает удовольствие от процесса, но цель забыта.
• Scrum-но: дальше пилюля правды от бизнеса, scrum «мутирует» и позволяет бизнесу получать какой-никакой продукт от разработки. И, к сожалению, формально ставится галочка «мы работаем по scrum», а реальный потенциал команды разработки так и не раскрыт, да и кругом говорят «scrum ненастоящий».