Создание стратегии

Введение в продуктовую стратегию

Important

“Any progress starts with a mission, a vision.” (C) Arnold Schwarzenegger

Info

A business strategy in its simplest form is a tool for helping you achieve your business goals.

A business strategy provides the guiding principles for many organizational decisions, such as hiring new employees, or developing new products. And helps you to define the methods and tactics you need to take within your company.

In essence, a business strategy is an organizational master plan. This plan is what the management of a company develops and implements to **achieve their strategic goals.**Essentially, a business plan is a long-term sketch of the desired strategic destination for a company.

This long-term sketch will contain an outline of the strategic, as well as tactical decisions a company must take to reach its overall objectives. This business strategy will then act as a central framework for management.

Once this framework is defined, management must live and breathe it. It helps the different departments within a business work together, ensuring that all departmental decisions support the overall direction of the organization. This helps to avoid working in silos, or different teams pulling in opposite directions.

---

Strategy as we’ve identified refers to the long-term goal or roadmap for an organization, and how it plans to reach them. Or, the path the organization will take towards its goals.

Conversely, tactics refer to the specific set of actions taken to reach the organizational goals, or strategy.

---

For example, a company may have a strategic vision to become the cheapest supplier of a product in the market. This requires their managers to negotiate with suppliers, reducing purchase costs. This, is a tactical move taken towards achieving the set strategy.

“Good tactics can save even the worst strategy. Bad tactics will destroy even the best strategy.” – General George S. Patton Jr.

Product vision vs strategy

The product vision describes the future we are trying to create, typically somewhere between 2 and 5 years out.  For hardware or device-centric companies it’s usually 5-10 years out.  This is not in any sense a spec; it’s really a persuasive piece.  It might be in the form of a story board, or a narrative like a white paper, or a prototype (referred to as a “visiontype”).  It’s primary purpose is to communicate this vision and inspire the teams (and investors and partners) to want to help make this vision a reality.

When done well, the product vision is one of our most effective recruiting tools, and it serves to motivate the people on your teams to come to work every day.  Strong technology people are drawn to an inspiring vision; they want to work on something meaningful.

---

One of the most basic of all product lessons learned is that trying to please everybody will almost certainly please nobody.   So the last thing we should do is embark on a ginormous, multi-year effort to create a release that tries to deliver on the product vision.  That would truly be the antithesis of the concept of minimum viable product.

Whatever the goal is, your strategy is how you’re planning to go about accomplishing that goal.  Strategy doesn’t cover the details; those are the tactics we’ll use to achieve the goal. Strategy is the overall approach, and the rationale for that approach.

While there’s many forms of strategy, what we care about here is product strategy.  Which in short means: how do we make the product vision a reality, while meeting the needs of the company as we go?

Product strategy breaks down into four steps:

230. The first is to be willing to make tough choices on what’s really important;
231. The second involves generating, identifying and leveraging insights; 
232. The third involves converting insights into action;
233. And the fourth involves active management without resorting to micro-management.

---

Сравнение видения со стратегией, roadmap, миссией

Продуктовое видение: 
это большая мечта о том, чем ваш продукт должен стать в будущем и как он поможет людям.

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

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

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

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

---

Make the competition irrelevant: BLUE OCEAN STRATEGY by W.C. Kim and R. Mauborgne

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

Предприятиям предлагают следовать “Рамкам четырех действий”, которые включают в себя: 

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

Авторы также предлагают использовать схему “Шесть путей” для выявления неиспользованных рыночных возможностей, которая включает в себя:

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

”Good strategy Bad strategy”

Краткое содержание:
Хорошая стратегия необходима для успеха бизнеса. 

Хорошая стратегия включает в себя: 

• Определение критических факторов в ситуации. 
• Разработка руководящей политики для устранения этих факторов. 
• Принятие последовательных мер по реализации этой политики. 
• Осознание своих ресурсов и возможностей. 
• Сильное понимание своей отрасли и окружающей среды. 

Плохая стратегия часто является результатом: 

• Отсутствия тщательного рассмотрения на каждом этапе процесса стратегического планирования. 
• Отсутствие согласованности между структурой, политикой и действиями.
• Ориентация на краткосрочные цели, а не на долгосрочную устойчивость.

Примерами хорошей стратегии в действии являются сосредоточенность Nvidia на улучшении графики для ПК и использование компанией Amazon данных о клиентах для обоснования бизнес-решений.

Примерами плохой стратегии являются пренебрежение Kmart к конкуренции и неспособность Walmart адаптироваться к меняющимся условиям рынка в Китае.

Product launch strategy: How to launch a new product in 5 Steps

A product launch strategy is a planned effort to launch a new product in a market. The goal of most businesses is to launch something and get as much growth and traction as quickly as possible. Many steps, actions, and people are involved in a project launch process.

4 common reasons product launches fail

