Вопрос: как быть продакт овнером коммерческого продукта?

[Denis Petelin]

Привет всем!
Есть вопрос.
Будучи матерым продакт овнером (в том числе прокси) в оффшорной разработке, наконец занялся тем что давно хотел попробовать - заделать продукт.
Тут же оказался в странной ситуации - если в оффшоре ты имеешь непосредственный доступ к телу носителя вижна продукта и ежедневных пользователей, то с продуктом, раздаваемым на дисках, ты такой возможности лишен.
В саппорт пока волна реквестов не идет, и этот источник данных закрыт.

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

Вопрос - как быть? Какие есть методы отлова\вовлечения конечных пользователей?

--
Хорошего дня,
Денис

[Oleg Vilchinski]

Привет,

 

Проблема на самом деле интересная. Хотя для меня тема и не знакомая, но я бы начал с самого общего кейса и обратился бы к теории маркетинг ресерчей по продуктам (в конечном счете речь идет опродукте).

 

Обычно маркетологи практируют так называемые фокус группы и глубинный интервью (http://www.powerdecisions.com/qualitative-depth-interviews.cfm , http://www.szondaipsos.hu/en/modszereink/melyinterju/melyinterjuen) но это стоит дорого по затратам времени, скилов и денег (никто бесплатно не участвует :) ).

 

Суть подхода:

1. Определяем цели (собираем в кучу пропозалы, мнения, запланированные фичи)
2. Определяем стэйкходеров\пользователей (наше субъективное мнение)
1. Это могут быть потенциальные пользователи
2. Действующие пользователи
3. Сергментируем эту группу (за основу можно взять функциональные фичи\модули продукта чтобы определить кто что будет потреблять или что то др в зависимости от кейса)
4. Проводим так называемый скринтинг опрос, чтобы определить, кто чего хочет\будет потредлять и выявляем реально информативных товарищей потенциально желающих сотрудничать и потенциально полезных нам
5. Определяем что дадим этим товарищам за участие (деньги, бесплатную версию софта, и тд) соотвественно получаем их заинтерисованность
6. Выбираем методику (фокус группа либо глубинное интервью)
7. Проводим интерью или серии интервью
8. Анализируем результаты 

Вобщем это такой теоритический подход, давайте дискутировать :)

 

Best Regards,
Oleg Vilchinski

 

2008/12/12 Denis Petelin <dpet...@gmail.com>

--
Best Regards,
Oleg Vilchinski

[Yuri Shilyaev]

Денис, а что касается UCD -- user centred design Алана Купера?

1. Выделяем ключевых персонажей-пользователей продукта (Вася, Петя, Маша). Описываем их досконально вплоть до того какой пастой они зубы чистят.
2. Пишем сценарии для пользователей продукта. Сценарии использования, которые перекликаются с их жизненными сценариями.
   
3. Выделяем у них ключевые паттерны использования продукта.
4. Определяем реализующую это функциональность.
5. Расставляем приоритеты в зависимости от важности персон и заполненности их требований.
6. Каждое реализованное решение рассматриваем с точки зрения каждого из персонажей.
   

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

ЮШ

2008/12/12 Denis Petelin <dpet...@gmail.com>

--
Юрий Шиляев
yu...@shilyaev.com
http://yuri.shilyaev.com

[Denis Petelin]

Привет!

Оба метода (в упрощенном виде) пытался использовать.

Обнаружил нюанс:

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

Но! Никто не обсуждает стратегических вещей - типа "что важнее (что делать в первую голову): управление классами или elearning?". И ответов на главные вопросы - не получаю. Приходится гадать...

2008/12/12 Yuri Shilyaev <yu...@shilyaev.com>

--
Хорошего дня,
Денис

[Yuri Shilyaev]

Денис, но то, что ты автоматизируешь имеет представление в реально мире?
Раз ты автоматизируешь, значит это уже есть, но не автоматизированное? Почему бы не узнать как дело обстоит в реальности и перенести это на автоматизацию?

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

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

ЮШ

2008/12/15 Denis Petelin <dpet...@gmail.com>

[Denis Petelin]

Ну вот я цинично так и сделал - что мне как продакт овнеру хочется чтоб пользователи делали продуктом, то и закладываю :)
По принципу "захотят - скажут" :)

2008/12/15 Yuri Shilyaev <yu...@shilyaev.com>

--
Хорошего дня,
Денис

[Pavel Gabriel]

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

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

---
С почтением,
Павел Габриель

Mobile: +375 (29) 3-20-30-99

2008/12/15 Denis Petelin <dpet...@gmail.com>

[Denis Petelin]

Короче я как всегда кругом прав :D (смеюсь над собой :))
Спасибо, камрады! :)

2008/12/15 Pavel Gabriel <alo...@gmail.com>

--
Хорошего дня,
Денис