Monthly Archives: May 2012

И все таки зачем Facebook купил Instagram? Facebook что-то задумал…

Пока не попробовал Instargam, то много разных догадок было. Но когда его установил…. в результате вообще перестал понимать, еще и за 1 миллиард….

Видимо много факторов есть, как связанных с выходом на IPO, получить команду в месте с сервисом… Но все равно как-то сильно круто.

И вот возникла мысль на фоне этого непонимания.

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

Теперь проведем аналогию.

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

А что нужно, чтобы ожила социальная сеть приложений, другими словами, платформа Facebook? Нужно, чтобы стартаперы решили под нее писать. А когда они будут под нее писать? А тогда, когда будет побольше шансов, что Цукерберг позвонит.

Первая встреча product менеджеров в IT. Отчет.

Побывал на встрече product менеджеров в IT. Чистых продакт-менеджеров так и не встретил, в принципе и не расчитывал, потому что сложно быть на пересечении всех стейкхолдеров и не отдать предпочтение какой-то деятельности при этом. Но полезные и неочевидные вещи о Product Managment-е узнал. И очень хорошо, что докладчики делились живым опытом и стало на много более понятно “как это у других”.
За что докладчикам большое спасибо!

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

Идея встречи появилась у Вики после попытки найти Product Management для Grammarly. И на сколько я понял, не очень успешной – все заполонил аутсорсинг 🙂
Иван Онищенко. Systems Analyst and Architect at PocketBook International
Период доклада: 1-3 года назад.
Продукты ориентированы на малый и средний бизнес, виртуальные сервера.
Иногда продукты делают, чтобы продать компанию – создать продукт и продать его.
Успешные продукты обычно начинаются с небольших комманд – 1 чел, нет накладных продуктов на общение.
4 из 6 успешных продуктов – начинает 1 человек.
Важно делать быстро, потому что даже всего 10 человек за 1 год стоят очень дорого.
Появляются проблемы: после выхода первой версии появляется поддержка, сопровождение и обратная совместимость. Скорость развития падает и в конце концов становится не выгодно сопровождать.
Появляется вопрос, что с продуктом делать делать.
Убить продукт тоже сложно 🙂 кейс – до нескольких месяцев.
В какой то момент появляется вопрос:
Нужен продакт менеджер. Кто он такой из зачем?
Product manager в центре общения с топ-менеджментом, сейлз, маркетинг, разработа, суппорт, и.т….
Основная сложность Product Manager-а – передать девелопменту свое видения продукта, чтобы он получил на выходе то, что соответствовало его изначальному видению.
Обязанности Product Manager: требования, роадмеп, приоритеты…
Должен отвечать на вопросы: какие фичи будут и когда?
Также лицензирование у него – часть, связана с реализацией. Но политика не он определяет.
Основные проблемы Product Management: отсутствие Product Manager.
Для продукта очень важна реализация, хороший процесс.
Вредные советы:
* все и сразу
* “сделайте хоть как-то чтобы работало”, а потом “а почему это не работает?”
* универсальные решения
Игорь Иващенко Development Services Director at Software MacKiev

Идея в жизненном цикле продукта.

На примере приложения для iOS
Помним о главном! Идея!
Ценность идеи:
* уникальность рынка. Идея может открыть новый рынок
* польза пользователям.
* удовольствие при использовании.
Стоимость идеи ноль, пока она не реализована.
Источники идеи:
* рынок и  его требования
* конкуренты и их успехи
* пользователи и их негодование, возможно пользователи наших старых продуктов. Не нужно этого бояться, пусть поругают. Минимум – это пиар, максимум – беклог на следующие 3-4 версии
* сторонные профессиональные критики и обозреватели.
* отдел маркетинга и его понимание того, что выше.
Идеи с рынка.
основные направление, сопутствующие технологии, новшества платформы, что будет завтра – аналитики, убедить рынок в суперновости идеи 🙂
Пример. устройство приема кредитных карт для iPhone. О мобильных платежах аналитики писали давно.
Идеи от конкурентов.
Можно реализовать их идею лучше, чем они.
Хорошо, если сам хочешь найти приложение, чтобы самому использовать, но не удается этого сделать.
Пример. Shoping list. Нет ничего подходящего.
В AppStore пишут отзывы как правило те, у кого что-то не работает. У кого работает – не пишут.
Идеи от обратной связи пользователей.
Либо что-то не работает, либо пожелание в улучшении функциональности, либо новая функциональность.
Идеи от обзоров.
Хорошо, чтобы нанять кого-то, чтобы написал обзор – он конечно же получится хороший.
Нужно попросить, чтобы сделал какую-то авантюру, заинтересовать другие издательства, которые поругают бесплатно.
Что убивает идею:
* UI & U Experience – пользователь может просто устать.
* Нужно либо все свои элементы использовать, либо все стандарные – не перемешивать, пугает пользователя. Пример: системная кнопка в игрушке.
* пренебрежение Apple Mobile HIG. Есть инструкции для правильного написания интерфейса – не нужно ими пренебрегать.
* графика.
* функциональность: ненужная или плохо реализованная функциональность, удаление присутствующей функциональности. Если 2% пользуется фичей и вы ее убрали, то эти 2% сгенерят 90% негативных отзывов.
Пример: не делать маленькие кнопки, чтобы пользователь не мог на них попасть.
Делать идею уникальной:
* знайте аудиторию.
* посещайте места, связанные с вашей идеей.
* учитесь замечать больше.
* расширяйте горизонты (как то уж сильно сжато отметил, даже сам не понял).
Решение по реализации идеи:
* коммерческий успех
* соответствие ожиданиям рынка и пользователя.
* время реализации.
* лучше потерять хорошую идею, чем реализовать плохую.
Евгений Веселов в недавнем прошлом Program Manager Magento

