Defining Strategic Direction, Goals, and Priorities

The discovery work we covered in previous chapters gives you a clearer understanding of the needs, problems, gaps and opportunities to address them.

The next step is to use what you've learned to generate ideas that can address the opportunities and gaps you've identified, and gather enough evidence to decide which are worth pursuing, considering the value each could create, how well it aligns with the organization's priorities, and whether it is realistic given the available resources, constraints, and risks.

Once you've landed on the option that looks like the best fit, you define it in more detail through a solution vision and measurable goals. Together these give you and your stakeholders a basis for deciding what to work on first, and for explaining those decisions later, such as when someone asks why their request was scheduled behind somebody else's.

In this chapter, you explore simple ways to generate ideas, evaluate which of these initiatives are worth pursuing, establish a solution vision and measurable goals, set priorities, and develop a roadmap for what to do next.

Generating Ideas to Address the Opportunity

Start with your opportunity summary and the evidence you gathered during discovery and use these to explore the different ways it could be addressed. Generating several alternatives before deciding which one to pursue helps you avoid committing too quickly to the first workable idea and gives you a better basis for evaluating what is likely to create the most value.

Keep your ideas broad as an opportunity may be addressed by changing a process, improving an existing system, providing better information, changing roles or responsibilities, introducing new technology, or combining several of these approaches.

Idea generation works best when done as a collaborative exercise with your stakeholders since they understand different aspects of the problem and the surrounding system. A simple approach is to:

1. Start with the opportunity. Make sure everyone understands the improvement you are trying to achieve and the important findings, constraints, and assumptions that led to it.
2. Generate different approaches. Ask participants to suggest different ways the opportunity could be addressed. Consider changes to processes, information, technology, responsibilities, policies, services, or combinations of these.
3. Make the ideas visible. Capture ideas in a form that makes them easier to understand such as short description, sketch, storyboard, or simple prototype.
4. Combine and refine ideas. Bring similar ideas together, build on promising suggestions, and use discussion, feedback, or further research to develop them. As you do this, new questions may emerge that require you to revisit your earlier research or refine the opportunity.
5. Make a first cut. Remove ideas that clearly do not address the opportunity, substantially duplicate another idea, conflict with important constraints, or are obviously unrealistic. Keep this assessment lightweight; the aim is to reduce the number of alternatives that require more detailed investigation rather than decide which solution is best.
6. Identify the alternatives to investigate. Bring the remaining ideas together into a manageable number of distinct approaches that are worth evaluating in more detail.

You can do this individually or collaboratively using whiteboards, sticky notes, sketches, or other simple tools as this is an effective way for people to explore, describe and help illustrate and demonstrate their ideas.

Once you have a set of promising ideas, you can validate them in more detail to help you decide on which approach to pursue.

Validating Ideas

Once you have identified several promising ideas, investigate them far enough to decide which is worth pursuing. Consider whether each idea addresses the stakeholder need, supports the organization's priorities, offers enough value to justify the cost and effort, and can be implemented and supported with the available resources. You should also consider any significant environmental, social, ethical, security, privacy, or accessibility concerns.

Determine Strategic Fit

Senior leaders will often make the final decision about whether an idea is worth pursuing, so you need to analyze its fit against the organization's strategy, giving them evidence for that decision, and making any important assumptions or trade-offs visible.

You do this by checking how well an initiative supports the organization's strategy and priorities. Techniques such as PESTLE can help you investigate external factors that may influence the initiative, and SWOT, which can help you identify its strengths, weaknesses, opportunities, and threats. These provide you with an analysis framework to help you decide whether the initiative is worth pursuing.

PESTLE Analysis

Use a PESTLE analysis when you need to identify and analyze changes outside the organization that materially affect your initiative's viability and requirements, like changes in regulation, privacy and data protection laws, economic conditions, social expectations, and emerging technologies.

For example, developments in AI or the rapid expansion of data centers may create new opportunities, but they can also introduce regulatory, environmental, reputational risks and cost considerations that you, leadership and your other stakeholders need to understand to help make a decision about whether to proceed.

It organizes these factors into six categories:

How to Conduct a PESTLE Analysis:

