Архив метки: управление проектами

Системность и дисцплинированность

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

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

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

Я постоянно убеждаюсь в этом на практике. Приходит в команду новый человек, который добивается высоких результатов? Он действует систематически, и несмотря на огромную инерцию, дисциплинирует людей и обладает самодисциплиной сам. Увидели потрясающий вирусный креатив? За ним будет стоять профессиональное агентство с детально проработанными процессами. Нашли успешную западную компанию-стартап, которая достигает хороших показателей? Внутри все четко организовано и структурировано. Классный digital-продукт? Под капотом много распределенных продуктовых команд, строгая методология и возведенная в культ ритмичность.

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

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

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

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

По-другому не бывает.

Правда про кастдев, дизайн-мышление, UX research

Я в ИТ-бизнесе с 2007 года. Последние 5 лет изо всех утюгов индустрии можно слышать про важность Customer Development, дизайн-мышления, customer dicovery, UX research и [подставьте свое]. Каждый эксперт настаивает на конкретной методологии и позиционирует ее как панацею от всех продуктовых бед и провалов в бизнесе.

Есть у меня на этот счет одна мысль.

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

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

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

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

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

Три вида продактов

Если вы видите хороший продукт, будьте уверены, что в его главе стоит один из этих 3-х типов людей:

  1. Гений. У человека просто талант. Необъяснимый. Чутье, интуиция, видение. Встречается очень редко.
  2. Профессиональный продуктолог. Самый очевидный сценарий. Человек владеет профессиональной методологией — значит, может с максимальной вероятностью сделать хороший продукт. Практически безотносительно предметной области.
  3. Типичный представитель целевой аудитории продукта. Самый часто встречающийся в России тип владельцев успешных бизнесов. Иногда путается с Гением, однако таковым не является. Секрет такого продакта прост: он сам глубоко погружен в предметную область, сам является представителем типичной (важно, что не меньшинства, а именно типичной) ЦА и оттого очень хорошо понимает проблемы клиентов.

Вот так.

Лучшие материалы по управлению продуктом 2016

Компания Alpha опубликовала очередной дайджест со ссылками на лучшие по их версии материалы по теме управления продуктом за 2016 год. Здесь посты, которые я нашел наиболее интересными и отложил себе на «прочитать позже». Пост обновляется комментариями по итогам прочтения.

As a product manager, what do you spend most of your typical work time on?

По итогам прочтения: очень много ставших клише «В 6 я встаю, а к 8 уже сделал половину рабочих дел за день, и вообще весь мой день космически систематизирован».

How to Pick Winning Product Features

What Do I Do At Work All Day?

По итогам прочтения: вполне реальная рутина, приметил для себя количество времени, которое автор уделяет личным встречам.

Decision Making for PMs

What You Can Do to Simplify Your Products

Why Talking to Customers is the Most Important Thing a Product Manager Can Do

How A Modern Product Team Should Work

Building Products

Product Management for the Enterprise

A Trello template for your Product Backlog

3 Mobile Product Lessons From Uber

Behind Every Great Product

After running 2,000 experiments for Fortune 500 product teams, here’s what we learned

Интуиция против статистики: как расставить приоритеты по внедрению новых функций

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

Перейти к статье на vc.ru

О пользе usability-тестирования

Давайте посмотрим на экран «Контакты» в Skype для Mac.

У меня недавно возникла проблема. Я не знал, как добавить новую группу контактов. Это очень странное ощущение: ты видишь, что группы уже есть (значит ранее ты их уже добавлял), но как добавить новую, совершенно не понимаешь.

Как бы вы добавляли группу? Я подсветил на скриншоте те элементы, которые вроде как могли бы логично вести к такому действию:

