Product Vision, Value and Stakeholder Discovery

Introduction

Agile development is often described as an approach for delivering working software incrementally. That description is incomplete. Agile teams also need to decide what is worth building, for whom, and why. Without a clear product direction, iterative delivery can become a rapid production of features that are technically sound but commercially irrelevant, ethically problematic, or poorly adopted.

Product discovery addresses these questions before and during delivery. It connects user needs, organizational strategy, market evidence, technical possibilities, and measurable outcomes. In Scrum, discovery is not a single phase that ends before development begins. It is a continuing activity involving the Product Owner, Developers, stakeholders, users, and other relevant specialists.

This chapter explains how to create product visions, goals, roadmaps, personas, value propositions, stakeholder analyses, discovery practices, and outcome hypotheses. It also considers limitations, governance, and the responsible use of data and artificial intelligence in product decisions.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the relationship between product vision, strategy, goals, objectives, and backlog items.
2. Construct a clear product vision and value proposition.
3. Identify, segment, and analyze stakeholders.
4. Develop evidence-based personas and customer journey insights.
5. Apply design-thinking and product-discovery practices.
6. Formulate outcome hypotheses and connect them to measurable evidence.
7. Compare roadmap approaches and select an appropriate one.
8. Evaluate product decisions for feasibility, viability, desirability, usability, and ethical risk.

1. From Features to Outcomes

A feature is a capability supplied by a product, such as passwordless login, search filtering, or automated notifications. An output is something the team produces, such as a released feature or a completed sprint increment. An outcome is a change in user behavior, experience, or organizational performance resulting from that output. An impact is the wider, sustained benefit sought by the organization or society.

For example:

The causal relationship is not automatic. Releasing a notification does not prove that students will respond, advisers will act, or retention will improve. Discovery therefore asks what assumptions connect an intervention to an expected outcome.

A useful product decision begins with a problem or opportunity rather than a preselected feature. The question is not merely “Can we build it?” but also “What evidence suggests that building it will create meaningful value?”

2. Product Vision, Strategy and Goals

Product vision

A product vision is a concise description of the desirable future created by a product. It provides direction without prescribing every implementation detail. A strong vision identifies a meaningful beneficiary, a significant need, and the change the product seeks to create.

For example:

Enable working university students to complete high-quality learning activities flexibly, confidently, and affordably.

This statement is preferable to “Build a mobile learning application,” because it describes the intended value rather than a particular technology.

A vision should be:

• user- and outcome-oriented;
• understandable to technical and nontechnical stakeholders;
• ambitious but credible;
• stable enough to guide several release cycles; and
• open to multiple solutions.

Strategy

Product strategy explains how the organization intends to move toward the vision. It normally identifies target users, differentiated value, major choices, constraints, and evidence needed for investment decisions. Strategy is more specific than vision but broader than a backlog.

Product goals and objectives

A product goal is a near- or medium-term outcome that gives the Scrum Team a coherent objective. In Scrum, a Product Goal describes a future state of the product and provides a target against which the Product Backlog is planned.

An objective should be observable and bounded. A useful objective often includes:

• a target population;
• a behavior or experience to change;
• a time horizon; and
• evidence of success.

For example, “Improve onboarding” is vague. “Within the next academic term, increase the proportion of new students who complete setup and their first learning activity in one session” is more useful, although the exact target should be based on baseline evidence.

Product goals should not be confused with activity lists. “Conduct five workshops” is an activity; “reduce confusion during first-time setup” is an outcome-oriented goal. Activities remain important, but they are means rather than proof of value.

Connecting the levels

A practical hierarchy is:

Vision → strategy → product goal → outcome hypothesis → experiments and increments → evidence

The Product Backlog supports the Product Goal, but the hierarchy is not purely one-way. Evidence from users, market research, analytics, and delivery can cause the team to revise the strategy or even the vision. Agile planning is adaptive, not merely progressive decomposition.

3. Value and Value Propositions

What is product value?

Value is contextual. It may include revenue, cost reduction, risk reduction, learning, convenience, accessibility, trust, safety, social benefit, or enjoyment. Different stakeholders may experience different forms of value, and value for one group can create costs for another.

A technically elegant product may have low value if it solves an unimportant problem. Conversely, a simple service may be highly valuable if it removes a frequent and costly difficulty.

Teams can assess a proposed opportunity using five complementary questions:

1. Desirability: Do people need or want it?
2. Viability: Can the organization sustain it financially and operationally?
3. Feasibility: Can it be built and operated with available technology and capability?
4. Usability: Can intended users understand and use it effectively?
5. Responsibility: Does it respect safety, privacy, fairness, accessibility, and legal obligations?