1. Define the scope. Start with a quick scan of all six categories, then narrow down and investigate the factors most likely to affect the initiative.
2. Gather data. Work with subject-matter experts, organizational documents, government and regulatory information, market research, and other relevant external sources to help identify changes or trends that could impact your initiative.
3. Assess the implications. For each relevant factor, consider how likely it is to occur, how significant its effects could be, and what it could mean for the initiative.

Then, use your findings to identify opportunities, risks, or constraints that could affect the initiative, or feed them into a SWOT for further analysis.

SWOT Analysis

You use SWOT analysis to help you identify the internal and external factors that could impact your initiative, giving you a simple framework for considering what the organization already has in its favor, where it may be less prepared, what opportunities could be pursued, and what threats could make the initiative harder to deliver.

SWOT looks at four areas:

An effective SWOT analysis needs input from subject matter experts and domain specialists who understand the market, the technology, and the operational realities of your organization. These diverse viewpoints help you surface blind spots that a single analyst or a homogeneous team will miss and those same experts should assess the reliability of the information that's been gathered that will be used as input into the SWOT and this scrutiny reduces the subjectivity that otherwise weakens SWOT output (Helms & Nixon, 2010).

A focused SWOT session with your stakeholders is an effective way to bring these perspectives together. As you work through each area, use the following steps to keep the discussion focused and grounded in evidence:

1. Focus on the most important factors. Identify the strengths, weaknesses, opportunities, and threats most likely to affect your initiative.
2. Look for connections. Consider which strengths could help you take advantage of opportunities, which weaknesses could make threats more significant, and what risks you need to address.
3. Use evidence. Support what you and your stakeholders identify with evidence. If you have items that aren't supported by research, mark these as open questions that need further investigation.
4. Vet your results. Once you have assembled the findings, vet them through a second round of review, checking whether the data supports the conclusions drawn, whether any quadrant leans too heavily on assumption, and whether the team has conflated opinion with evidence.

Use what you learn to refine the idea, surface strategic risks and assumptions, and decide what still needs investigation before you can make a recommendation.

Assessing Financial Viability

To evaluate the feasibility of your initiative you need to compare its expected financial benefits with the cost of implementing and supporting it. These costs might include infrastructure and licensing costs, software development or purchasing costs, specialist expertise, implementation and training, and ongoing support and maintenance.

Return on Investment (ROI) looks at the expected financial benefits of a solution, such as increased revenue or decreased costs, against the estimated costs to implement and maintain it. If the benefits outweigh the costs, then the investment has a positive ROI and the further those benefits exceed costs, the stronger the return.

Early in your project, you're unlikely to have a detailed cost breakdown, so any ROI calculation is only as accurate as your estimates. Still, it's worth producing initial numbers (and when in doubt, document assumptions and use a range or conservative estimate) and share those projections with stakeholders to gauge their appetite for the investment.

Simple ROI Formula:

ROI = ((Total Benefits − Total Costs) ÷ Total Costs) × 100%

In addition to the expected costs and return, you should be able to tell your stakeholders when they can realistically expect a return on the investment the organization has made. For example, a new system may have a potentially strong ROI, but take several years to break even, while another may recover its costs quickly but produce more modest benefits after that point, so your decision-makers need to consider both the overall return and how long it will take to achieve it.

To do this, you figure out when the investment will "break even" or the point where the benefits you've gained finally catch up to what you spent.

Simple Break-Even Formula:

Break-even point = Initial Investment ÷ Net Benefit per Period

This provides a lightweight way to estimate how long it takes for the financial benefits of an investment to recover its initial cost, assuming net benefits are reasonably consistent from one period to the next.

Financial return may not always be the reason to pursue an initiative, for example a hospital, or government agency may be investing in better access, safety, compliance, or improved service. Where these benefits cannot be expressed credibly in financial terms, describe them separately rather than forcing them into the ROI calculation.

Validating Technical Feasibility

Your solution needs to work within the organization's technical environment and meet its important technical requirements and standards to determine whether the idea is feasible, whether it requires additional investment, or whether you need more information before making a decision.

To assess technical feasibility, work with subject-matter experts (SMEs) such as system owners, enterprise architects, security specialists, and data specialists. Review the organization's existing systems and platforms, and identify the infrastructure, integration, and any standards your solution has to meet.