234. Word-of-mouth is not enough. a good way to evaluate your growth is to take away all other forms of your marketing strategy — this means emails, paid ads, anything that promotes your product — and see whether your company continues to grow. If churn outpaces growth, then WOM isn’t strong enough to support your business on its own. With WOM, growth might be slow over time, but this sets the stage for accelerated growth later on because it builds such a strong foundation. - What brands don’t realize is that Step 2 of the loop, Greatly Exceeds Expectations, can indeed be controlled. Brian explained that, at this point, you control “the audience coming in and what the audience experience is.”
235. Validating product and feature hypothesis slows down. An important part of your launch plan is validating the product and feature quickly. 1. Qualitative signals. Like Net Promoter Score (NPS) and Customer Satisfaction Score (CSAT) can be corrupted when you get negative feedback from users who are not meant to test the first version of your product or feature. 2. Quantitative signalsю Like retention curves show how well you’re able to retain users over time and deliver on the promised value. Without segmenting your audience, this, too, can result in a slow validation process.
236. Too much communication. Users have only so much attention to give your product. It’s in your best interest to be protective of their experiences and avoid bombarding them with irrelevant messages that test their patience. > “it’s much harder to fill the fuel tank than it is to drain it in today’s environment, where all of our customers are getting overwhelmed with messages.”
237. Only envisioning the short-term. The goal for launches is to create a long-term, sustainable growth strategy. Reforge thinks about their sustainable growth strategy as a qualitative growth model grounded in strong communication.

How to launch a product in 5 steps

• Define your scope
• Access who needs the product
• Filter your list for the best users
• Use a success signal
• Leverage your signals for the next user group

According to Michael Porter, a good strategy should pass the following 5 tests1

238. Unique value proposition Ask yourself: - Who are the customers you are going to serve? What is their typical age, sex, education, race, religion, place of residence, and even sexual orientation? Do they have children? Do they use the internet? Are they overweight? Where do they spend their time? What are their plans for the future? What do they dream about? What are they afraid of? What motivates them? What is important to them? - What are the needs, problems, and desires you want to solve? At the heart of any successful product which has remained in the market is solving an urgent, pressing problem. - At which relative price are you going to offer your products? For example, for IKEA, it is a low price, and for Apple, it’s a premium price.
239. A tailored value chain. A set of distinct activities that you perform in creating, producing, marketing, and delivering your product or service.
240. Tradeoffs. Tradeoffs define what to do but also what NOT to do. Tradeoffs create focus, amplify the value and make the strategy hard to copy for others without sacrificing their existing businesses.
241. Fit. Different elements in the value chain and the value proposition should reinforce each other. A good strategy is like a net. The more reinforcements, the stronger and more difficult the strategy is to copy.
242. Continuity over time. Companies can change too slowly, but they can also change too fast. Strategy is a bet that the core value proposition will not change much over time.

Value proposition Canvas

1. Справа— Клиенты: - Задачи: Что клиенты пытаются сделать? Например, если у вас приложение для фитнеса, их задача — поддерживать себя в форме. - Боли: С какими проблемами они сталкиваются? Возможно, им сложно найти время для тренировок. - Выгоды: Чего они хотят достичь? Например, они хотят чувствовать себя здоровее.

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

Как читать Value proposition Canvas

Business Model Canvas

55 Популярных бизнес моделей

Многие истории успеха начинались с инновационной бизнес-модели, а не с превосходного продукта:

• Amazon - стало крупнейшим интернет-магазином в мире, не имея ни одного традиционного магазина

• Apple является крупнейшим продавцом музыки, хотя не владеет не одной студией и не продает компакт-диски

• Skype - крупнейший телекоммуникационный провайдер в мире, хотя и не имеет собственной сетевой инфраструктуры

• Netflix - вдохнула новую жизнь в видеопрокат, не имея ни одного физического магазина

• Starbucks - крупнейшая в мире сеть кофеен, продающая обычный кофе по премиум ценам

90% инновационных бизнес-моделей есть результат комбинирования 55 базовых шаблонов

Стратегии генерирования новых бизнес-идей

Перенос

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

Комбинирование

Комбинирование: перенос и объединение двух бизнес-моделей. Особо передовые компании могут даже объединять три бизнес-модели одновременно (например, Nestlé использует для Nespresso шаблоны «Бритва и лезвие», «Привязка к продавцу» и «Прямая продажа»). Главное преимущество: комплексная модель снижает вероятность ее копирования конкурентами. Главная трудность: планирование и реализация сопряжены с чрезвычайными сложностями

Рычаг

Компания использует успешную бизнес-модель для другой продуктовой линейки (например, от Nestlé Nespresso к Nestlé Special.T и Nestlé BabyNes). Такое под силу только истинным новаторам. Главное преимущество: возможность опираться на собственный опыт и объединенные усилия компании; возможность управлять рисками. Главная трудность: сохранение баланса между переменами и стабильностью.

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

Типичные ошибки при инновации бизнес-модели

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

• Мышление «я умный – все дураки», продавливание своей идеи
• Будьте внимательны ко всем идеям от всех участников процесса, старайтесь быть максимально объективным и не допускать в процесс “личного отношения”.
• Оглядываться на конкурентов
• Формальное заполнение
• Отсутствие критической оценки
• Отсутствие альтернатив
• Отсутствие осознанности, жизнь в «волшебном мире»

