Упорядочение идей по приоритетам для эффективной разработки продукта
Умение грамотно распределять приоритеты — один из важнейших навыков менеджера по продукту. Эффективную расстановку приоритетов можно даже назвать сверхспособностью успешных команд по продуктам, помогающей им действовать быстро и направлять все усилия на самые значимые проекты.
Но определение приоритетов редко бывает простым и понятным, поэтому менеджеры должны действовать осмотрительно и тщательно взвешивать свои решения. Им приходится искать баланс между конфликтующими приоритетами и соображениями, например неотложными нуждами бизнеса, долгосрочной стратегией, запросами клиентов, конкуренцией и меняющимися условиями рынка.
С другой стороны, если расставлять приоритеты в отрыве от аналитики и без привязки к результатам, это может стать настоящим кошмаром. Дискуссии перерастают в конфликты, прийти к согласию не удается, а решения принимаются под влиянием интуиции или самых громких голосов.
RUF: надежность, удобство использования, новые функции
Мы рекомендуем распределять вложения между новыми функциями продукта, улучшением уже реализованных возможностей и укреплением его базовой структуры для обеспечения надежности.
Для этой цели многие команды Atlassian используют так называемую систему RUF:
RUF = Reliability (Надежность) + Usability improvements (повышение удобства использования) + new Features (новые Функции)
Это своего рода пирамида.
| Надежность | The first thing users expect from your app is that whenever they open it, and it just works. |
| Usability improvements | The longer you’ve worked on a product, the more features it likely has. Feature bloat is the silent killer of many apps. |
| New Features + Ideas | With a strong foundation in place, you can add new features. Everyone knows what we’re talking about here 😉 |
The 3 Bucket Planning Guide for prioritizing new ideas
Even when it comes to new product ideas, take a balanced approach to set your product up for success.
🛑 You can’t just build whatever features customers ask for, as you risk only helping your current user base.
🛑 You can’t only focus on improving key business metrics like revenue growth, as you might ignore important customer needs.
🛑 You can’t only ship new revolutionary ideas either, or you put reliability and usability at risk
Adam Nash, former VP product and growth at Dropbox, suggested looking at 3 buckets (source: “the 3 bucket planning guide”):
A view of 3 bucket feature planning in Jira Product Discovery
- Metrics Movers are product initiatives that directly contribute to business goals by improving key metrics: sign-ups, conversion, retention, active users, referrals, revenue, etc. Growth initiatives typically fall in this category.
- Customer Requests are what customers ask for, both net-new features and improvements to current experiences. Addressing these helps keep customers happy, reduce support load, and ensure that your product nails its key jobs.
- Delighters are where your product innovates. These are the features your customers didn’t know they wanted, but can improve their lives by changing how they work. Delighters differentiate you from competition and build a moat around your product.
Allocating budget across investments
It’s important to be intentional in how you invest in each of these buckets. Otherwise, your velocity might drop because your team spends 80% of their time fixing bugs, or the growth of your product slows down, because you’re not thinking strategically. Shipping as many new features as possible is unlikely to fix that.
The right budget allocation for each bucket depends on many things, but in particular the stage of your product: pre-PMF (Product Market Fit), post-PMF, or mature product.
In practice, budget allocation could look like this:
| | Pre-PMF | Post-PMF | Mature |
|---|---|---|---|
| Надежность | Pre-PMF 10 % | Post-PMF 30% | Mature 50 % |
| Usability improvements | Pre-PMF 20 % | Post-PMF 20 % | Mature 20 % |
| Customer requests and delighters | Pre-PMF 70 % | Post-PMF 30% | Mature 10 % |
| Growth initiatives | Pre-PMF
| Post-PMF 20 % | Mature 20 % |
Remember, this should never be set in stone. For example, you might decide to invest more in new features for a few months, then go back and focus on UX improvements or addressing technical debt.
But as you allocate and re-allocate, it’s important to keep in mind the different aspects that are required to make your product successful, and to balance your investments over time.
There are different ways to manage these investments: you can have teams dedicated to one or the other bucket, you can make sure that each team has one initiative from each bucket at each time, or you can have each team pick work from each of the buckets in a round-robin fashion. There are pros and cons to each approach but it’s a lot more about delivery planning so we won’t cover them here.
Balancing investments at Jira Product Discovery
Here’s how we configured our investment allocation on the Jira Product Discovery team over a six-month period.
Investments across all squads
We have 4 main themes: pricing and packaging, growth, jobs-to-be-done and engineering initiatives. In each of these themes, we have a number of bets.
These bets are distributed amongst the JPD teams: 5 product squads and 1 engineering squad (Sirius, Horizon, Aurora, Juno, Pulsar, X-flow).
Product squads
Each product squad is required to allocate their time with the following split:
- 60% on product initiatives. For this they create a roadmap with two sections: one for new features, and one for improvements to the current product experience.
- 20% on RtB - Run the Business: on-call, bugs, etc.
- 20% on fixing tech debt
While we don’t strictly enforce this allocation, each team discusses keeping this balance during their sprint planning and monthly reviews. Typically, it does hold true over time.
For product initiatives, we keep a watch on feedback we receive from users and discuss every week with all product managers. We separate the feedback into “Boulders,” XL investments, and “Rocks,” large investments.
We have a separate list for “Pebbles,” small improvements fixing “paper cuts” in the UX. These are difficult to prioritize since you can’t compare their impact to L and XL investments. But, their impact compounds over time. The expectation is that each squad has one Pebble fix in progress at any point in time.
Engineering squads
Each engineering squad has a similar split. But instead of product initiatives they focus on pure engineering projects to improve system resilience and scale.
Setting the stage for productive prioritization discussions
There are many people at your company who have insights into business and customer needs your product should help with.
If you can harness this collective knowledge, you can build more confidence in your product decisions and mitigate the risk of making the wrong bets.
But this is easier said than done. We’ve heard of product teams being swamped with asks from leadership and sales teams, then constantly interrupted with requests for updates: “when is my request going to ship?”
Done right, you can get a lot of value from turning prioritization into a team sport. A collaborative prioritization process creates clarity of mission, vision and purpose, getting teams across the business working towards shared goals.
Here are a few principles to follow for productive, collaborative prioritization.
Определение четких ожиданий
Setting expectations is crucial for everyone to collaborate effectively. People must understand what prioritization actually entails, and how they should contribute.
Here are a few key ingredients:
- Everyone’s roles and responsibilities in the conversation
- Shared goals and ways to measure success
- Designated vocabulary and framework for prioritizing
- Established communication channels and feedback loops
Назначьте роли и обязанности
For prioritization to be a positive experience for everyone, you want to make it clear how they should contribute.
To help with this, we designed Jira Product Discovery around 3 roles: creators, contributors and stakeholders.
Where creators, contributors, and stakeholders fit into the prioritization process.
Позиция | Who they are | Ответственность |
|---|---|---|
| авторы | Who they are The core product team across product, engineering, design, research. | Ответственность Drive the product, the prioritization process, and the ideas from beginning to end. |
| Участники | Who they are Points of contact within the sales, support, customer success, marketing and other field teams. | Ответственность Participate in the prioritization process and provide key insights: customer requests, support problems, etc. |
| Заинтересованные стороны | Who they are The rest of the company, typically separated in 2 roles: leadership, and everyone else. | Ответственность Need visibility on priorities, progress and decisions and ways to provide feedback. |
Review priorities continuously for incremental improvement
Расстановка приоритетов в крупном масштабе один-два раза в год — распространенный, но неэффективный подход.
Он не работает, потому что не позволяет команде адаптироваться к постоянно меняющимся факторам. Ведь корректировки в продукт необходимо вносить при изменении рыночных условий, после разговоров с новыми клиентами или если реализация оказалась более сложной, чем ожидалось, и так далее.
Такой масштабный подход к приоритизации также требует долгих обсуждений, поскольку каждое решение имеет серьезные последствия. Обсуждение приоритетов может происходить напряженно, потому что участники ощущают давление из-за необходимости оправдать ожидания. Специалисты опасаются направить ресурсы в неверное русло и потом расхлебывать последствия месяцами.
Вот почему рекомендуется чаще пересматривать приоритеты со своими командами и заинтересованными сторонами: не реже одного раза в две недели или в месяц, а в идеале — понемногу каждую неделю. Спрашивайте себя: какие выводы сделаны? Нужно ли что-либо изменить в текущей работе?
Настройте бэклог продукта для проведения обсуждений
Чтобы каждый четко понимал свою роль, а решения принимались вовремя, рекомендуется настроить бэклог продукта следующим образом.
- Добавьте авторов в проект Jira Product Discovery. Пусть они могут задавать настройки проекта (поля, представления и т. д.), а также создавать идеи, представления и аналитику и управлять ими.
- Добавьте в проект участников и предоставьте им ограниченный набор базовых инструментов для совместной работы. Пусть они могут добавлять голосования, аналитику, комментарии и реакции.
- Заинтересованные стороны в проект добавлять не нужно. Они смогут ознакомиться с представлениями, доступными только для чтения, которые опубликуют авторы.
Рекомендуется создавать отдельные представления для каждой аудитории:
В Jira Product Discovery предусмотрено три представления для разных ролей.
Эти представления созданы для конкретных ролей, так что каждая группа участников может получить необходимую информацию в актуальном для них виде. Участнику сразу становится ясно, как команда по продукту расставляет приоритеты, какие идеи обсуждаются и как внести свой вклад. А любые возражения можно эффективно передать по специальным каналам.
При таком подходе каждая группа плодотворно участвует в обсуждениях, и на всех уровнях улучшаются сотрудничество и согласованность.
Методы совместной расстановки приоритетов в Jira Product Discovery
Чтобы расстановка приоритетов путем общего обсуждения была прозрачной для всех, каждый участник должен уяснить условия и лишь затем подключаться к процессу.
С бэклогом продукта в Jira Product Discovery вы легко объедините усилия для расстановки приоритетов. В этом разделе мы расскажем о различных способах настроить его для проведения обсуждений.
Во многих из этих способов используются числовые оценки, например от 1 до 5. Оценки по своей природе всегда субъективны, но важно понимать, что стоит за тем или иным числом. Для обсуждения относительного приоритета каждой идеи необходимо, чтобы все понимали систему оценок одинаково. Например, объясните всем, что считается «большими трудозатратами» или «незначительным влиянием».
Сыграйте в «10 долларов», чтобы привить команде привычку мыслить в рамках ограничений
Игра «10 долларов» — это увлекательный способ побудить людей оценить важность идеи с учетом ограничений.
Имей они неограниченное время и ресурсы, команда по продукту могла бы создать все что угодно. Но на практике и то и другое ограничено. Вот тут-то и пригодится игра «10 долларов». Она учит мыслить как менеджер по продукту — и помогает игрокам понять сложность его работы!
Игра «10 долларов» в Jira Product Discovery.
Метод прост: каждому участнику дается бюджет в размере 10 долларов. Их он может «потратить» на идеи, которые считает наиболее важными. Распределять траты между идеями можно как угодно: например, вложить 5 долларов в две идеи или 3 доллара в три идеи. Вместо 10 долларов также можно установить любой другой бюджет.
Затем участники должны обосновать свой выбор: почему они сочли определенные идеи важными или перспективными? Такой подход помогает вовлечь всех в активное обсуждение и учесть мнение каждого участника.
Попробуйте сыграть в «10 долларов» в начале цикла приоритизации, чтобы понять, как рассуждает каждый из участников команды. Или сыграйте в конце, чтобы узнать, совпадают ли суждения.
Организуйте обсуждения в командах по продукту и разработке с помощью матрицы сравнения влияния и трудозатрат
В матрице Impact vs. Effort (Влияние и трудозатраты) идеям присваивается приоритет с учетом их потенциального влияния на бизнес и трудозатрат, которые потребуются для их реализации.
Эта матрица — простой, но эффективный способ структурировать общение между менеджерами по продукту и разработчиками.
Попросите технических специалистов разъяснить потенциальные сложности разработки. Это поможет менеджерам определить, от каких идей возможна быстрая отдача и какие крупные проекты принесут выгоду в будущем, а также обосновать, почему одним идеям следует отдать предпочтение перед другими.
Матрица Impact vs. Effort (Влияние и трудозатраты) в Jira Product Discovery.
Учитывайте степень уверенности с помощью RICE (охват, влияние, уверенность, трудозатраты)
В системе RICE идее присваивают приоритет на основании четырех факторов: охвата, влияния, уверенности и трудозатрат. Этот популярный инструмент для управления продуктами помогает представить эти факторы в виде, понятном большинству заинтересованных сторон.
Большинство участников привыкли оценивать влияние идеи, ее охват и трудозатраты, которые потребуются для ее реализации. Но преимущество RICE заключается в том, что в расчет берется еще и степень уверенности в этих оценках.
Уверена ли команда по продукту, что инвестиции в идею окупятся? Или для такой уверенности им нужны дальнейшие исследования и проверки продукта на пригодность для клиентов и соответствие техническим требованиям?
Участники команды могут делиться своими выводами о готовности идеи к реализации или о необходимости дополнительных исследований.
Упоминайте клиентов в описании тех идей, которые соответствуют их потребностям
Многие компании, использующие Jira Product Discovery, выбрали этот подход: они настраивают представление со списком идей так, чтобы команды, взаимодействующие с клиентами, тоже имели к нему доступ.
Если клиент рассказывает о своих потребностях, а они имеют отношение к одной из идей, то специалист по продажам или поддержке вносит упоминание об этом клиенте в описание идеи. Идеи затем можно проранжировать в зависимости от количества упомянутых в них клиентов.
Если пользователей можно поделить на сегменты в зависимости от важности, команды по продукту и работе с клиентами могут присвоить им весовые коэффициенты. В приведенном ниже примере клиенты поделены на Enterprise (корпорации), SMB (малый и средний бизнес) и Startup (стартапы).
Это простой, но очень эффективный способ организовать плодотворное взаимодействие между командой по продукту и командой, взаимодействующей с клиентами.
В зависимости от целей компании, можно применять весовые коэффициенты для разных категорий клиентов.
Присвойте весовые коэффициенты ключевым клиентам для приоритизации идей.
Можно сделать расстановку приоритетов еще интереснее (но, возможно, это излишне)
Есть еще много методов, которые команды могут использовать для обсуждения приоритетов.
Безусловно, вы сами решаете, какой из них подходит именно вам, но в общем случае считается, что чем проще метод, тем результативнее обсуждения.
Метод «Сначала более ценная и короткая работа» (WSJF), пожалуй, слишком сложен.
Некоторые команды одержимы поиском «правильной» модели приоритизации. Но метод — это всего лишь средство, ведущее к результату. Он предназначен для того, чтобы помочь вам достичь своих целей, а не отнимать время и внимание. Помните: вы управляете в первую очередь своим продуктом, а не системой приоритизации.
Используйте метод, который подходит именно вам
Перечисленные выше методы — это просто возможные варианты. Не существует двух одинаковых проектов Jira Product Discovery, потому что нет двух одинаковых компаний или команд. Независимо от канала взаимодействия, все эти методы помогут вам получить всестороннее представление о следующем:
- каковы цели бизнеса;
- чего хотят потенциальные клиенты;
- каковы потребности клиентов и пользователей;
- как уменьшить нагрузку на команду поддержки;
- как внедрить практику предпродажных разговоров с потенциальными клиентами;
- и многое другое, в зависимости от вашего бизнеса и продукта.
Рекомендуется сочетать представления на свое усмотрение, исходя из уникальных потребностей команд и того, какой продукт вы поставляете. Это поможет вам расставить приоритеты так, как вы хотите. Ведь только вам решать, какими они должны быть: над чем работать, а что отбросить.
В результате обсуждения идей вы составите дорожную карту.
Что дальше?
Расстановка приоритетов — единственный способ увязать решения по разработке с желаемым готовым продуктом. Результатом хорошей приоритизации будут эффективные дорожные карты с продуманным распределением ресурсов. Эти карты станут для команд по продукту ориентиром при достижении бизнес-целей и адаптации продукта к потребностям клиентов.
Теперь мы готовы перейти к последнему разделу этого справочника. Мы обобщим полученные знания, чтобы:
вы могли создавать дорожные карты для слаженного взаимодействия между командами и заинтересованными сторонами.
Кроме того, мы приведем примеры того, как все это делаем мы сами, команда Jira Product Discovery, с использованием Jira Product Discovery и других продуктов.
Обратная связь и аналитика
Узнайте, как интеграция аналитических данных в процесс разработки поможет принимать эффективные решения, учитывать потребности клиентов и в конечном итоге создавать успешные продукты.
Составление дорожной карты
Узнайте, как разрабатывать эффективные дорожные карты по продуктам, позволяющие согласовать приоритеты, улучшить коммуникацию и поддержать общие стратегические цели команд.
