Рубрика «product management» - 5

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

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

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

Рецепт гладкого релиза: PMy на заметку - 1
Читать полностью »

image

Хороший продакт всегда думает о проблемах пользователя, интересах компании и о том, что надо сделать, чтобы обе стороны были довольны. Это и есть продуктовое мышление. Оно помогает принимать решения и находить точки роста. Но даже у опытных менеджеров бывают слепые зоны — незаметные ловушки, которые приводят к ошибкам. Спикер курса Product Owner Weekend Алексей Авдей — директор сайта sberbank.ru, ранее — Chief Product Officer «ЦИАН» и руководитель Яндекс.Маркета, перечислил типичные ошибки на каждом из этапов жизни продукта и рассказал, как с ними бороться.
Читать полностью »

Предлагаю выделить каналы в отдельный таб и немного доработать:

Как улучшить каналы в Telegram? - 1
Читать полностью »

Сегодня расскажем, как переводили на микросервисы монолитное решение. Через наше приложение круглосуточно проходит от 20 до 120 тысяч транзакций в сутки. Пользователи работают в 12 часовых поясах. В то же время функционал добавлялся много и часто, что довольно сложно делать на монолите. Вот почему системе требовались устойчивая работа в режиме 24/7, то есть HighLoad, High Availability и Fault Tolerance.

Мы развиваем этот продукт по модели MVP. Архитектура менялась в несколько этапов вслед за требованиями бизнеса. Первоначально не было возможности сделать всё и сразу, потому что никто не знал, как должно выглядеть решение. Мы двигались по модели Agile, итерациями добавляя и расширяя функциональность.

Как перейти на микросервисы и не разломать production - 1
Читать полностью »

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

image

В центре кадра — Julie Zhuo, product design director в Facebook

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

Я люблю свою работу. Мне кажется, что из-за людей она и тяжелая, и безумная, и чудесная. Она о взаимодействии с людьми. О понимании людей. О поиске самого лучшего в людях. И снова о понимании, что все не идеальны, но вместе с нашими несовершенствами мы все равно можем добиться большего, чем в одиночку.Читать полностью »

«Я не злюсь, я просто разочарован.»
— PM

image

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

Представляем вам чеклист из 50 пунктов для самопроверки. Вот примерные подразделы:

  1. Логин и регистрация
  2. Первый опыт
  3. Важные детали
  4. Запуск
  5. Профиль
  6. Безумные потоки

Читать полностью »

«Роль аналитика в принятии важных продуктовых решений»: видеозаписи докладов с митапа - 1

В конце сентября в питерском офисе Wrike прошла встреча для продуктовых аналитиков и менеджеров по продукту. Встреча была посвящена вопросам качественной (vs количественная) аналитики, взаимодействию аналитиков и продакт-оунеров, процессу и инструментам валидации продуктовых изменений.

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

Встреча в Петербурге «Роль аналитика в принятии важных продуктовых решений» - 1

Что может помочь менеджеру по продукту минимизировать риски при принятии решений по развитию тех или иных фич? Насколько веским может и должно быть слово аналитика в процессе разработки? Есть ли у продуктовых аналитиков какой-то иной инструментарий, кроме количественных данных?
20 сентября в офисе Wrike в Санкт-Петербурге мы встретимся составом продуктовых аналитиков и продакт-менеджеров, чтобы постараться ответить на эти вопросы.

Встреча будет посвящена проблемам качественной (vs количественная) аналитики, взаимодействию аналитиков и продакт-оунеров, процессу и инструментам валидации продуктовых изменений. Поговорим о том, как оценивать качество продуктов, проверять продуктовые гипотезы, собирать релевантный пользовательский фидбек и выстраивать роадмап развития продукта, исходя из него.
Читать полностью »

Черты великого продакт-менеджера - 1

Почему у одних людей ничего не получается, а другие доводят любое дело до конца? В чем разница между хорошими и выдающимися профессионалами? Где грань между деспотизмом и верой в результат? Ну и что объединяет прекрасных продакт-менеджеров в клуб настоящих профессионалов? Под катом прекрасный рассказ Лоуренса Рипшера.Читать полностью »

После завершения (с любым итогом) проекта менеджер обязан написать т.н. «post mortem». Цель очевидна: сделать хорошее и плохое, что было в ходе проекта явным как для себя, так и для других. Если бы жанр таких post mortem стал более популярен у нас, уверен, процент успешных проектов от этого вырос бы, какими бы ни были критерии «успешности».

В этом тексте я опишу часть истории проекта в весьма бурно сейчас развивающемся домене TNC (Transportation Network Companies), а более точно – ROD (Ride on Demand). Если совсем по-простому, сервис заказа такси. В середине прошлого года одна достаточно крупная западная TNC (далее – «Энтерпрайз») приобрела в России игрока регионального уровня, б.ч. бизнеса которого была сосредоточена в средней полосе России. У этого игрока, назовём его «Такси 666», имелось семейство продуктов собственной разработки: приложения на Андроиде для клиентов и водителей, а также ряд Delphi-приложений, необходимых для управления таким бизнесом (принятие водителей, просмотр статистики и пр.). Отдельно стоит упомянуть Delphi-приложение для операторов, принимающих заявки по телефону. Особенностью, отличавшей модель бизнеса Такси 666 от наиболее известных TNC вроде Uber’а, было то, что телефонные заказы занимали долю около 80%, при этом никакой тенденции к увеличению доли заказов через приложение не наблюдалось. Тем не менее, Энтерпрайз воспринял такое положение вещей не как проблемную ситуацию (за которой много чего скрывалось – см. ниже), а как своего рода конкурентное преимущество для России с её необъятными просторами и в целом ещё низкой (но быстро растущей) долей проникновения мобильного Интернета.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js