These dimensions are not a mechanical scoring formula. They are lenses for identifying assumptions and trade-offs.

Value proposition

A value proposition states who the product serves, what important problem or job it addresses, how it helps, and why the proposed approach is preferable to alternatives. A useful template is:

For [target user] who [need or problem], [product] provides [benefit] by [distinctive approach], unlike [alternative], which [limitation].

Example:

For shift-working students who struggle to coordinate study time, the learning planner provides personalized, achievable study schedules by combining course deadlines with available time, unlike generic calendar tools, which do not understand academic workload.

A value proposition is a hypothesis, not a marketing fact. It must be tested against evidence. Claims such as “personalized,” “secure,” “easy,” or “faster” should be operationalized and measured.

4. Stakeholder Discovery and Analysis

A stakeholder is any person, group, or institution that affects, is affected by, or has a legitimate interest in the product. Stakeholders may include end users, paying customers, administrators, regulators, support staff, suppliers, security specialists, communities, and people indirectly affected by product decisions.

Stakeholder identification

Begin broadly. Useful sources include:

• service and process maps;
• organizational charts;
• customer-support records;
• regulatory and contractual obligations;
• interviews with sponsors and operational staff;
• user research; and
• analysis of who supplies data, makes decisions, or bears risk.

Distinguish the buyer, user, administrator, beneficiary, and person affected. They may be the same person, but often are not. In an employee monitoring system, for example, an executive may buy the system, a manager may administer it, employees may be monitored, and a regulator may scrutinize its use.

Power–interest analysis

A simple stakeholder matrix considers relative power and interest. Stakeholders with high power and high interest usually require close collaboration. High-power but low-interest stakeholders need appropriate engagement and assurance. Low-power but high-interest groups should not be ignored: they often possess essential domain knowledge and may experience the greatest consequences.

This matrix is a conversation aid, not a scientific measurement. Power and interest can change during the product life cycle, and stakeholders should not be reduced to labels.

Stakeholder salience and inclusion

Power is not the only consideration. Legitimacy and urgency also matter. A group with little formal power may have legitimate rights or face urgent harm. Children, disabled users, low-income users, and people excluded by language or connectivity constraints may be underrepresented in conventional research. Responsible discovery actively seeks their perspectives.

5. Personas and User Understanding

A persona is a research-informed archetype representing a meaningful user group. It is not a fictional biography invented from stereotypes. A persona typically includes goals, context, behaviors, constraints, frustrations, relevant abilities, and quotations or evidence patterns.

A useful persona distinguishes:

• goals: what the person is trying to accomplish;
• tasks: activities performed to pursue those goals;
• context: environment, device, time pressure, and social setting;
• pain points: obstacles or sources of dissatisfaction;
• motivations: reasons for adopting or avoiding a solution; and
• constraints: accessibility, financial, technical, cultural, or organizational conditions.

Personas must be traceable to research. Teams should record the evidence base, date, sample limitations, and assumptions. A persona should be revised when evidence changes.

Personas do not replace direct engagement with real people. Overreliance on personas can hide variation within a group, encourage stereotyping, or cause teams to design for an imagined “average” user. Complement personas with journey maps, accessibility reviews, behavioral data, and direct usability testing.

Jobs to be done

The jobs-to-be-done perspective focuses on what users are trying to accomplish in a situation, rather than only their demographic characteristics. A job statement might be:

When I receive a complex assignment while working full time, I want to identify the next manageable study action, so that I can make progress without feeling overwhelmed.

This format helps the team investigate context and desired progress. It does not imply that demographic information is irrelevant; identity, resources, culture, and accessibility can strongly shape the job and its constraints.

6. Design Thinking and Discovery Practices

Design thinking is commonly represented through empathizing, defining, ideating, prototyping, and testing. In professional practice, these activities are iterative rather than a strict sequence.

Empathy and research

Discovery methods include:

• semi-structured interviews;
• contextual observation;
• diary studies;
• surveys;
• usability tests;
• support-ticket analysis;
• product analytics;
• competitive and comparative research; and
• collaborative workshops.

Each method has strengths and weaknesses. Interviews reveal perceptions and language but may not predict behavior. Analytics show observed behavior but rarely explain motivation. Surveys can reach many participants but depend on question quality and sampling. Usability tests expose interaction problems but usually involve small samples.

Good research begins with a decision or learning question. “What should we learn to decide whether this opportunity deserves investment?” is more useful than “Let us interview users.”

Problem framing

A problem statement should identify a user, context, difficulty, consequence, and evidence. Avoid embedding a solution prematurely. “Users need a chatbot” is a solution request. “New users cannot find reliable answers outside office hours and abandon setup” is a problem statement that permits multiple solutions.

