Ultimate Guide to Product Strategy Planning and Prioritizing

Supposedly, you’d like to figure out how to properly develop and build a product strategy, as well as learn how to prioritize ideas, features, and tasks correctly. Thus, you are in the right place!

In this guide, we share our insights for product and project managers and everyone who wants to be as great in strategy creating as Napoléon Bonaparte and learn more about the power of prioritization.

This guide consists of 5 blocks, describing:

1. Product strategy
2. GIST planning
3. Simplified GIST and how it works
4. Ideas prioritization
5. Feature Scoring

So here we go.

1.Product Strategy

Everything begins with a clear and flexible strategy. Determining the product strategy at the very start of your product lifecycle is in “must do” list. A good strategy should satisfy your customers’ needs and help them to respond to the other internal company needs. If you don’t have a clear strategy, then it’s not a time for prioritizing features yet.

A product strategy is a basis for the entire product lifecycle. As product leaders develop their strategies, they define the core product and customer attributes that are necessary to achieve success.

What exactly is a strategy?

In fact, any strategy is aimed to achieve a specific objective. It can be imagined as a route getting you from point A to point B.

What makes the strategy effective

“An effective strategy is a set of actions that is credible, coherent and focused on overcoming the biggest hurdle in achieving a particular objective”

Richard Rumelt

So, the effective strategy includes the following:

• Achieving specific objectives
• Set of particular actions with a specific plan
• The credible and coherent plan that should believably accomplish the objective and make sense.
• Focusing on overcoming the biggest hurdle: there should be a clear diagnosis of the biggest problem to be solved.

Actually, any product strategy consists of 4 parts: vision, goals, metrics and actionable plan.

Product vision

Vision includes details on the market opportunity, target customers, product positioning, a competitive analysis, and a market plan. The product vision describes who the customers are and what they need.

Product success is ultimately achieved if a product onboards new users and delivers its consistent value to them.

Product goals

Goals are measurable and time-bound objectives that have clearly defined metrics associated with them. Product goals help you to set what you want to achieve in the next quarter or another period of time (to increase revenue, expand into new countries, increase mobile adoption, and so on).

Product metrics

Metrics allow you to measure the progress of goal achievement. They should be specific and measurable.

Actionable plan

What should we do to be strategic? The answer is well described in the article How to be Strategic by Julie Zhuo.

2. All about GIST

For the first time, we’ve learned about GIST planning from Itamar Gilad’s article, who started to use it while working at Google. Why is it worth to be applied?

The challenge

Plans quickly go out of sync with reality — the longer they are the more they are wrong. Roadmaps and Gantt charts are helpful, however, there is no room for agility — changes at the top cause huge ripple effects of replanning and project cancellations at the bottom.

As roadmaps allow only for a few big projects to be funded, you have to prioritize and kill many potentially good ideas upfront. In top-down companies, the winner’s ideas come from management. In bottom-up teams getting your idea to win became a very big deal, hence pitching, salesmanship and hype are now mandatory product management skills.

The solution

The usage of the GIST planning system assists to solve such problems: you get the lightweight plans that are built for change. They lower management overhead, improve team velocity and autonomy, set a proper cross-company alignment, and ultimately products and solutions.

The author’s version of the GIST planning system consists of the following blocks: Goals, Ideas, Step-projects, and Tasks. Each block has a different planning horizon and frequency of change. Together the blocks constitute all the core planning any company and team needs to do.

G – Goals describe the company strategy in terms of desired outcomes: where we want to be, by when, and how will we know that we got there. Whenever anyone in the company is wondering “Why are we doing this project?” the goal should give the answer.

I – Ideas describe hypothetical ways to achieve the goals. They are hypothetical because there can be many ideas on how to achieve a given objective, but at most 1 in 3 ideas will deliver a positive result.

According to GIST, product managers:

• Collect all ideas in an Idea Bank. All ideas are welcome and the bank can hold hundreds of ideas indefinitely.
• Prioritize them using appropriate prioritization methods and frameworks.
• Put as many ideas as possible to the test in order of priority.

S – Step Projects occur when the bigger project behind the idea should be broken into small parts, each no more than 10 weeks long (according to GIST). For example:

Mockup → Prototype → MVP → Dogfood → Beta → Launch