Business model navigator

Онтология Бизнес-моделей

Основные бизнес модели для стартапов

Основные способы распространенияПО

• Локальное(on-premise) программное обеспечение устанавливается и запускается в рамках внутренней инфраструктуры клиента. 
• Облачное(cloud) программное обеспечение поставляется через интернет и доступно через веб-браузер.
• Гибридное программное обеспечение сочетает в себе элементы как локального, так и облачного распространения.

Потоки доходов для программных продуктов могут включать: 

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

Некоторые возможные источники дохода для компаний-разработчиков программного обеспечения включают: 

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

Бизнес-модели состоят из трех основных элементов: модели создания ценности, модели прибыли и логики бизнеса. 

• Модель создания ценности предполагает определение целевых клиентов и предложения, которое создаст для них ценность.
• Модель прибыли - определение источников дохода и структуры затрат.
• Логика бизнеса предполагает достижение целей прибыли и роста

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

Lean Canvas

Lean Canvas — это адаптация Business Model Canvas, специально разработанная для стартапов и новых бизнес-проектов.

Отличия Business model canvas и Lean canvas

244. **Целевая аудитория:

- Business Model Canvas разработан для широкого круга бизнесов, включая устоявшиеся компании и крупные организации. 

- Lean Canvas более ориентирован на стартапы и новые бизнес-проекты, где требуется большая гибкость и скорость.  
            

245. **Фокус:

- Business Model Canvas сосредотачивается на описании всех аспектов бизнеса, включая ключевых партнеров, действия, ресурсы, клиентские отношения и каналы распространения. 
- Lean Canvas фокусируется на проблемах и решениях, а также на ключевых метриках, структуре затрат и потоках доходов, что особенно актуально для начинающих предприятий.  
          

246. **Подход к разработке:

- Business Model Canvas подходит для более всестороннего планирования и долгосрочного стратегирования. 
- Lean Canvas спроектирован для быстрого тестирования идеи и её адаптации на основе обратной связи, что идеально подходит для начальных стадий запуска стартапа.  
      

247. **Структура:

- Business Model Canvas включает более широкие категории, такие как ключевые партнеры и ключевые действия. 
- Lean Canvas добавляет элементы, связанные с рисками и выгодами, включая неустранимые проблемы и конкурентное преимущество.

Roadmap

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

Why do you need a roadmap?

Here are a few reasons to start building a product roadmap.

248. Strategic alignment

It ensures everyone’s paddling in the same direction.

• Sales teams won’t promise some features that PMs aren’t even aware of
• Marketing won’t build campaigns for features that aren’t in the works
• Design won’t create wireframes for low-priority features

249. Stakeholder communication

A roadmap is like a translator between you and your key stakeholders. There will always be people who want certain features shipped yesterday. How can you effectively communicate your current priorities? With a product roadmap, of course!

250.  Resource planning

Knowing what you’re building will help determine which resources you need. You’ll also know when you need them, in what quantities, and how crucial they are. Planning simplifies everything! If you plan properly, you won’t end up with too many or too few resources.

Roadmap Templates

Technology Roadmap - navigate in tech projects

Software Development Roadmap - when’s the next update?

Business Roadmap - zoom out to the bigger picture

Marketing Roadmap - to spread the word about your products

Project Roadmap - break down complex projects

Идеальный Roadmap продукта

• Waterfall роадмап продукта был эффективен ранее, но с ускоряющимися изменениями всё больше и больше становится популярным Agile подход

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

Основные компоненты роадмапа продукта:

Цели

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

Релизы

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

«Эпик» (Epic)

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

Функции

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

Минимально жизнеспособный продукт (MVP)

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

Пользовательские истории

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

Временная шкала

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

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

• Определить цель проекта - Когда вы думаете о создании дорожной карты продукта, вы должны очень четко определить свою цель. Здесь может быть несколько вариантов в зависимости от того, для чего вы строите дорожную карту. Например, это новый продукт или доработка существующего?
• Держите свою дорожную карту четкой и лаконичной - Когда все члены вашей команды стремятся к одной цели, разработка продукта идет более гладко. Но это происходит только в том случае, если вся команда понимает продукт и свою роль в его разработке. Важно, чтобы ваша дорожная карта была простой и понятной. Возможно, вы думаете, что сложный план действий будет подробно описывать каждый шаг на пути к успеху, однако такой подход приведет лишь к недопониманию и срыву сроков.
• Составьте карту пользовательских историй - Составление пользовательских историй — это подход к сбору требований сверху вниз, который представлен в виде дерева. Подход, ориентированный на пользователя, помогает определить требования с точки зрения пользователя, например, покупателя, продавца, администратора и т.д. Затем карта структурируется как «Пользователь > Цели > Пути пользователя > Действия > Истории».
• Определите особенности и приоритеты продукта - Построение дорожной карты продукта включает в себя учет всех функций, которые могут быть связаны с основным продуктом. Например, при создании нового SaaS-продукта связанными функциями могут быть «новая кампания» и «клонирование новой кампании».
• Разделите задачи на «эпики» - Далее следует определиться с графиком и разбить задачи на более мелкие, выполнимые эпизоды. Составление окончательной дорожной карты на листе включает в себя объединение всех «эпиков» в рамках определенного графика.
• Создайте доску видения - Следующим шагом будет размещение всего на доске видения, доступной для всех заинтересованных сторон. Это позволит всем участникам отслеживать прогресс в разработке продукта. «Эпики» или даже функции могут быть разделены для каждого спринта в зависимости от имеющихся ресурсов. При гибком подходе к составлению дорожной карты продукта тестирование происходит на каждом «эпическом» уровне и не нужно ждать завершения работы над всем продуктом.