In addition to working with SMEs, prototypes and proofs of concept can also reduce technical risk by testing specific assumptions about whether the solution will behave as expected. For example, you might test whether two systems can exchange data reliably, whether an AI service can achieve the required level of accuracy, or whether a proposed technology can meet the organization's performance and security requirements.

Establish a Solution Vision

Once you have decided which approach to pursue, you should develop a solution vision that describes its purpose, the stakeholder and organizational needs it addresses, and the future change it aims to create. As the work progresses you'll use this to guide decisions about scope and priorities and to assess whether new ideas support the outcomes you are working toward.

You should develop the vision with the people who will fund, use, support, or be affected by the solution using a "vision workshop" as it gives you the opportunity to bring these different views together, work through differences, and identify anything that still needs further discussion or investigation.

Begin by asking participants to describe the future they want the solution to create, the stakeholder and organizational needs it should address, and what success would look like, using whiteboards, sketchpads, sticky notes, and if it's a large workshop, use small breakout groups to help people contribute.

Once you've agreed on the vision the following structure can help you capture this in a concise and easy-to-understand way.

Defining Goals

Alongside the vision, you should set specific objectives and measurable results that help define what success looks like and give you a way to assess whether the solution is delivering the results you expected.

The Objectives and Key Results (OKRs) framework developed by Andy Grove at Intel provides a useful way to structure these goals by pairing an objective describing what you want to achieve, with a small number of measurable key results that show whether you are making progress and help prioritize and focus on execution (Doerr, 2018).

In the OKR framework objectives describe the outcome you are working toward. They should be clear, meaningful, and focused on what you want to improve or change rather than the features you plan to deliver or the activities you'll undertake to implement these.

Key results are then the measurable targets that show whether you are achieving the objective and where possible, include a baseline and a target (i.e. reducing processing time from 10 days to 6 days). Keep the number of key results small and between two or five key results per objective is usually enough (Doerr, 2018).

Example OKR

Setting Priorities

Once you have defined the vision and goals, you need to decide what to focus on first as you won't have enough time, funding, or capacity to address every need or deliver every capability at once and prioritization helps you decide and plan where to concentrate your effort.

What you prioritize will change as you move from discovery through to development. Early on, you might compare different initiatives, changes, or high-level capabilities that help achieve your goals. Later, these will be broken into requirements and backlog items that need to be prioritized to guide development.

The solution vision and your OKRs should guide prioritization. Work that supports important outcomes may deserve greater priority, but you should also consider other dependencies and the impact of delaying the work.

How to Prioritize

Involve your stakeholders in prioritization because different people may place different importance on value, risk, urgency, effort, and other factors. Prioritization workshops give people a way to compare alternatives, explain their reasoning, and make assumptions and trade-offs visible.

• Review what you have learned. Use your findings from stakeholder interviews, user research, organizational goals, and other discovery work.
• Agree on criteria. Decide which factors should influence the decision, such as value, urgency, risk, effort, or strategic alignment. Clarify what each factor means and whether some should carry more weight than others.
• Gather any additional input you need. Work with technical and other subject-matter experts where necessary to understand effort, constraints, dependencies, or feasibility.
• Review your prioritization. Review your final list of priorities and any unexpected results, challenge assumptions, consider the trade-offs, and agree on what should be pursued first.

Choose the factors that matter most to the decision. These might include:

• Necessity. Is the work required for the solution to operate, meet a legal or regulatory obligation, address an important security or safety concern, or enable another essential capability?
• Stakeholder value. How much could the work improve outcomes, experiences, decisions, or ways of working for the people affected?
• Strategic contribution. How strongly does the work contribute to organizational goals, priorities, or the outcomes defined in your vision and OKRs?
• Impact of delay. What happens if you wait, considering the delayed benefits, continuing operating costs, missed deadlines or opportunities, and risks that increase over time?
• Reach. How many users, stakeholders, transactions, processes, or parts of the organization are likely to be affected?
• Risk. Could completing the work reduce an important technical, operational, financial, security, regulatory, or adoption risk?
• Dependencies. Does other important work depend on this capability and does something else need to be completed first?
• Effort and cost. Approximately how much time, funding, specialist expertise, organizational change, and other resources will be required?
• Feasibility. Can the organization realistically deliver and support the work with the technology, data, skills, funding, and capacity available?
• Confidence. How confident are you that the expected value and impact are supported by the evidence available?