Попробуем по очереди.

  1. Кликнем правой кнопкой рядом с имеющимися группами. Не работает(
  2. Поищем в файловом меню, во всех его пунктах. Нет(
  3. Нажмем правой кнопкой на контакт. Нет, там только «Add to List…», но нужного Create new list нет…
  4. Нажмем на кнопку с плюсиком. Не то(
  5. Выйдем на домашний экран. Ничего подобного там нет(

Я совершал 3 подхода к этой задаче. Два раза забивал. В третий раз в отчаянии решил потратить побольше времени, но не гуглить, а разобраться самому.

И я разобрался.

Знаете, где сидел нужный контрол? В модальном окне «Add to List…»

Но почему там? В вашем распоряжении огромный Retina-дисплей Мака. Почему не предусмотреть контрол не в двух кликах, а в одном?

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

Как не повторять ошибок Skype?

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

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

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

Где найти больше информации?

The Guide to Usability Testing

How to Conduct Usability Testing from Start to Finish

 

Управление продуктом: как работать с обратной связью

Это не моя статья, это перевод. Ссылка на источник в конце.

Процесс сбора ценного и своевременного фидбека от клиентов требует времени. Шан Таунсенд, директор по исследованиям Intercom, рассказывает о том, как научиться понимать пользовательские отзывы. В этой статье она объясняет, как распознать и проанализировать те виды отзывов, которые принесут наибольшую пользу вашему бизнесу.

1. Определите, к какой категории пользователей относится автор отзыва

Мы постоянно делимся друг с другом мыслями. Но прислушиваемся ли ко всему, что сказано? Ведь мы склонны доверять мнению тех, с кем давно знакомы. А к советам случайного попутчика вряд ли отнесемся всерьез. Читать далее

Разработка продуктов при помощи Job Stories

Это не моя статья, а перевод. Ссылка на источник в конце материала. 

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

Эта статья Алана Клемента, евангелиста Jobs to be Done, о том, как команда разработчиков проектировала страницу профиля в приложении, используя метод Job Stories. Его суть — в проработке реальных историй того, как продукт выполняет ту или иную работу.

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

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

[Перевод] 12 шагов, которые должен совершить менеджер по продукту в новой компании в первые 30 дней

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

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

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

Давайте выделим 3 основных области, в которых мы будем действовать: люди, продукт и вы сами.

Люди

1. Выясните ожидания СЕО или своего руководителя.

Скорее всего, вас наняли для того, чтобы буквально «заткнуть течь», поэтому вы ощутите на себе давление к немедленной демонстрации результатов. Обсудите с СЕО/руководителем цели, которые он ставит перед вами. Здесь важно убедиться, что у компании правильные ожидания от менеджера по продукту. Ваша главная цель на первый месяц — эффективно влиться в коллектив.

2. Запланируйте встречу тет-а-тет с каждым членом команды.

В зависимости от ее размеров, это действие может занять как несколько часов, так и все 30 дней. Тем не менее найдите на это время.

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

3. Задайте всем один и тот же вопрос: «Что я могу сделать, чтобы облегчить тебе жизнь?»

Этим вы покажете, что вы здесь для того, чтобы помогать, а не командовать. То, в какой манере люди будут отвечать вам – почти так же важно, как и что именно они будут говорить. Вы увидите, как члены команды относятся к роли PM, и что им от вас нужно.

4. Снимите груз с плеч людей.

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

Продукт

5. Запланируйте встречу с главным разработчиком, чтобы вникнуть в архитектуру продукта. Глубоко вникнуть.

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

Часто PM’ы пытаются впечатлить девелоперов своей технической подкованностью, но по моему опыту, последних куда больше впечатляют те продуктологи, которые задают много вопросов и не комплексуют говорить «Я не понимаю».

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

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

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

7. Общайтесь с пользователями

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

8. Исправьте что-нибудь

Я верю, что PM может быть «технарем», и отличное начало – это самостоятельное исправление бага или запуск самой небольшой фичи.

Обустройте себе среду разработки и попросите какую-то маленькую задачу, которая будет вам по силам. Пользуйтесь помощью коллег, но не злоупотребляйте временем своим и команды – вы, в конце концов, PM, а не фул-тайм разработчик.

Личное

9. Прочитайте всю документацию. Если чего-то нет, допишите.

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

10. Поставьте себе цели по личному развитию.

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

Задайте себе вопросы:

— Что вы делаете по-настоящему хорошо и планируете продолжать делать? Получится ли это делать на новом месте? Как именно?

— В чем вам надо вырасти? Какие меры вы для этого предпримите? Как вы измерите свой прогресс?

11. Настройте свою «систему жизнеобеспечения».

Поставьте весь софт, который вам необходим. Настройте все инструменты, включите почтовые фильтры, комфортно обустройтесь на новом рабочем месте.

12. Получайте удовольствие от любимой работы!

А какие советы начинающим PM дали бы вы? Давайте обсудим в комментариях.

Источник: «12 things product managers should do in their first 30 days at a new company», Ken Norton, The Next Web.

Что такое дизайн-мышление: исчерпывающий гайд

В последнее время все те, кто так или иначе задействован в ИТ-проектах, в создании продуктов, в инновационном предпринимательстве, — слышат термин «дизайн-мышление», но мало, кто понимает, о чем идет речь.

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

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

Скриншот 2016-06-29 11.26.07

Посмотреть руководство