“Я не несу яиц, но их качество определяю лучше любой курицы”

Фича: зарождение-юношество-зрелость-смерть.
Рабочий софт и продаваемый – это совершенно разные вещи
Для фич действует принцип Парето.
При больших и неочевидных фичах возможно долгое “рождение” – уточнение, лучшее понимание фичи.
Если продукт не меняется, то продукт умирает.
Пример. Майкрософт Офис – меняется интерфейс, но редактирование остается практически без изменений.
Подводные камни. Осторожно:
* Если у фичи очень много “родителей”, различных мнений, и в конце концов очень долго принимается решение и постоянно идут запросы на изменение.
* Общение с компанией, которая к примеру может прекратить поддержку того, от чего вы зависите.
* Зависимость от других продуктов в компании.
Чем раньше продукт начинает продаваться, тем лучше.
“Если вы зависите от каких то SaaS то у них в последний день обязательно что-то сломается :)”
Валерий Галянт. Сооснователь системы управления проектами Worksection.com
Коммуникация с пользователями.
Источник вдохновения – BaseCamp.
Использовали BaseCamp, стало не хватать, вдохновились сделать свою систему. Первые клиенты – это клиенты других сервисов компании.
Сделали под себя на русском языке – в 2009 году.
Развивались на основе обзоров по похожим системам.
Выбирали путем голосовая – было мало людей в компании, в основном фаундеры (четыре).
Позже появилось достаточно откликов от пользователей.
Появился список идей, которые можно реализовать.
Приоритет повышался, если клиент желал иметь фичу (у клиента учитывалась крутость (нравится лично, сайт), лояльность, тариф).
Важно – техническая поддержка.
Основные: хелп, юридическая, оплата, багфиксы.
Дополнительно: предложение клиента сверялось с векторами развития, определенными внутри компании.
Когда дело доходило до реализации идеи, то уже имелось довольно много отзывов и позволяло правильно реализовать фичу.
Если фича не совпадает с векторами развития, то идея сохранялась в списке пожеланий.
Клиент получает письмо с благодарностью и, возможно, сроки, когда фича будет реализована.
Потом клиентам сообщалось, когда фича становится доступной (Удивляло, почему этого никто не делает – первый раз услышал о реализации).
Есть единичные доработки важного клиента.
Позже либо фича становится всем, либо все таки остается для одного клиента – пока проблем с поддержкой не возникало.
Перекладывание Project Managment на клиентов.
По потенциальным фичам вопросы клиентам:
1. Вопросы по правам и ролям.
2. Преложения по улучшению.
3. Отладка ошибок.
Реализуется самый простой вариант фичи и потом на протяжении недели собираются фичи. Как правило получают отзывы от лояльных клиентов и больших, когда не понятна их специфика.
В фидбеке кроме проблем добавили вопрос: оставьте свое пожелание.
Особенно хорошо, когда клиенты видят что их пожелания реализовываются, и тогда отзывов оставляют все больше и больше.
Решили писать продукт для себя ради идеи. Деньги пришли сами.
Продукт уже 2 года на самоокупаемости.
По статистике клиенты, которые генерируют очень много идей, как правило высказывают то, что в конечном счете все таки реализуется, хотя и реализуется далеко не все их идеи.
В компании 4 основателя и разработчика и 3 человека саппорт, бухгалтерия и пиар отдел.
Релизы – 1 раз в месяц или 2, маленькие доработки – несколько раз в месяц (SaaS продукт)
Deployment делать просто, поскольку SaaS.