Each step-project is like an experiment that tests the idea.

Product managers avoid all the nasty side effects of long projects because step-projects are small. Ideas that don’t work get dropped early, ideas that work get more investment. No need for pitching or politics. The ability to come up with an idea and see it come to life and tested in a matter of weeks is incredibly liberating and enjoyable for everyone involved.

T – Tasks are the parts of every step-project. This part of the system is well covered by Agile planning tools, Kanban boards, and other modern development project management techniques.

There is nothing to change at this level. The only difference is that the layers above are now Agile as well and ready for the change.

The process of GIST planning may seem too complicated, that’s why we offer a simplified version of the system.

3. Simplified GIST and how it works

GIST is a great framework, however, it may be redundant for small projects. The Step Projects Itamar Gilad writes about what is needed for large projects when the cost of developing a single feature can reach hundreds of thousands of dollars.

Step Projects are really useful for large projects because they help to validate ideas as soon as possible in order not to spend huge sums on the full development of the idea. For example, we do a mockup and usability testing with real users. We get negative feedback and understand that the idea does not work and therefore we stop further development of the idea.

For example, in mobile apps development, you can act without Step Projects. So after we’ve chosen the best ideas with the help of prioritization, we write the tasks for their implementation, collect the requirements, write specifications, and push them to development. At the end of the sprint, we put them to production and can collect data and feedback from users. In fact, the hierarchy looks like this:

• goals are formulated for a quarter ahead, it’s clear
• metrics – we choose key metrics that will show our movement towards goals and on which we will influence with the help of ideas. OMTM, North Star metrics or AARRR (Pirates metrics)  concepts can be checked here.
• ideas are hypotheses about how to raise our metrics
• features/tasks – specific tasks for developers and other team members for implementing ideas.

The simplified process looks rather simple: we set goals, choose appropriate metrics for control and collect the ideas that can improve these metrics. Then we conduct a Lean prioritization of ideas, apply features scoring, and finally write the task for the features that have won. Then the features get broken into tasks and they are pushed to development. 

How does it work?

Goals formulation

Let’s start with the goals settings to the quarter ahead.

Example1: For SaaS product – we have a 2-week trial and want to increase the number of companies that purchase a paid subscription after the trial. This is our main goal for the next 3 months.

Example2: For mobile games – we want to increase our revenue from 300K to 500K per month.

Choosing metrics

We use basic and additional metrics. All these metrics are in our zone of influence and it’s rather important.

Example1: The basic metric is a trial-to-paid conversion. Additional metrics can be represented as:

• Activation (AHA moment)
• Retention 1 day

Now trial-to-paid conversion is equal to 3%. The goal and the end of a cycle is 6%.

Example1: The basic metric is LTV. Additional ones:

• ARPDAU
• Retention 1 day
• Retention 7 day
• Average number of viewed video ads per user

Now LTV is $0.5 and our goal is to get $1 in 3 months.

We’ve set the goals and chosen the metrics. We’ve been collecting ideas into the idea bank all the time.

Collecting ideas

“If you want to have good ideas you must have many ideas. Most of them will be wrong, and what you have to learn is which ones to throw away“

Linus Pauling

Ideas are our hypotheses about how we will move towards our goal. The hypothesis has two main outcomes: it can be confirmed and it can not be confirmed.

For example, we formulate a hypothesis – if we make a tutorial in the game, then conversion into the purchase of a trial will increase by 5%. If the conversion grows by 5% or more, it means the hypothesis was confirmed. If the conversion does not increase at all or grows by less than 5%, then we believe that the hypothesis was not confirmed and our idea has not worked.

According to statistics, only 1 out of 3 ideas gives a positive result

That is why we collect absolutely all ideas.

Where can you get your ideas from? There are many sources; here are just some typical examples:

• Customer support tools used for customer conversations and knowledge base (Intercom.com, Zendesk.com)
• Users behavior analytics tools (Inspectlet.com or AppSee for mobile) that help to watch how individual visitors use your site as if you’re looking over their shoulders. These tools record videos of your visitors as they use your site, allowing you to see everything they do.
• Tools for measuring NPS (aka customer happiness) (Wootric.com, Satismeter.com). Customers put the number from 1 to 10 and can leave a comment.
• Behavior analytics tools (Amplitude.com, Mixpanel.com)
• Services that helps to follow competitors (Feedly.com)
• Customer development Interviews. The book about customer development – Custdev.com. 
• Experiments and A/B testing
• App Store/App Store Reviews
• Usability testing
• Surveys
• Hallway testing as one of the types of usability testing.