Ideation and prototyping

Ideation generates alternatives before the team commits to one design. Prototypes may be sketches, storyboards, clickable interfaces, service simulations, or technical spikes. A prototype is valuable when it answers a question cheaply and safely.

The appropriate fidelity depends on the uncertainty. A paper prototype may test navigation structure; a technical spike may test integration feasibility; a service role-play may test operational responsibilities. High visual polish is not evidence of product value.

Testing and synthesis

Research findings should be recorded as observations, interpretations, and implications. Teams should distinguish what was directly observed from what is inferred. Triangulation—comparing interviews, behavior, and operational evidence—can increase confidence, though it does not eliminate bias.

7. Outcome Hypotheses and Evidence

An outcome hypothesis expresses a proposed intervention and its expected effect. A practical structure is:

We believe that [intervention] for [target group] will produce [observable outcome] because [reason or assumption]. We will examine [evidence] within [time or context].

Example:

We believe that showing a single recommended next study action to newly enrolled students will increase first-week task completion because it reduces decision overload. We will compare task completion and qualitative feedback during a controlled pilot.

A hypothesis should specify an observable outcome, but teams should avoid assuming that one metric proves causation. Useful evidence may include:

• adoption and activation;
• task completion;
• time to complete a task;
• retention or repeated use;
• error and support rates;
• satisfaction or perceived confidence;
• accessibility outcomes;
• operational cost; and
• unintended effects.

Leading and lagging indicators

Leading indicators provide early evidence, such as completion of onboarding or successful use of a prototype. Lagging indicators represent later outcomes, such as retention, revenue, or reduced incident rates. Leading indicators are faster but may be weak proxies. Lagging indicators are often more meaningful but slower and affected by many external factors.

Teams should define a baseline where possible, specify a comparison, and state the period of observation. A change in a metric does not automatically establish causation. Seasonality, concurrent releases, selection bias, and changes in policy can affect results.

A lightweight evidence record can include:

8. Product Roadmaps in an Agile Context

A roadmap communicates intended direction and sequencing. It is not a contractual list of guaranteed features. Roadmaps should express outcomes, themes, opportunities, or product goals rather than false precision about distant delivery dates.

Common roadmap styles include:

• feature-based: emphasizes capabilities to be released;
• outcome-based: emphasizes measurable user or business changes;
• theme-based: groups work around strategic areas such as trust or onboarding; and
• now–next–later: communicates relative priority without pretending that all future details are known.

An effective roadmap states assumptions, dependencies, confidence, and review points. It distinguishes commitments from options. Short-term items may be described with greater detail; later items should remain deliberately less specific.

Roadmap decisions should consider value, risk, effort, compliance, technical dependencies, and learning potential. A low-effort feature is not automatically high priority, and a high-value idea may need discovery before delivery.

9. Integrated Applied Case: CampusConnect

The following is an illustrative fictional case.

Background

A university wants to improve support for part-time students in a full-stack development program. Leaders propose a mobile application containing announcements, calendars, discussion forums, reminders, and an AI study assistant.

Problem

Initial stakeholder meetings reveal a feature-heavy proposal but little evidence of the central problem. Interviews with twelve students, four advisers, and three teaching staff show that students are not primarily missing announcements. Many struggle to determine which learning task should be completed next when work, family, and study obligations conflict. Advisers also report that they discover disengagement late.

The research sample is small and not representative, so the findings are treated as directional rather than conclusive. A survey and accessibility-focused interviews are planned to test whether the pattern extends to a wider population.

Analysis

Stakeholders include students, advisers, instructors, program leaders, the accessibility office, the data-protection officer, and the IT operations team. Students and advisers have high interest; program leaders have high decision power; the accessibility office and data-protection officer have legitimate governance authority even if they are not daily users.

A preliminary persona is developed:

Maya, a part-time student who works irregular shifts, uses a phone frequently but has limited uninterrupted study time, and wants clear next actions rather than another large information system.

The team identifies assumptions: students will trust recommendations; course data will be accurate; advisers can act on signals; and personalized recommendations will not expose sensitive information.

Approach

The product vision becomes:

Help part-time students make steady academic progress despite changing schedules, while enabling timely and respectful adviser support.

The first Product Goal is to reduce uncertainty during the first four weeks of study. Instead of immediately building an AI assistant, the team prototypes a simple “next best study action” flow using existing course deadlines and manually reviewed rules.

The outcome hypothesis is:

If students receive one clearly explained, feasible next action based on their course schedule, then more students will complete an early learning activity because the product reduces planning effort.