Приоритизация гипотез

Зачем вообще приоритизировать бэклог? Почему нельзя все делать планомерно? Все очень просто.

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

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

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

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

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

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

Способы приоритизации

251. ROI  Работает она очень просто: берем то, сколько мы заработаем с фичи, делим на то, сколько она нам будет стоить, и получаем конкретный коэффициент ROI, то есть окупаемость инвестиций.

В чем плюс этого способа? Если для вашей компании деньги — это самое главное и ваша стратегия — это «не закрыться завтра», у вас нет финансирования и нечем его привлечь, то этот способ вам точно подойдет. Но если вы имеете какие-то цели, выходящие за рамки «заработать и не закрыться», будь то увеличение доли на рынке, больший охват, какие-то PR-активности или глобальная цель по изменению всего рынка, то ROI как инструмент приоритизации для вас неактуален.

252. ICE “Impact” - это потенциальное влияние фичи “Effort” - это сколько усилий надо приложить, чтобы осуществить эту фичу “Confidence” — это вера в конкретную фичу.

Обычно ICE используют с четырехбалльной, пятибалльной или десятибалльной шкалой. Что происходит при его использовании? Берется какая-то идея и рассматриваются следующие показатели:  

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

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

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

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

 В зависимости от этого, выявляются 4 вида фичей:
- **Минимальные**: Если вы пользуетесь Google Docs, то основной функцией для вас будет написание текста и вряд ли она вызовет у вас какое-то восхищение, вы ожидаете ее по умолчанию. При этом не делать этот функционал нельзя, потому что он представляет собой базовые ожидания пользователя от продукта.
- **Обычные**: это функции, являющиеся основным инструментом выбора для пользователя. Если мы говорим о тех же самых Google Docs, то к этим функциям можно отнести объем хранимых документов на Диске, работа функции автосохранения, разделение доступа к документу с другими людьми и тд. 
- **Одномерные функции**. Некоторые функции продукта ведут себя так, как мы можем интуитивно предполагать, что Satisfaction работает: чем больше мы предоставляем этих функций, тем более удовлетворены наши клиенты.
- **Неважные функции (Indifferent)**. Естественно, есть и функции, к которым мы относимся **безразлично**. Это те, присутствие которых (или их отсутствие) не имеют реального значения в нашей реакции на продукт.

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

Первый и второй вопросы анкеты соответственно называются функциональными и дисфункциональными формами. Каждому «как вы себя чувствуете, если у вас была / не была эта функция», возможные ответы:

- Мне она нравится
- Я ожидаю ее
- Я нейтрален
- Я могу это терпеть
- Мне это не нравится

Для каждой пары ответов мы используем таблицу для определения категории, в которую респонденты попадают, что позволяет нам понять, как он или она чувствует эту функцию.
![[assets/Pasted image 20250209225646.png]]
Из отдельных ответов и итоговых категорий вы можете перейти на два уровня анализа:

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

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

Как правило, функции должны быть приоритизированы, чтобы соблюдался следующий порядок: **Обязательные** > **Одномерные** > **Привлекательные** > **Неважные**.

255. Развесовка приоритетов.

Пройдемся по весам:
- прибыли отведено 60% приоритета - но при этом есть довольно много блокеров(10%), то есть существуют критически важные бизнес-процессы, которые нельзя нарушать. Это характерная ситуация для компаний с большим количеством сложных процессов, которые нужно учитывать
- приоритеты компании - 20% -  у этой компании есть сильная стратегия, потому здесь уделено большое внимание приоритетам компании и отмечено, что вероятность успеха тоже имеет большое значение.
- При этом, так как эта компания достаточно сильно развита, реализовывать эксперименты не так-то просто: это не маленький стартап, где можно накидать какие-то изменения буквально за день, поэтому целых 40 процентов уходит на проведение эксперимента(20%) и на реализацию(20%).
- Зеленым цветом на картинке выделены приоритеты. По каждому из них мы выставляем вес в зависимости от стратегии и целей компании.
- По сути, в «часах» мы заполняем, сколько времени у нас уходит на эксперимент и реализацию, сколько в трудозатратах. Приведем пример того, как это можно делать: у нас есть средняя стоимость часа работы сотрудника с учетом дизайна, разработки, проджект-менеджмента, тестирования и так далее, и есть примерное представление о соотношении этих часов, то есть нужно брать среднее с поправкой на то, что на тестирование понадобится меньше времени, чем на разработку и на дизайн. Таким образом можно получить примерную стоимость часа и можно оценить, сколько часов займет та или иная задача, пусть и очень приблизительно.
- То, что стоит в столбце «авто» — это, по сути, тоже разбалловка, составляемая, исходя из содержимого столбца «часы».
- Почему важно разделять эксперимент и реализацию? Иногда эксперимент может пройти очень просто и быстро, буквально за две-три недели, но реализация при этом имеет вероятность затянуться надолго.
	>Если взять пример платформы онлайн-образования, то какая-то новая практика в качестве эксперимента может быть внедрена быстро и дать хорошие результаты, но попытка распространить ее на всех преподавателей грозит вылиться в минимум полгода работы. Или, например, предположим, что вы делаете новый вариант главной страницы, и в этом случае эксперимент, наоборот, будет самым длинным и дорогим из процессов — верстка, тесты и так далее, а вот реализовать протестированное — вопрос пятнадцати минут работы разработчика.