It’s hard to imagine that any company may have problems with ideas. There are always hundreds of them. Unfortunately, we cannot test all ideas because we have limited resources to develop these ideas. Besides, we do not want to do everything, we just want to reach our goals at the end of the quarter.

This is where prioritization is really helpful. And we recommend doing double prioritization:

• Every day you can prioritize new ideas with the help of Lean approaches that allow you to do this quickly. This way, all ideas in your backlog will be scored. During the backlog grooming process, you can do a periodic reassessment of your ideas.
• You can do Weighted Scoring to evaluate the best ideas once in every 1-2 weeks. This method is quite labor-intensive. Thanks to the preliminary Lean prioritization, you already know these best ideas. Applying Weighted Scoring, you highlight a set of criteria for evaluating, such as Value and Efforts. There can be 2 criteria in the Value block. For example, the effect on revenue and UX. For the objective assessment, you need to conduct a preliminary analysis of ideas. 

4. Ideas Prioritization

The first approach includes the frameworks that are considered to be quite effective and powerful and they do not take a lot of time and efforts. They are able to offer you a simple and fast prioritization system.

2×2 matrix for prioritization

The classic approach based on the initial Eisenhower matrix consists of two axes. Choosing the framework, you may set your own criteria and score product ideas, features and tasks. For example, such prioritization methods as Value vs Effort, Value vs Risk, Value vs Cost can be easily visualized with the help of this framework.

Here’s the explanation of Value vs Effort system:

Comparing the Value and Effort combination helps to prioritize tasks better and choose the most important ones for development.

• Value shows which business value the feature can bring to your product or your business
• Effort measures the resources needed to complete the task.

It can be visualized with the Backlog Priority Chart including 4 segments with a specific priority block:

• Time Sinks (the tasks are not worth working on at the moment)
• Maybes (the tasks that do not bring a lot of value but are easy to implement)
• Big Bets (the tasks that can bring a lot of value but are as well hard to implement)
• Quick Wins (the tasks are valuable and quite easy to implement).

ICE Scoring

ICE scoring method is a simple way to get things done and prioritize product features without extra requirements.

ICE scoring was intended to prioritize growth experiments. But now the ICE is used for features prioritization as well. All you need is to calculate the score per idea, according to the formula:

• Impact demonstrates how much your idea will positively affect the key metric you’re trying to improve.
• Confidence shows how I’m sure about all my estimates – both about impact and effort (how my estimations look like a truth).
• Ease is about the easiness of implementation. It is an estimation of how much effort and resources are required to implement this idea.

These values are rated on a relative scale of 1–10 so not to over-weigh any of them. You can choose what 1–10 means, as long the rating stays consistent.

The key goal of ICE scoring system is to prevent you from being bogged down in trying to fine-tune the score too much.

You may try the ICE model framework in Hygger. First, you need to collect all the ideas and product features on a Kanban-alike board, structure them using horizontal Swimlanes and Labels. You can also adjust the process of working with features using Columns. Then you can choose ICE score framework among the scoring types and apply it.

This tool that helps to choose better product ideas, as well as the special tool for calculating confidence, are also perfectly described by Itamar Gilad.

RICE Scoring

RICE is one more simple and convenient scoring model for product manager’s needs. RICE is an acronym including 4 components:

Reach

Reach is measured in a number of people/events per time period. This factor is aimed to estimate how many people each feature or project will affect within a specific time period and how many customers will see the changes.

Impact

Impact reflects what contribution does the feature give to the product. Value is understood in different ways in each product.

Impact is difficult to measure precisely. We choose from a multiple-choice scale: 3 for “massive impact”, 2 for “high”, 1 for “medium”, 0.5 for “low”, and finally 0.25 for “minimal”. These numbers get multiplied into the final score to scale it up or down.

Confidence

If you think a project could have a huge impact but don’t have data to back it up, confidence lets you control that. Confidence can be measured with a percentage scale.