The pilot measures first-week activity completion, time to identify the next action, student-reported confidence, accessibility barriers, and adviser workload. It also monitors whether recommendations are incorrect or create pressure for students with exceptional circumstances.

Outcome and adaptation

The pilot shows improved task discovery but no clear improvement in completion. Interviews suggest that work shifts, not information overload, are the larger barrier. The team therefore explores flexible rescheduling and adviser-supported planning rather than expanding automated recommendations. This is a productive result: discovery prevented premature investment in a broad AI feature.

Learning points

1. A feature request can conceal a different underlying problem.
2. Personas and hypotheses should be grounded in evidence and marked with uncertainty.
3. A roadmap should preserve options until important assumptions are tested.
4. Outcome measures should include user experience, operational effects, and unintended harm.
5. Discovery continues after release because real-world evidence can invalidate the original theory of value.

10. Challenges, Ethics and Governance

Confirmation bias

Teams may seek evidence supporting a preferred solution. Countermeasures include documenting assumptions before research, deliberately recruiting dissenting perspectives, testing competing explanations, and distinguishing evidence from opinion.

Proxy metrics

A metric such as clicks, daily active users, or time spent may increase while meaningful value declines. Teams should ask whether the metric represents the intended outcome and examine qualitative evidence and possible harms.

Privacy and data protection

Discovery often involves personal data, recordings, location information, or sensitive inferences. Teams should collect only what is necessary, explain purpose and retention, restrict access, protect data, and follow applicable law and institutional policy. Consent must be meaningful, especially when participation could affect employment, grades, or access to services.

Algorithmic and AI risks

AI-assisted discovery can summarize interviews, classify feedback, generate personas, or suggest product ideas. Such tools can reproduce bias, invent statements, expose confidential material, and create unjustified confidence. Human researchers must verify outputs against source evidence. Sensitive research data should not be entered into a tool unless authorized safeguards and contractual controls exist.

If an AI system makes recommendations about people, the team should examine explainability, contestability, fairness, accessibility, security, and accountability. Automation does not transfer responsibility away from the organization.

Inclusion and accessibility

Discovery should include people with different abilities, languages, devices, connectivity conditions, and levels of digital confidence. Accessibility is not only a compliance concern; it affects product quality and the validity of research findings. A product tested exclusively with well-connected, experienced users may fail in its actual context.

11. Professional Best Practices

1. Start with a user or organizational problem, not a preferred feature.
2. Make the product vision brief, durable, and outcome-oriented.
3. Keep a visible record of assumptions and their evidence status.
4. Involve Developers early so feasibility and technical risk influence discovery.
5. Include operational, legal, accessibility, security, and support stakeholders.
6. Use multiple research methods appropriate to the decision.
7. Separate observed facts, interpretations, and hypotheses.
8. Treat roadmaps as communication and learning tools, not rigid promises.
9. Measure outcomes, not merely delivery volume.
10. Revisit the vision and strategy when evidence shows that the problem or context has changed.

Chapter Summary

Product discovery provides the reasoning that connects Agile delivery to meaningful value. A product vision describes a desirable future, while strategy explains choices for moving toward it. Product Goals translate direction into an actionable target, and outcome hypotheses make assumptions explicit and testable.

Stakeholder analysis identifies people who use, buy, govern, support, influence, or are affected by a product. Personas and jobs-to-be-done clarify user context, but they must be based on evidence and continually revised. Design-thinking practices—research, framing, ideation, prototyping, and testing—help teams learn before making expensive commitments.

Value includes desirability, viability, feasibility, usability, and responsible impact. Roadmaps should communicate direction and outcomes while preserving flexibility. Evidence should combine quantitative indicators with qualitative understanding and should be interpreted cautiously because metrics may be incomplete proxies. Ethical discovery requires inclusion, privacy protection, accessibility, transparency, and human accountability, particularly when AI is used. The central professional discipline is to learn continuously and adapt product decisions to credible evidence.

Key Terms

Product vision: A description of the desirable future a product seeks to create.

Product strategy: The set of choices and approaches used to pursue the product vision.

Product Goal: A future state of the product that provides a target for product planning.

Stakeholder: A person or group that affects, is affected by, or has a legitimate interest in a product.

Value: A beneficial change perceived by users, organizations, or other affected groups.

Value proposition: A statement of target users, problems, benefits, and differentiation.

Feature: A product capability provided to users.

Output: A delivered artifact or activity produced by a team.

Outcome: A change in behavior, experience, or performance resulting from an intervention.

Impact: A broader and more sustained consequence of product outcomes.

Persona: A research-informed archetype representing a meaningful user group.