Important

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

Допустим, в какой-то момент ваша компания настолько отмасштабировалась, что все процессы внутри нее стали невероятно сложными. Это значит, что, прежде всего, нужно делать фичи, решающие какие-то блокирующие проблемы. В таком случае можно, например, поднять приоритет столбца «Блокер» до 40 процентов (разумеется, в сумме все приоритеты не должны давать больше 100 процентов). Или, например, вы знаете, что у вашей компании проведение экспериментов и реализация почти не занимают ресурсов — допустим, у вас все сделано на Tilda и собрать решение вы можете за несколько минут. Это значит, что вы можете «скрутить» приоритеты у правой части, отвечающей за соответствующие процессы, и не обращать на нее внимания, а вес ценности, наоборот, увеличить.

6. Оценка возможностей(Opportunity Scoring). Фреймворк основываются на правиле, что люди покупают продукты и услуги, чтобы выполнить определенную работу. То есть, это ожидаемый результат. Концепция jobs-to-be-done Клейтона Кристенсена разделяет эту линию мышления, и это была горячая тема, которая собрала много внимания в последнее время.

   

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

   Благодаря пользовательским исследованиям и другим методам мы можем составить список желаемых результатов для продукта. Затем мы должны попросить клиентов оценить каждый результат, насколько он важен для них, и степень удовлетворения продуктом в масштабе от 1 до 10. Учитывая это, Ульвик предлагает показатель возможностей, который определяется по этой формуле:

   $$Importance+max(Importance-Satisfaction,0)=Opportunity$$

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

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

256. Story Mapping. Основная идея Карт Историй заключается в том, что одностраничный бэклог продуктов — это ужасный способ организовать и расставить приоритеты в работе, которая должна быть выполнена. Необходима более глубокая структура.

1. Существует горизонтальная ось, представляющая **последовательность использования**;

- Истории пользователей (или задачи/таски) размещаются вдоль этой оси в последовательности, в которой они выполняются пользователем;

2. Вертикальная ось означает **критичность**;

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

1. Группы связанных историй пользователей могут быть сгруппированы как « _Activities_» (Действия):