Effort

Estimate the total amount of time a feature will require from all team members to move quickly and have an impact with the least amount of effort. Effort is estimated as a number of “person-months”, weeks or hours, depending on needs. It is the work that one team member can do in a specific month. Unlike the other positive factors, more effort is a bad thing, so it divides the total impact.

You need to rank proposed features with a Reach, Impact, Confidence, and Effort, and use the final score you’ve come up with to decide what should be implemented at first.

5. Features Weighted Scoring

The Weighted Scoring approach allows you to take your proposed features, rank them with a benefit-versus-cost framework on a number of criteria, and use the scores you’ve come up with to decide which features make the cut. This is a low-cost and convenient way to determine the relative value of any number of things you may work on.

It’s up to you what criteria to choose for your product and company objectives when evaluating features against each other for prioritization.

Let’s say, you can use real-world data – to score a feature on its ability to increase revenue, or to add customer value or value to the company itself. In terms of costs, you can evaluate an initiative on its complexity or level of difficulty to implement, or its hard-dollar operational costs.

Specific criteria for the scoring may be selected based on well-defined product goals and metrics. For example, for “In terms of potential benefits” the following may be chosen:

• Increases income
• Helps to acquire new customers
• Helps to retain current customers
• Adds Value for users
• How often is needed

In terms of costs, the following can be evaluated:

• Time and cost of development
• Time and cost of implementation
• Operational costs

The Weighted Scoring model is to quantify, to the best of your ability, each competing initiative on your list to help you prioritize the roadmap.

Planning Poker

Any ideas or features evaluation at the planning stage is always a subjective assessment in conditions of strong uncertainty. Evaluating ideas in groups allows you to make these estimates more accurate through open discussion of ideas. However, it is important to follow the basic rule – before evaluating, you need to loudly discuss the idea and try to touch on different aspects to complete the picture:

• Why do we need this idea/feature – Which metric are we going to improve?
• How will we understand that this idea has worked? With what grounds? What should we track in the app?
• What is the approximate solution to this idea? How will our users work with this solution?
• What will this idea affect?

Only after the group has discussed the idea you can proceed to the evaluation. The method is called Planning Poker because in the original it is used to evaluate tasks for sprints. Then product managers began to use it to evaluate ideas.

Every estimator has a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, or other settings. All these values represent the number of value or other units in which the team estimates ideas and features.

Аll estimators select one card to represent their estimate. All cards are then revealed at the same time. If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. First, the people who put a minimum and maximum estimation, have a voice. Just to understand their logic.

After further discussion, each estimator reselects an estimate card. All cards are again revealed at the same time. The process is repeated until consensus is achieved.

Other prioritization techniques and methodologies

Nowadays product managers may find dozens of classic and innovative prioritization techniques and approaches. We combine the most interesting of them in Hygger University section. Here’re top-6 according to their popularity among our users:

Value vs Cost

This is a very common method of determining priorities. Features are scored on their Value and Cost of implementation. Those with better coefficients will have a higher priority.

The main goal of the method is that at a certain release period we work on the most valuable tasks that can be accommodated in this period.

To visualize this method, you may also use a 2×2 chart. Spread out all the features that are considered from the perspective of their value in each dimension. Priority ranking will be displayed as the slopes of the lines going from the origin to each feature. The higher the slope, the higher the priority.

Kano model

Kano model is really useful because it helps to determine the relationships between the product update, the level of customer satisfaction and market dynamics.

This approach makes it possible to clearly describe the satisfaction of what needs leaves the consumer indifferent, dissatisfied, or makes him/her happy.

The model is based on the following premises:

1. 1. • Satisfaction. Customer satisfaction with product features depends on the level of functionality provided (how well they were implemented).
      • Customer reaction. Features can be categorized, depending on how customers react to the level of functionality provided.
      • Customer feelings. You can determine how customers feel about a feature through questionnaires.

4 Categories of Features:

Features can fall into four categories, depending on how customers react to the provided level of Functionality

Performance

Some product features behave as what we might intuitively think that Satisfaction works: the more we provide, the more satisfied our customers become.

Must-be