Jobs to be done: The progress or accomplishment a person seeks in a particular context.

Discovery: Activities used to understand problems, opportunities, users, and possible solutions.

Outcome hypothesis: A testable claim linking an intervention to an expected outcome.

Roadmap: A communication of intended product direction and sequencing.

Prototype: A deliberately limited representation used to test an assumption.

Leading indicator: An early measure that may provide evidence of later results.

Lagging indicator: A later measure of an outcome or impact.

Triangulation: Comparing multiple evidence sources or methods to improve understanding.

Proxy metric: A measurable indicator used as an imperfect substitute for a less immediate outcome.

Review Questions

Short Answer Questions

1. Distinguish a product vision from a product feature.
2. What is the difference between an output and an outcome?
3. Define a research-informed persona.
4. Identify two limitations of interviews as a discovery method.
5. Why should a roadmap avoid false precision about distant releases?

Long Answer Questions

1. Explain how vision, strategy, Product Goals, outcome hypotheses, and Product Backlog items are related.
2. Describe a stakeholder-analysis process and discuss why low-power stakeholders may still require substantial attention.
3. Compare desirability, viability, feasibility, usability, and responsibility in product evaluation.
4. Explain how design-thinking practices can reduce product risk without eliminating uncertainty.
5. Discuss the ethical and governance risks of using AI to analyze user research or make product recommendations.

Analytical / Application Questions

1. A team proposes building a chatbot because customer-support tickets are increasing. Design a discovery plan that tests whether a chatbot addresses the underlying problem.
2. Construct a value proposition and an outcome hypothesis for a university service of your choice. Identify the assumptions and evidence you would use to evaluate them.
3. A pilot increases daily usage but also increases support complaints and excludes users with limited connectivity. Analyze whether the product should be considered successful and recommend next steps.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a product vision?

A. A detailed list of technical tasks for the next Sprint

B. A description of the desirable future the product seeks to create

C. A fixed contract guaranteeing every future feature

D. A record of defects found during testing

Correct Answer: B. A description of the desirable future the product seeks to create

Question 2

Which item is an outcome rather than an output?

A. A notification service released to production

B. A completed user-interface prototype

C. More advisers contact at-risk students earlier

D. A database migration completed by Developers

Correct Answer: C. More advisers contact at-risk students earlier

Question 3

Which stakeholder usually requires close collaboration in a power–interest matrix?

A. High power and high interest

B. High power and low interest

C. Low power and low interest

D. No power and no legitimate interest

Correct Answer: A. High power and high interest

Question 4

What makes a persona professionally useful?

A. It represents an imaginary average customer without research

B. It is based on evidence and describes goals, context, and constraints

C. It contains only demographic information

D. It remains unchanged throughout the product life cycle

Correct Answer: B. It is based on evidence and describes goals, context, and constraints

Question 5

Which statement is an outcome hypothesis?

A. Build an AI assistant by the end of the month

B. Conduct five stakeholder workshops

C. If users receive one clear next action, first-week task completion will increase

D. Add personalized recommendations to the backlog

Correct Answer: C. If users receive one clear next action, first-week task completion will increase

Question 6

Why is a prototype created during discovery?

A. To guarantee that the final product will succeed

B. To test an assumption relatively cheaply and safely

C. To replace all user research

D. To establish a fixed long-term roadmap

Correct Answer: B. To test an assumption relatively cheaply and safely

Question 7

Which is a leading indicator?

A. Five-year customer retention

B. Annual reduction in operating cost

C. Completion of onboarding during a pilot

D. Long-term societal impact

Correct Answer: C. Completion of onboarding during a pilot

Question 8

Which roadmap practice is most consistent with Agile uncertainty?

A. Specify exact features and dates for several years

B. Treat every roadmap item as an unconditional promise

C. Use outcomes or themes and provide more detail for near-term work

D. Avoid communicating product direction to stakeholders

Correct Answer: C. Use outcomes or themes and provide more detail for near-term work

Question 9

What is a major risk of using AI to summarize sensitive user interviews?

A. It makes all research automatically representative

B. It can expose confidential data or produce inaccurate summaries

C. It eliminates the need for human judgment

D. It guarantees accessibility compliance

Correct Answer: B. It can expose confidential data or produce inaccurate summaries

Question 10

A team observes increased clicks but also more complaints and exclusion of low-connectivity users. What is the best conclusion?

A. The product is successful because clicks increased

B. The complaints should be ignored because they are qualitative

C. The team should examine broader outcomes and unintended effects before judging success

D. The team should immediately add more features

Correct Answer: C. The team should examine broader outcomes and unintended effects before judging success