- Создайте вертикальную линию для разделения одних групп историй от других;
- Например, к Действиям можно отнести «управлением электронной почтой», при этом «отправить электронное письмо на один или несколько адресов» является пользовательской задачей;
- Действия расположены над вертикальной осью и не имеют какой-либо последовательности использования, они просто есть — эти действия составляют основные атрибуты продукта и не могут быть приоритизированы (подумайте, вы же не можете определить приоритет двигателя автомобиля по сравнению с его колесами)
![[assets/Pasted image 20250209231819.png]]
- Чтобы определить выпуски, проведите горизонтальные линии вдоль карты, выбрав истории с эквивалентными уровнями критичности;
- Это приводит к полным сквозным версиям продукта и, как следствие, к более быстрой доставке и проверке на рынке (что важно на этапе [MVP](https://en.wikipedia.org/wiki/Minimum_viable_product)).

![[assets/Pasted image 20250209231855.png]]

257. MoSCoW - Этот метод предлагает быстрое и простое решение для определения приоритетов. Проблема связана с отсутствием классификации по категориям. Например, как мы можем узнать, какие требования ДОЛЖНЫ быть или МОГУТ быть более важными, чем другие? Из-за этого ограничения метод MoSCoW, вероятно, лучше подходит для внутренних проектов, а не для продуктов со большим количеством клиентов — общение с несколькими заинтересованными сторонами в тонкостях приоритизации всегда будет проще, чем более крупный контакт с конечными клиентами.

• Must have (Должно быть) — они имеют решающее значение и должны быть включены в продукт. Если даже одно требование не включено, релиз считается провальным. Они могут быть опущены, если между заинтересованными сторонами будет достигнуто согласие.
• Should have (Надо бы иметь) — эти требования важны, но не имеют решающего значения для выпуска. Они являются первым уровнем «Nice to have» (Хорошо бы иметь) и, как правило, разделяют важность требований “Должно быть”, не будучи настолько чувствительными к времени.
• Could have (Могут быть) — эти требования желательны, но не нужны для выпуска. Обычно это недорогие усовершенствования продукта. Из-за их меньшей важности они являются вторым уровнем функций «Nice to have».
• Won’t have (Не будут) — они считаются наименее критичными или даже не соответствуют стратегии продукта. Они должны быть отброшены или пересмотрены для будущих выпусков.

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

Вот [как это работает](https://msdn.microsoft.com/en-us/library/hh765981\(v=vs.120\).aspx#Prune):

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

Отсюда вы можете извлечь ценные данные. Является ли дерево сбалансированным? Возрастают ли непропорционально отдельные области? Или в настоящее время растут слаборазвитые области?

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

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

Проблема в том, что **доллар сегодня стоит больше, чем доллар завтра**. Инициатива, которая возвращает $ 10K, $ 20K, $ 30K за три квартала, менее ценна, чем такая же с одинаковой прибылью, но в обратном порядке. Необходимы более сложные методы сравнения. Мы рассмотрим методы, позволяющие ответить на эти вопросы:
- «Сколько из сегодняшних денег у нас будет после N-го периода времени, если мы инвестируем в этот проект?”
- «Какова отдача от этого проекта в процентном выражении?»
- «Сколько времени потребуется, чтобы вернуть эти инвестиции?»

	**Чистая приведенная стоимость (NPV)** - Сколько денег нужно будет положить в банк, чтобы к концу 1 года у нас было бы 10 долларов? Это то, что называется [текущей (приведенной) стоимостью](https://ru.wikipedia.org/wiki/%D0%94%D0%B8%D1%81%D0%BA%D0%BE%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D0%BE%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D1%8C) некоторой суммы, и это зависит от процентной ставки, которую банк предоставляет
$$ PV - C * (1+i)^{-t}$$
	C — денежный поток, i — процентная ставка и t — количество периодов дисконтирования между настоящим и временем C

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

Запуск продукта приводит к последовательности денежных потоков в течение периодов времени (например, месяцев или кварталов). **Каждый из них должен быть дисконтирован до их текущей стоимости (PV). Чистая приведенная стоимость представляет собой сумму этих статей за определенный период времени и определяется по следующей формуле:**

$NPV={\sum }_{i=0}^{n}C\ast (1+i)\ast -t$ Внутренняя норма доходности (IRR) - это показатель, отражающий доходность проекта в процентном выражении. Другими словами, это показывает, как быстро инвестиции будут расти в цене. IRR определяется как процентная ставка, при которой NPV равен нулю. Из этого значения вы получаете возврат проекта и можете сравнить его с другими. Однако это не должно учитываться отдельно для принятия решений, поскольку общая NPV или инвестиционное время, в течении которого оно принимается, могут быть важными факторами принятия решений. Дисконтированный срок окупаемости. сколько времени потребуется для возврата инвестиций. Для этого мы рассмотрим текущую суммы дисконтированных денежных потоков. Когда он становится положительным, это означает, что инвестиции были возвращены. Это число не говорит нам, сколько денег будет заработано. Однако полезно измерить уровень риска, связанный с проектом. Чем дольше требуется вернуть деньги, тем рискованнее. В зависимости от финансовых условий компании и устойчивости к риску это может быть критическим фактором.

260. Ценность против риска - сравнение ценности того, что должно быть сделано с другим показателем сравнения. Обычно этот показатель — стоимость. Характеристики оцениваются в двух измерениях: ценность и риск. Нет никаких предписанных способов оценки стоимости, и для этого вы можете использовать один из других методов, представленных здесь. Что касается рисков, существует несколько видов, но нас обычно интересуют: - Риск несоблюдения графика работ (например, «это может быть сделано не в тот момент, когда нам это нужно») - Стоимостной риск (например, «это может стоить дороже, чем то, что позволяет экономическое обоснование») - Риск функциональности (например, «мы, возможно, не сможем это сделать»)

![[assets/Pasted image 20250212155148.png]]

261. Ценность против Затрат - Функции оцениваются по их ценности и стоимости реализации. Те, у кого лучшие коэффициенты, будут иметь более высокий приоритет.

Также называемый “[Bang for the buck](http://tynerblain.com/blog/2008/10/20/planning-sprints-part-2/)”, похожий на ROI-подобный анализ, этот метод интуитивно понятен и также встраиваем в другие методы определения приоритетов.

Основная цель этого метода заключается в том, что мы стараемся [максимизировать ценность времени](http://tynerblain.com/blog/2007/07/31/prioritization-and-value-maximization/) доставки. То есть, для заданного периода выпуска мы работаем над наиболее ценными предметами, которые мы можем поместить в этот период.

![[assets/Pasted image 20250212155306.png]]

Ключевые выводы о приоритизации(на примере Циана)

262. Классические методы приоритизации, о которых пишут статьи и книги, на самом деле используются в компаниях — только в доработанном виде.
263. Каждый показатель того или иного метода приоритизации необходимо откалибровать под свои процессы и метрики.
264. Выбор метода приоритизации зависит от типа продукта: например, новый продукт сложно просчитать в деньгах.
265. Если оценка влияния гипотезы состоит из нескольких метрик, необходимо свести их к общей, интегральной метрике. Если это не получается — выбрать наиболее важный параметр.
266. Приоритизация — не жесткий процесс, если рынок или какие-то отдельные параметры рынка меняются, необходимо пересматривать приоритеты.
267. Приоритет на высоком уровне. По сути, все методы определения приоритетов работают с высокоуровневыми функциями (темами) и целями пользователя. Это важно по двум причинам:

- Основное внимание уделяется предоставлению ценности пользователю, а не мелочам (по крайней мере, вначале);

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

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

На что категорически стоит обращать внимание при приоритизации гипотез

269. Стратегия компании. Первое, из чего можно исходить — это стратегия компании. Условно: если у компании есть стратегия расширения, перехода на новые рынки, или, наоборот, сокращения расходов и оптимизации, то само направление движения компании может подсказать идеи для создания новых фич.
     - Если у вас операционная компания, такая, как, например Skyeng, то понятно, что в ваш бэклог обязательно будут входить различные фичи, которые призваны помочь сократить операционные расходы и автоматизировать некоторые процессы
270. Job Story. Расширение Job Story пользователя. Приведем такой пример: все видели недавний запуск Яндекс.Go, который теперь стал закрывать job story не только такси, но и заказа продуктов, еды и так далее. Это тоже часть стратегии компании, новая глобальная функция, которую компания закрывает. Это не маленькая фича, а глобальное изменение рынка, и если у вас верхнеуровнево сформулирована job story, то бэклог наполняется соответствующими задачами, которые помогают ее реализовать.
271. Инсайты от фаундера. Иногда то, что приносит фаундер или руководитель, является, как минимум, странным. Однако такие ситуации являются достаточно редкими, и в большинстве случаев у руководителя или фаундера лучшее понимание рынка, большая насмотренность, он умеет чувствовать аудиторию, и поэтому его инсайт может стоить тридцати ваших инсайтов. Разумеется, нельзя стопроцентно доверять его видению, нельзя без проверки исполнять желания фаундера или руководителя, но прислушиваться к его мнению очень важно.
272. Инсайты с рынка. Четвертый инструмент — инсайты с рынка. Если вы находитесь на позиции мидл- или сеньор-продакта или туда метите, очень важно следить за рынком:
     - Узнавать, что нового появилось в сфере технологий, близких к вашему продукту;
     - Следить, что запускают ваши конкуренты в России, в США, в Китае или где-то еще. Кстати, об этом: на самом деле, Китай — это очень хорошая история, если вы продакт, или хотите им стать, или выполняете тестовое задание по устройству в какой-нибудь продукт, то вам точно стоит посмотреть, чем закрыта эта пользовательская потребность в Китае, потому что там огромное количество интересных продуктов, огромное количество ресурсов, и продукты, созданные в Китае, могут быть очень нестандартными в своих решениях, потому что их оунеры мыслят иначе, и это тоже очень неплохой источник для наполнения своего бэклога.
273. Инсайты от отдела продаж или техподдержки. Любому продакту стоит время от времени слушать звонки отдела продаж и читать чаты технической поддержки. Для начала, это позволит вам развить ваше умение чувствовать продукт и пользователей. Подобная насмотренность нужна для того, чтобы с большей вероятностью угадывать, только ознакомившись с какой-то фичей, «выстрелит» она или нет, а так как различных гипотез и идей огромное количество, то со временем вы сможете самые неудачные из них устранять в самом начале — это значительно ускорит процесс.
274. Аналитика. Здесь все просто: вы изучаете вашу систему аналитики, просите вашего аналитика искать «выбросы» — неожиданные изменения метрик. Допустим, на одном из маркетинговых каналов какая-то метрика неожиданно выросла, и совершенно непонятно, что послужило тому причиной. В таком случае ваша задача — понять, почему эта метрика выросла, и попытаться распространить эту причину на все остальные каналы.
275. Результаты кастдевов. Когда вы занимаетесь кастдевом, в вас пробуждается эмпатия. Вы начинаете чувствовать то, что чувствует ваш пользователь, и понимаете, как он мыслит. Очень часто люди, работающие в сфере IT, что называется, «далеки от народа».

CJM

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

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

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

Покупатель - Это не просто пользователь интерфейса. Это потребитель услуги. Покупателя от пользователя отличает готовность платить денежки и пользоваться предоставленными услугами.

Сервис - Это не просто интерфейс. Это услуга, инструментом получения которой может быть (а может и не быть) интерфейс. Сервис оплачивается клиентом и включает в себя множество компонентов от склада до отдела контроля качества.

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

Warning

CJM не нужен, если нет сервиса и покупателя, когда необходимо проиллюстрировать взаимодействие пользователя с интерфейсом

Уместно и полезно применять CJM в двух случаях:

1. при анализе текущего сервиса (не интерфейса)
2. при планировании нового сервиса

CJM для существующего сервиса

276. Составляем персону

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

278. Выписываем текущие проблемы в каждой точке - На основе общения с заказчиком и текущими клиентами мы можем понять проблемы, которые сейчас существуют на том или ином этапе взаимодействия c сервисом

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

Есть основные блоки, которые традиционно пристутствуют в CJM. Вы можете вставлять все или только необходимые.

1. **Персона.** Кратко описываем кто наш клиент и чего он хочет.
2. **Путь клиента.** Перечисляем действия, которые должен предпринять клиент для достижения результата. Путь начинается не с получения услуги или пользования интерфейсом, а с момента знакомства и принятия решения об использовании.
3. **Точки соприкосновения.** Под каждым действием в пути клиента указываем точки взаимодействия с сервисом, которые сформулировали ранее.
4. **Моменты истины.** Представляют собой моменты на пути к покупке, когда происходит ключевое событие и формируется мнение о бренде. Проще говоря, это точки соприкосновения, когда ваши клиенты либо влюбляются в ваш продукт, либо отворачиваются и уходят. Момент истины может быть один, но чаще их несколько. Важно обозначить эти точки, чтобы особенно тщательно проработать момент и не потерять клиента. _Например, для клиента исчерпывающее описание услуг и указание стажа работы может стать моментом истины, когда он решит пойти в салон._
5. **Поставщики услуг.** Под каждой точкой соприкосновения записываем, кто предоставляет услугу и несет за это ответственность. _Например, администратор салона во время записи или косметолог во время процедуры._
6. **Эмоции.** Что чувствует клиент в каждой из точек соприкосновения. Можете использовать шкалу от -5 до 5 или визуализировать смайликами. Получить эти данные можно в ходе интервью или опросов текущих клиентов–вы можете узнать много интересного.
7. **Возможности.** На каждом из шагов у сервиса есть шанс улучшить взаимодействие с клиентом. Клиент грустит на шаге записи, потому что не может дозвониться в салон? Электронная запись–наша возможность.

CJM для нового сервиса

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

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

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

Если у вас нет четкого понимания целевой аудитории и возможности проводить исследования, прото-персона позволит сформулировать предположительный портрет ЦА и сэкономить время.

>Очень важно **не** создавать прото-персону в одиночку. Персона — инструмент для синхронизации команды, и прото-персона должна быть создана коллективно.

283. CJM воркшоп. Как и в случае с прото-персоной, планируемый CJM не должен быть плодом только вашего воображения. Необходимо привлечь клиента, команду, а в идеале и представителей ЦА к проектированию пути покупателя, ведь диаграммы сами по себе не дают ответов, но способствуют диалогу. Ваша задача — сделать так, чтобы этот диалог произошел.

Воркшоп — это способ поделиться опытом, идеями и создать нечто общее. Это ни в коем случае не семинар, на котором все слушают эксперта-проектировщика. Во время воркшопа ваша задача — модерировать, а не проводить лекцию. 

![[assets/Pasted image 20250213145112.png]]
Помните, что полученная на воркшопе CJM содержит много фантазий и предположений. В процессе ее создания и вы и участники хорошо это прочувствуете.   

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

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

Другие методы создания карт(mapping)

![[assets/Pasted image 20250213150944.png]]

Базовый шаблон составления любой карты

285. Service Blueprint Плюсы - простая карта с четкой структурой - не требует сложных исследований, только наблюдения - подходит для совместной работы

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

286. Customer Experience Map(не путать с CJM) Плюсы - не ограничивается покупкой услуги, использованием сервиса - очень гибкая: в зависимости от задачи можно отходить от структуры, менять элементы - позволяет вызвать эмпатию и проектировать “снаружи внутрь” - подходит для совместной работы

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

287. User Stories Map - Epics (большой кусок работы, который имеет общую цель. Могут быть организованы по времени, аналогично этапам на CJM или логически) - User Stories (меньшие куски работы, которые нужно выполнить чтобы закрыть Epic. Формулируются по специальному шаблону и фокусируются на потребности конкретной роли) - Релизы (этапы во времени разработки, по которым разбиваются User Stories)

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

**Минусы**
- необходимо поддерживать, обновлять и дополнять
- риск наплодить много сторей, в которых можно запутаться
- частично зависит от менеджером проекта/скрам-мастера

288. Empathy Map Плюсы - позволяет вызвать эмпатию и проектировать “снаружи внутрь” - аггрегирует наши знания о ЦА в удобном формате - подходит для совместной работы - помогают увидеть несоответствия в словах и мыслях пользователя или в словах и поведении. Это позволяет создать продукт, который основан не только на том, что мы слышим от пользователя, но и на глубинных наблюдениях за его поведением и мотивами.

**Минусы**
- требует глубоких качественных исследований (интервью, наблюдения, тестирования)
- можно утонуть, пытаясь провести линию различий между похожими блоками (например, think и feel) или начать придумывать от себя

---

Навигация

• Назад: Продуктовая аналитика
• Наверх: Шпаргалка по продакт-менеджменту
• Далее: Дизайн для менеджеров