Product Manager

@jobstobedone Нравится 0
Это ваш канал? Подтвердите владение для дополнительных возможностей

В этом канале собраны материалы, которые помогают развивать продуктовое мышление и создавать качественные продукты.
Автор канала – @popoffka, продакт-менеджер Яндекс.Карт
Гео и язык канала
Россия, Русский
Категория
Технологии


Гео канала
Россия
Язык канала
Русский
Категория
Технологии
Добавлен в индекс
19.12.2017 17:52
реклама
Хотите получать подписчика по 6 руб?
Подпишитесь на наш канал и узнайте как это сделать
TGStat Bot
Бот для получения статистики каналов не выходя из Telegram
SearcheeBot
Ваш гид в мире Telegram-каналов
58
подписчиков
~0
охват 1 публикации
~10
дневной охват
N/A
постов в день
N/A
ERR %
0
индекс цитирования
Последние публикации
Удалённые
С упоминаниями
Репосты
Product Manager 9 Nov 2019, 15:12
Product Manager 9 Nov 2019, 15:12
Zero Bug Policy (ZBP)

Вчера с коллегами обсуждали подход ZBP. Краткая суть: если не можешь пофиксить баг в ближайшие 2 спринта, закрывай как won’t fix.

Почитала, что пишут про этот подход разные компании, и выделила, как лучше его внедрять.

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

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

Срок жизни бага — 2 спринта. Если за это время баг не починили, значит он не критичный и даже не важный, можно смело закрывать как won’t fix.

Для приоритизации вполне подойдёт простой способ: наиболее серьёзные и быстровыполнимые брать в первую очередь.

Серьёзность бага можно оценить по общепринятой шкале:
blocker — у пользователя нет возможности выполнить целевое действие другим способом;
critical — есть возможность выполнить целевое действие обходным путём, но это не очевидно;
major — есть очевидный и простой обходной путь;
minor — для совершения целевого действия нет необходимости в обходных путях.

Можно чуть больше заморочиться за приоритизацию и оценить баг по матрице (см картинку ниже).
0 или 1 — пожар, чиним сразу;
2 — берём в работу в следующем спринте;
3 — редко, но забираем в бэклог;
4 — закрываем как won’t fix.
Читать полностью
Product Manager 18 Oct 2019, 09:22
Product Manager 18 Oct 2019, 09:22
Как правильно вызвать такси, если вы в 1910 году

Читаю автобиографию Агаты Кристи (1890 - 1976). Книга про традиции того времени, путешествия, любовь, трудности и местами про пользовательские сценарии.

Так с появлением в Лондоне такси возникла целая система подзывать их. Вы становитесь перед своим подъездом. Один свисток — подъезжает старомодный четырёхколёсный экипаж с извозчиком. Два свистка — и пожалуйста, двуколка с извозчиком позади, это уличная гондола. Три — (если повезёт), вы получаете такси.

Карикатура в юмористическом журнале изображала уличного мальчишку, советовавшего стоящему у подъезда дворецкому со свитском в руке:
– Попробуйте четыре раза, сэр, может, самолёт прилетит.
Читать полностью
Product Manager 15 Oct 2019, 16:54
Мудрость от коллеги: большая часть проблем человечества от того, что они не понимаютт, что не понимают друг друга.
Product Manager 1 Jun 2018, 14:57
Product Manager 16 May 2018, 15:35
Product Manager 16 May 2018, 15:35
Хороших UGC-проектов (user generated content) лично я знаю не так уж много. Добавлю в копилку Cost of Living www.numbeo.com. С его помощью можно сравнить стоимость жизни в разных городах/странах. Информацию о ценах на аренду жилья, медицину, продукты и пр. добавляют пользователи со всего мира.
Product Manager 8 Feb 2018, 13:04
MailChimp делает ладошку красной, если вы часто жмёте на неё
Product Manager 8 Feb 2018, 13:04
Google Chrome даёт поиграть с маленьким динозавром, когда пропадает интернет-соединение
Product Manager 8 Feb 2018, 13:04
Product Hunt отправляет спать, если вы слишком увлекаетесь изучением новых продуктов
Product Manager 8 Feb 2018, 13:03
Принципы компании Lego

