На Хабре отличный пост про то, какие бывают типы программистов и особенностях командной работы с каждым из них - https://m.habrahabr.ru/post/336248/

Хороший пример презентации от UBER. Проблемы, их решение и преимущества продукта. И да, это их самая первая преза для инвесторов. https://speakerdeck.com/panphilov/uber-pitch-deck

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

Harvard Business Review отлично дополнили свою модель монетизации контента по классической подписке... продажей этого же контента, но запакованного в спец. подборки... http://hbr-russia.ru/sborniki/

Есть две стратегии развития продуктов и бизнеса: экстенсивная и интенсивная.

Экстенсивная - когда приходится набирать всё больше и больше сотрудников, закрывая ими растущие объёмы работ. Очень часто это приводит к ещё большему количеству проблем из-за выросшего человеческого фактора и общему упадку уровня производительности труда.

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

Что-то очень понравилась фраза

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

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

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

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

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

Как видите, простые dropdown-менюшки с заранее заготовленными причинами отказа и(или) рекомендациями могут принести немало пользы. Само собой, поле "Добавить комментарий менеджера" всегда должен быть.

P.S. Как нельзя лучше этот совет описывает еврейская поговорка - "сэкономил — значит, заработал".

Не задумывались, почему интерфейс Booking.com кажется таким перегруженным? На самом деле, за каждым UI-блоком на его сайте стоят конверсии, исчисляемые миллионами и миллонами долларов.

Нашел интересную статью на английском о том, как они манипулируют сознанием пользователей (в хорошем смысле слова), которые приносят им свои деньги - https://goo.gl/giAM3n. "Перевести на русский" никто не отменял :)

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

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

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

1. Этап разработки и запуска MVP
2. Этап роста пользовательской базы
3. Этап выхода на безубыточность
4. Этап генерации прибыли
5. Этап масштабирования прибыли

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

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

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

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

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

Павел Дуров анонсировал еще одну версию мессенджера - Телеграм Х. Тёмный, стильный, очень быстрый и, самое главное - более гибкий, т.к. написан на Свифте.

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

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

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

На языке программистов есть даже термин fork (англ. fork — развилка, вилка) или ответвление — использование кодовой базы программного проекта в качестве старта для другого), т.е. в нашем случае, Дуров «форкнул» ТГ и в его новой версии будет смело проводить эксперименты, в то время как стабильная старая также будет работать.

Бот из скриншота - @campusim_bot

Cпринт - понятие растяжимое 😄

Инфа для тех, кто мечтает «работать в Гугл». Не говорю уже о жёсткой служебной иерархии, отсутствии свободы действий и инакомыслия (инфа сотка, общался с чуваками в SF).

Когда работаешь в стартапе

И в этом вся разница

Только что нашел в предложке на Единороге и делюсь с вами. @lexmosolov перевел первую главу легендарной книги чуваков из Intercom под названием "Starting Up" и выложил ее на Медиуме. Читал её еще на английском и готов сказать, что в ней много простых и работающих советов.

Вот теперь и на русском: https://goo.gl/MKXpJn

Рекомендуется к просмотру всем, кто связан с продуктами. https://youtu.be/aid-H-_j5FU

Сильный текст про пользователей, продукты и команды.
http://telegra.ph/YA-rabotayu-v-produktovoj-kompanii-CHto-ehto-znachit-02-26

Pet Feature - это та "хотелка" заказчика, которая не несет ценности для продукта. Термин появился благодаря слову pet - "домашний питомец", которого заказчик холит и лелеет.

Например, у вас для отдела технической поддержки в разработке система по разбору запросов пользователей. Тут прибегает заказчик/овнер/инвестор и говорит - а пусть при отправке ответа пользователю на экране появляются фейрверки с мотивирующими надписями "Молодец! Продолжай в том же духе!".

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

Определить Pet Feature очень просто. Задайте себе вопрос - мы делаем эту хотелку, чтобы что? Потому что вы так хотите или потому что это пойдет на пользу продукту?

PS. Термин вообще достаточно редкий, но, для примера, встречается в книге "Impact Mapping: Making a big impact with software products and projects" и на различных англоязычных сайтах, посвященных Impact Mapping (а Impact Mapping - это метод отрисовки карты влияния, помогающей заказчику определиться с целями, но это уже совсем другая история...)

Нашел у @analysis_paradisis