Сейчас читает 6 книг списком обложками

  • The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses

    Eric Ries

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

    Пример №1
    Zappos – мировой лидер по продаже обуви он-лайн с годовым оборотом, превосходящим миллиард долларов.
    Он начал с проверки гипотезы о том, что пользователи действительно готовы покупать обувь в он-лайне. Он просто обошел местные обувные магазины и попросил разрешения сфотографировать продающуюся в них обувь и разместить их на своем простеньком сайте под обещание того, что если кто-нибудь закажет что-то, то он принесет этот заказ продавцу и тот сможет поставить эту обувь конечному покупателю даже без выплаты Нику комиссионных.
    Таким образом, Ник смог понять сразу несколько вещей:

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

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

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

    Пример №3
    Food on the Table – это сервис, который еженедельно автоматически генерит для вас меню на всю неделю и список покупок, которые необходимо сделать, чтобы приготовить эту еду.
    Но свою жизнь Food on Table начал с одного-единственного пользователя и одного-единственного продуктового магазина. Как они выбирали, с какого магазина начинать? Никак – пока они не нашли своего первого пользователя. Как они составляли начальную базу рецептов? Никак – пока первый пользователь не начал планирование своего первого еженедельного меню. По сути своей компания начала обслуживание своего первого пользователя без написания единой строчки программного кода, без единого подписанного соглашения о партнерстве ни с одной продуктовой сетью и без единого нанятого профессионального повара.
    Этот первый клиент получил личное обслуживание. Он пользовался сервисом не с помощью сайта, еженедельно его лично посещали основатели проекта, которые до этого изучали и цены и наличие продуктов в ближайшем магазине. Они приносили потребителю пакет с продуктами и список специально подготовленных для него рецептов, а уносили с собой чек на $9.95.
    Но на самом деле они делали огромный прогресс – каждую неделю они понимали все больше и больше о том, что должно быть в их продукте, чтобы он смог добиться успеха. Каждый новый клиент делал привлечение следующего клиента более простой задачей. Каждый клиент получал личное обслуживание, и это продолжалось до тех пор, когда издержки на личное общение не стали серьезно увеличиваться. Только после этого основатели начали тратить деньги на автоматизацию процесса, они автоматизировали процесс шаг за шагом, на каждом этапе получая возможность обрабатывать все больше и больше клиентов. Так и достигалось масштабирование. Сейчас Food on Table – это сервис, который работает в масштабах целой страны.

    Вот, новый поворот:
    Если результаты экспериментов показывают, что принципиальные допущения, сколько мы не бились, так и не нашли подтверждения в реальности – надо не боятся, а пересматривать стратегию развития:
    Отдельное свойство продукта может стать самостоятельным продуктом. А все остальные свойства оказываются никому не нужными.
    Сам продукт оказывается только частью процесса, который нужно автоматизировать. Надо создать новый продукт, в которым старый продукт станет одним из свойств.
    Оказывается, что продукт востребован, но только другой аудиторией, на которую не планировалось ориентироваться изначально. Сам продукт сохраняется, но происходит перефокусировка, в том числе и маркетинговая, на новую категорию потребителей.
    Оказывается, что у пользователей есть проблема, но вовсе не та, которую мы собирались решать изначально. Целевая аудитория сохраняется, но изменяется свойства продукта, так как он теперь предназначен для решения немного другой проблемы.
    Платформа становится продуктом или наоборот. Часто бывает, что вместо того, чтобы разрабатывать универсальную платформу для создания некой категории приложений, в реальности необходимо создать всего одно максимально нужное потребителю приложение – так платформа становится продуктом. Бывает и обратная ситуация – становится понятно, что вместо одного продукта необходима целая линейка кастомизируемых приложений, что приводит к тому, что продукт становится платформой.
    Замена высокомаржинальной штучной модели продаж на низкомаржинальную и массовую, и наоборот. Это обычно означает смену в приоритетах по объему охвата целевой аудитории – либо узкая платежеспособная, либо широкая, но менее платежеспособная.
    Изменяется понимании того, что является реальной ценностью продукта. Сам продукт сохраняется, но изменяется фокусировка в позиционировании продукта, чаще всего влечет изменение модели монетизации.
    Именуется понимание того, каким способом продукт может расти. Чаще всего вызывает изменение в понимании ценности продукта и, как следствие, способа его монетизации.
    Изменяется понимание того, по каким каналам сбыта продукт должен распространяться. Чаще всего заключается в выборе между использованием прямых продаж, поиском и использованием существующих партнерских сетей или построением собственной дилерской сети.
  • Crossing the Chasm

    Geoffrey A. Moore

    Практически единственная книга по product management:
    по совету Лёши Корсуна и отсюда http://crankypm.com/recommended_reviewed_products/books-product-management

    Резюме:
    http://www.parkerhill.com/Summary%20of%20Crossing%20the%20Chasm.pdf

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

    Новаторы, ранние последователи, раннее большинство, позднее большинство, "увальни"

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

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

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

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

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

    Ранние последователи обычно приходят с заказом к вам сами, как правило они основываются на мнении первых гиков.

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

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

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

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

    Один — поражение первой цели, захват плацдарма, преодоление пропасти.
  • Cockburn

    "Writing Effective Use Cases" Cockburn
    "GUIs with Glue" Hohmann
    "Improving Software Organizations" Mathiassen
    "Surving Object-Oriented Projects" Cockburn
    "CrystalClear" Cockburn
    "Agile Software Development Ecologies"
  • Agile Retrospectives: Making Good Teams Great

    Esther Derby, Diana Larsen

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


    Dana let the group know the purpose, focus, and time allowed for the
    retrospective

    1. Set the stage.
    2. Gather data.
    3. Generate insights.
    4. Decide what to do.
    5. Close the retrospective.

    1.
    ask everyone in the room to speak
    established the timebox, goal, and approach and set of values
    read Working Agreements ("phone on silence" or "Everyone participates",..)

    2.
    Start with the hard data
    created a timeline by posting cards to represent what happened during
    their thirty-day iteration
    structured way for people to talk about feelings makes
    Ask the team to scan the data you've gathered and
    comment on patterns, shifts, and surprises.

    3.
    examine the conditions, interactions, and patterns that contributed to
    their success. Investigate breakdowns and de?-
    ciencies. Look for risks and unexpected events or outcomes.

    4.
    At this point, the team has a list of potential experiments and
    improvements. Now is the time to pick the top items (usually no more
    than one or two for an iteration) and plan what to do.
    Plan a break--even if it's only lunch--between the retrospective and the
    planning session.
    be sure that people sign up and commit to tasks.

    5.
    Decide how to document the experience and plan for follow-up.
    appreciation for the hard work everyone
    a few minutes to perform a retrospective on the retrospective "Inspect
    and adapt"

    All:
    * Understand different points of view.
    * Follow a natural order of thinking.
    * Take a comprehensive view of the team's current methods and
    practices.
    * Allow the discussion to go where it needs to go, rather than
    predetermining the outcome.
    * Leave the retrospective with concrete action and experiments for
    the next iteration

    Делать ротацию роли ведущего.
    Иногда стоит менять комнату для встреч - чтобы всё не превращалось в рутину

    Set the stage (5%) 6 minutes
    Gather data (30-50%) 40 minutes
    Generate insights (20-30%) 25 minutes
    Decide what to do (15-20%) 20 minutes
    Close the retrospective (10%) 12 minutes
    Shuffle time (10-15%) 17 minutes
    Total (100%) 120 minutes