You'll rarely give every factor equal weight so focus on what matters most to the decision, and make the trade-offs clear to stakeholders. For example, a regulatory requirement may be high priority even if it does not directly address a user need because meeting the requirement is mandatory.

Ways to Prioritize

Different methods help you look at the decision in different ways, some use simple categories, while others use numerical values and calculations to help quantify priorities.

Choose a technique based on the decision you need to make, the factors that matter, the quality of the available evidence, and how much structure you need to compare the alternatives.

Simple Ranking (High/Medium/Low or 1-2-3)

Simple ranking is a lightweight prioritization technique that groups goals, capabilities, requirements, or backlog items into a small number of priority levels.

Use simple ranking when you need a quick, practical way to compare items without applying a detailed scoring model. It is particularly useful early in planning, when estimates and evidence are still limited, or when stakeholders need a shared starting point for discussion.

Define what each priority level means before assigning rankings. The criteria should reflect the initiative's goals, timing, dependencies, risks, and expected value. Numeric labels such as 1–2–3 can make larger sets easier to sort and summarize, but they should not be treated as precise scores.

For example:

• 1 or High: Essential to the next outcome, decision, or release; delaying it would significantly reduce value, increase risk, or prevent other work from proceeding.
• 2 or Medium: Valuable and likely to be needed soon, but it can follow the highest-priority work without undermining the immediate outcome.
• 3 or Low: Useful but not currently time-sensitive; it can be deferred while the team gathers more evidence or focuses on higher-value work.

Allocation Methods (Dot Voting & $100 Exercise)

These are collaborative, workshop-based techniques that encourage stakeholder participation. The group reviews the items that need to be prioritized and participants then either vote with dots or distribute a notional budget across the items. Once the voting is complete, the results are tallied and discussed to identify shared priorities, differences in perspective, and areas that may need further conversation.

Common approaches to allocation include:

• Dot Voting: Participants allocate a limited number of stickers (dots) to requirements they support. Multiple dots can be placed on the same item to show a stronger preference.
• $100 Exercise: Each participant has $100 in fictional dollars to "spend" across options, allocating more to those they value most.

MoSCoW (Must Have, Should Have, Could Have, Won't Have)

MoSCoW helps you prioritize capabilities or requirements by grouping them according to how important they are to the solution or the outcome you are trying to achieve.

• Must Have: Essential. Without it, the solution would not be viable, safe, compliant, or able to achieve its essential purpose.
• Should Have: Important, but the solution could still succeed without it initially.
• Could Have: Useful or desirable, but lower priority and easier to defer if time or resources are limited.
• Won't Have (this time): Deliberately left out of the current scope, although it may be reconsidered later.

For each item, ask, "What happens if we don't include this?" to help you identify what is essential from what is important or simply desirable.

Value vs. Effort

The value/effort matrix (also called an impact/effort matrix) helps you compare alternatives by considering the value they could provide against the effort required to deliver them. Plot each alternative according to its expected value and approximate effort to identify potential quick wins, higher-effort investments, and work that may be less worthwhile.

Developing a Product Roadmap

A roadmap helps you show stakeholders which goals you expect to address, which capabilities you plan to deliver, and roughly when that work may happen. Roadmaps generally work best when they emphasize outcomes, capabilities, and broad timeframes rather than detailed task plans.

This distinction separates a roadmap from a project plan or Gantt chart. A product roadmap defines the strategic direction and intended outcomes, whereas a project plan explains how and when specific tasks will be completed, including the schedules, resources, and dependencies required for execution. You will often need both, but for different audiences and different conversations.

How to Create a Roadmap

1. Set your timescale. Roadmaps may use broad time horizons such as months or quarters.
2. Identify goals and results. Each release should clearly identify which strategic goals it addresses.
3. Identify key capabilities and features. Review your opportunity statement, vision document, and prioritization.
4. Map features to goals. Capabilities and features should be explicitly linked to the goals they support, ensuring that project or product roadmaps illustrate how feature releases support organizational and stakeholder goals.
5. Define success metrics. Using the outputs of defining your OKRs, define how success will be measured for each release.
6. Identify supporting activities. Identify any key activities that enable release success, including research, development, change management, and marketing.
7. Identify dependencies. Identify any dependencies that need to be addressed to enable the release.

References