Other product features are simply expected by customers. If the product doesn’t have them, it will be considered to be incomplete or just plain bad. This type of features is usually called Must-be or Basic Expectations.

Attractive

There are unexpected features which, when presented, cause a positive reaction. These are usually called Attractive, Exciters or Delighters.

Indifferent

Naturally, there are also features towards which we feel indifferent. Those which their presence (or absence) doesn’t make a real difference in our reaction towards the product.

MoSCoW prioritization method

MoSCoW is the method of prioritization that is widely used in many areas to reach consensus among stakeholders. The name of the technique is an acronym, where each consonant letter defines a priority category:

• M – Must. The requirements that are critical and must be applied to a product as a matter of priority. Even if one of them is not taken into account, the release is considered to be unfulfilled.
• S – Should. Requirements important but not critical for the release. Such requirements are not very sensitive to time.
• C – Could. Desirable but not mandatory requirements for your release. These are usually low-cost improvements for the product.
• W – Would. These are considered the least critical or may not correspond to the product strategy at all. They can be ignored and be revised for future releases.

Buy a Feature

Buy a Feature is a gaming method and business prioritization technique for determining the most important features for customers.

This fun gaming method can be played collaboratively or individually. The principle is rather simple:

There is a group of buyers and you should present them a set of features that need to be prioritized. Every buyer gets some play money to spend on the features.

Every feature is priced according to some measure points (efforts, complexity, etc.). Players’ budget should be between a third to half of the total cost for all features.

When players buy the features, ask them to explain why they do it. The game ends when all money runs out or when players have bought all the features they’re interested in.

Buy a Feature gives a valuable set of insights on the most important features for customers.

Feature buckets

Feature Buckets method also looks helpful for determining priorities and getting great business results.

This method of prioritization proposed by Adam Nash is very simple. The author believes that feature prioritization differs greatly in different types of products and industries, and that is why he emphasizes that this method was defined specifically for a consumer of online products.

According to the method, you place feature concepts in one of the four buckets:

1. Metrics Movers. Features that will significantly move the target business and product metrics. Specific goals and strategies behind the decision to invest in a product should be here (AARRR (Pirate Metrics) will be helpful.
2. Customer Requests. Features that have been requested directly by customers.
3. Delights. Innovative features that are internally generated based on insights in design or technology.
4. Strategic. Features that are included for strategic reasons related to future goals.

A well-balanced product release should typically include features from all of these buckets.

KJ Method

KJ methodology was designed by Jiro Kawakita. The method is often used in product management as a group process for setting priorities. It quickly helps to come to objective group agreement from the series of subjective data. The concept focuses on stakeholders in one company.

This is an 8-step process for groups of any size, designed for an interval of about an hour. First, the following requirements must be met:

• Colored stickers
• A spacious wall
• A facilitator
• Flipchart or board for results of prioritization

There are special steps to follow:

1. Define a focus question. Every session will have its own focus question.
2. Organize a group. People should be from the different parts of the company. It will bring more diverse perspectives.
3. Put opinions on sticky notes.
4. Place the notes on the wall. Participants put their sticky notes up on the wall in random order.
5. Group similar items. Once everyone has added their contributions to the wall, the facilitator instructs the group to start grouping similar items in another part of the room.
6. Name each group. Everyone should assign a name to every group, using the second color of sticky notes.
7. Vote for the most important groups. Participants vote to choose which groups are the most important to answer the focus question.
8. Rank the most important groups. All sticky notes are placed on the whiteboard and ordered by the number of votes. Participants can combine similar groups, which adds their votes and moves them up the ranking.

When a couple of groups have much higher ranking than the rest, the facilitator may stop the process.

What’s next?

If the process of prioritization was successful, then everything is rather simple: all tasks are pushed to development according to Scrum or Kanban and the product manager will have to track their progress.

If your development team works in Jira, then you can push your features to Jira. Hygger supports integration with this platform. Besides, you can also keep track of tasks status in Jira, while being in Hygger.

You may get more details about Scrum and Kanban development from our articles:

• How to do Kanban with Hygger Software?
• How to Do Scrum with Hygger Software?

Feel free to also study our learning center – Hygger University with its Product Management 101 secton where the popular product management templates, methods, and techniques are gathered.

If you have any questions, please contact us.

Hygger team