☝️Продукт – часть большой системы
Часто в процессе создания продукта PM и дизайнеры неосознанно превращают его в автономную систему (функциональность, тестирование, дистрибуция). Однако важно помнить, что после запуска продукт станет частью большого мира. Поэтому важно понимать, где находятся потребители, когда взаимодействуют с продуктом, как узнают о нём, что делали до этого и что будут делать после.

☝️Игровые моменты в продукте
Позволяют создать эмоциональную связь с продуктом, включить в продукт «моменты радости». Понятно, что у Lego в этом смысле большое поле для творчества. Но сервисы напрямую не связанные с процессом игры, активно внедряют этот подход:
– Product Hunt отправляет спать, если вы слишком увлекаетесь изучением новых продуктов,
– Google Chrome даёт поиграть с маленьким динозавром, когда пропадает интернет-соединение,
– MailChimp делает ладошку красной, если вы часто жмёте на неё.

☝️Думать не только головой, но и руками
Все, что можно потрогать в продукте, нужно потрогать и потестировать на собственном опыте. У дизайнера Lego забрали карандаш и сказали: «Эскизы – это хорошо, но лучше займись строительством». Если вы делаете интернет-продукт, находите проблемы и пробуйте лично решить их с помощью своего сервиса.

☝️Разобрать что-либо на части, чтобы найти лучшее решение
На создание нового набора в Lego уходит 1,5 года. За это время команда может позволить себе «разобрать на части и начать заново». В IT за это время можно проиграть конкурентам. Однако этот принцип вполне рабочий, на мой взгляд, в техническом смысле. Когда система не выдерживает и постоянно падает от растущей нагрузки, нужно «разобрать её на части» и понять, каким образом повысить стабильность работы.

☝️Простота – это сила
Lego даёт людям возможность строить быстро, эффективно и – самое главное – небрежно, на глаз. Пользователь не должен при виде продукта бояться, что у него что-то не получится. Кроме того, порог входа в продукт не должен быть высоким (сложная система регистрации, запрос на демо-версию с длинной анкетой и пр), у пользователя должна быть возможность в момент интереса попробовать и понять, решает ли продукт его проблему.

☝️Планы могут меняться, и это нормально
Не нужно до посинения вкладываться в первоначальную концепцию продукта. Особенно, если появились новые детали и вводные в процессе общения с клиентами, изучения системы, в которой они живут. Нужно всегда быть готовым к тому, что продукт будет использоваться не так, как задумала команда.
Читать полностью
Product Manager 8 Feb 2018, 13:01
Документальный фильм про компанию LEGO (русская озвучка), после которого захотелось разобраться, каких принципов они придерживаются в создании продуктов https://youtu.be/SzTkHTD6L3k
Product Manager 2 Feb 2018, 13:05
Product Manager 2 Feb 2018, 13:05
Про «дыры» в воронке продаж

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

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

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

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

Ключевые метрики и жалобы в саппорт лучше мониторить ежедневно.
Читать полностью
Product Manager 30 Jan 2018, 10:27
Product Manager 30 Jan 2018, 10:27
Когда случайно решил проблему, которой даже не было в сценариях использования продукта
Product Manager 29 Jan 2018, 13:22
Product Manager 29 Jan 2018, 13:21
Story Mapping – это способ визуализировать сценарий разработки продукта. Помогает расставлять приоритеты и выстраивать взаимодействие внутри команды: все работают над одной проблемой и понимают, каким должен быть финальный результат.

Команда «Додо Пицца» рассказала, как сторимэп не дала им завязнуть в разработке нового продукта на годы: https://habrahabr.ru/post/345524
Product Manager 29 Dec 2017, 17:31