Skip to main content

Chapter 17: The Human Side of the Case - Personas and Customer Journeys

Video: Personas & Customer Journeys: Bring the Human Side into Your Case Solution

Learning Objectives

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

  • distinguish a customer segment from a persona;

  • distinguish a useful persona from a demographic description;

  • identify customer or stakeholder goals, motivations, behaviours, values, and pain points;

  • create evidence-based or explicitly provisional personas;

  • recognise when multiple personas are required;

  • understand buyers, users, influencers, and decision-makers in organisational purchasing;

  • map a current customer, employee, user, or stakeholder journey;

  • identify stages, actions, thoughts, emotions, touchpoints, barriers, and opportunities;

  • recognise critical moments that disproportionately shape experience and behaviour;

  • connect visible experiences with the organisational activities producing them;

  • design a future-state journey around a proposed solution;

  • identify adoption, accessibility, resistance, and implementation barriers;

  • use personas and journeys to generate strategic alternatives; and

  • test whether a solution is strategically attractive and humanly realistic.

Why This Matters

Case teams often become obsessed with numbers:

  • revenue;

  • market share;

  • margin;

  • cost;

  • growth;

  • customer-acquisition cost;

  • market size;

  • and return on investment.

Those numbers matter.

But organisations ultimately create and deliver value through people.

  • Customers experience products and services.

  • Employees experience processes, systems, incentives, and change.

  • Suppliers experience purchasing practices and relationships.

  • Partners experience governance and operational expectations.

  • Stakeholders experience the effects of organisational decisions.

A strategy can look excellent in a financial model and still fail because:

  • customers do not understand it;

  • users find it difficult;

  • employees cannot deliver it;

  • managers resist it;

  • decision-makers do not trust it;

  • vulnerable customers cannot access it;

  • suppliers cannot support it;

  • or the experience does not solve the real problem.

A recommendation is not implemented when management approves it.

It is implemented when people:

  • notice it;

  • understand it;

  • believe it;

  • try it;

  • adopt it;

  • use it;

  • deliver it;

  • and continue supporting it.

Personas help teams understand who those people are.

Journey maps help teams understand what those people experience.

Together, they connect strategic analysis to human behaviour.

Discover Your MAD Skills Principle

Don’t just describe the customer. Understand the person.

A demographic description might tell you:

Sarah is a 35-year-old urban professional with an annual income of $90,000.

That information may help describe a segment, but it does not explain:

  • what Sarah is trying to accomplish;

  • why she behaves as she does;

  • what frustrates her;

  • what she values;

  • what would make her change;

  • or why she might reject the recommendation.

A useful persona might say:

Sarah is trying to reduce the time and mental effort required to plan weekday meals. She values reliability and convenience more than the lowest price. She is frustrated when deliveries arrive late because one failure disrupts her entire evening. She will try a new service if setup is simple, but she will cancel quickly if the service creates more work than it removes.

The second description gives the team something to solve.

A useful human-insight progression is:

Person → Goal → Barrier → Behaviour → Design implicationimplication.

Customer Segments and Personas Are Different

A customer segment is a group of people or organisations that share relevant characteristics, needs, behaviours, or economics.

A persona is a research-based representation of a person within a priority segment.

Customer Segment

Time-constrained urban professionals who purchase meal solutions at least three times per week.

Persona

Sarah is a project manager who arrives home at inconsistent times. She wants fresh meals but dislikes planning, shopping, and food waste. She is comfortable ordering digitally but expects delivery information to be accurate. She will pay more for reliability but avoids long subscription commitments.

The segment helps the organisation determine:

  • how large the opportunity is;

  • how customers differ;

  • which group to prioritise;

  • and whether the economics are attractive.

The persona helps the team understand:

  • motivations;

  • context;

  • behaviour;

  • emotions;

  • barriers;

  • and adoption.

Segmentation and personas should support one another.

A persona should represent a meaningful pattern within a segment—segment, not an imaginary average customer.

A Persona Is Not a Fictional Biography

A persona does not need:

  • a favourite television program;

  • a photograph;

  • a detailed family history;

  • a made-up quotation;

  • or an elaborate name

unless that information changes the analysis.

Decorative detail can make a persona appear realistic without making it useful.

Include only information that helps answer the case question.

The central test is:

Does this characteristic help us understand the person’s need, behaviour, decision, or experience? 

If it does not, remove it.

Evidence-Based and Provisional Personas

A persona should be grounded in evidence such as:

  • customer interviews;

  • surveys;

  • transaction data;

  • complaints;

  • reviews;

  • usage patterns;

  • observational research;

  • employee feedback;

  • case facts;

  • market research;

  • and stakeholder interviews.

In a case competition, the evidence may be limited.

The team can still develop a provisional persona, but it should distinguish:

  • evidence;

  • reasonable inference;

  • and assumption.

Example

Persona element Evidence status
Customers report frustration with late delivery Supported by survey
Time-constrained professionals have the highest order frequency Supported by transaction data
Customers will pay 10% more for guaranteed delivery Assumption requiring testing
Customers prefer text alerts to email Inference based on current usage

This protects the team from presenting an invented story as research.

Confidence Questions

Ask:

  • Which persona characteristics are strongly supported?

  • Which are inferred?

  • Which are assumptions?

  • What could be tested?

  • Which assumption would most affect the solution?

  • Is the persona representative of an important group?

What Makes a Useful Persona?

A practical persona may include the following elements.

Role and Context

Who is this person, and what situation are they in?

Include only relevant context.

Goal

What is the person trying to accomplish?

The goal should be expressed from the person’s perspective.

For example:

Prepare healthy weekday meals without spending significant time planning and shopping.

Motivation

Why does the goal matter?

Possible motivations include:

  • saving time;

  • reducing stress;

  • protecting family wellbeing;

  • feeling competent;

  • gaining status;

  • reducing risk;

  • maintaining independence;

  • fulfilling a responsibility;

  • or improving financial security.

Pain Points

What creates frustration, delay, risk, confusion, cost, or emotional difficulty?

Behaviours

What does the person currently do?

Include:

  • habits;

  • workarounds;

  • channel use;

  • purchasing behaviour;

  • information seeking;

  • and responses to failure.

Values

What principles or outcomes shape the person’s decisions?

Examples include:

  • convenience;

  • affordability;

  • trust;

  • autonomy;

  • privacy;

  • sustainability;

  • personal service;

  • quality;

  • and fairness.

Barriers

What prevents the person from adopting or succeeding?

Barriersarriers may be:

  • financial;

  • physical;

  • emotional;

  • informational;

  • technological;

  • organisational;

  • social;

  • or behavioural.

Triggers

What event or condition causes the person to act?

Examples include:

  • a service failure;

  • a life change;

  • a recommendation;

  • a price increase;

  • a deadline;

  • a new responsibility;

  • or frustration with the current alternative.

Concerns or Objections

Why might the person reject the solution?

Trust

Whom or what does the person trust?

Channels

Where does the person seek information, make decisions, purchase, use the service, and request support?

Success

What does a good outcome look like from the person’s perspective?

Jobs to Be Done

Another way to strengthen a persona is to ask:

What is this person trying to get done? 

A person does not purchase a product only because of its features.

They may be trying to achieve a functional, emotional, or social outcome.

Functional Job

What practical task must be completed?

Prepare dinner quickly.

Emotional Job

How does the person want to feel?

Feel less overwhelmed at the end of the day.

Social Job

How does the person want to be perceived?

Feel like a responsible parent providing healthy meals.

A meal-kit solution that addresses only the functional task may overlook the emotional value.

Multiple Personas

One persona may be sufficient when:

  • one segment clearly dominates the decision;

  • customer needs are relatively similar;

  • and the recommendation affects users in similar ways.

Multiple personas may be necessary when:

  • customer segments have conflicting needs;

  • the buyer and user are different;

  • employees and customers experience the solution differently;

  • adoption depends on several decision-makers;

  • or vulnerable groups face different barriers.

Do not create many personas simply to appear thorough.

Each persona should reveal a meaningful difference that changes:

  • the value proposition;

  • channel;

  • relationship;

  • solution;

  • implementation;

  • or risk response.

B2B and Organisational Personas

In business-to-business, government, healthcare, and education cases, the “customer” may consist of several people.

A purchasing decision may involve:

User

The person who uses the product or service.

Buyer

The person or department responsible for purchasing.

Decision-Maker

The person with authority to approve the decision.

Influencer

The person whose expertise or opinion shapes the decision.

Gatekeeper

The person or function controlling access, compliance, information, or procurement.

Economic Sponsor

The person accountable for the budget or financial outcome.

These stakeholders may want different things.

For example, a hospital technology purchase may involve:

Persona Priority
Nurse Usability and patient care
Physician Clinical quality and reliability
IT leader Security and integration
Procurement Cost and contractual terms
Executive Strategic and financial value
Regulator Safety and compliance

A solution that satisfies the executive but frustrates the user may fail during adoption.

Employee and Stakeholder Personas

Personas are not limited to external customers.

An employee persona may help the team understand:

  • workload;

  • incentives;

  • concerns;

  • professional identity;

  • skills;

  • trust;

  • and resistance to change.

A supplier persona may reveal:

  • margin pressure;

  • demand uncertainty;

  • information needs;

  • cash-flow concerns;

  • and reasons for cooperation or resistance.

A community persona may reveal:

  • local priorities;

  • lived experience;

  • historical trust;

  • and the consequences of the recommendation.

The persona selected should match the question.

Personas Should Reveal Tensions

Useful personas often contain tensions.

Examples include:

  • values convenience but distrusts data collection;

  • wants personal service but is highly price-sensitive;

  • supports sustainability but resists changing behaviour;

  • wants innovation but fears job loss;

  • wants more responsibility but has little time;

  • values local products but expects consistent availability.

These tensions create more realistic solutions.

A persona should not be designed merely to agree with the recommendation.

Deciphering Case Characteristics

Personas are especially useful when:

  • customer behaviour is central;

  • segments have different needs;

  • customer adoption is uncertain;

  • a new product or service is being introduced;

  • the recommendation changes the customer experience;

  • employee behaviour matters;

  • stakeholder resistance is likely;

  • accessibility is important;

  • trust affects the decision;

  • the buyer and user are different;

  • or the solution depends on behaviour change.

Personas may add less value when:

  • the decision is primarily technical;

  • stakeholders have similar needs;

  • or sufficient customer evidence does not exist.

The tool should clarify a decision—decision, not decorate the presentation.

Persona-to-Solution Translation

After creating the persona, identify its design implications.

Persona insight Solution implication
Values reliability over lowest price Compete on dependable delivery rather than discounting
Has limited time for setup Create short onboarding and guided defaults
Distrusts automatic renewal Use transparent terms and reminders
Needs human reassurance for complex decisions Preserve access to specialist support
Uses mobile communication throughout the day Prioritise mobile notifications
Fears losing professional autonomy Involve employees in process design and preserve judgement

A persona becomes useful when it changes a choice.

What Is a Journey Map?

A journey map shows what a person experiences over time while trying to achieve a goal.

  • A persona answers:

    Who are we solving for?

  • A journey answers:

    What happens to them?

The journey may involve a:

  • customer;

  • user;

  • employee;

  • supplier;

  • patient;

  • student;

  • donor;

  • partner;

  • or other stakeholder.

The stages should reflect the actual experience rather than a generic template.

Defining the Journey

Before mapping, specify:

  • the persona;

  • the goal;

  • the starting point;

  • the end point;

  • the situation;

  • the channel or channels;

  • and whether the map shows the current or proposed experience.

For example:

Sarah’s journey from deciding what to prepare for dinner through ordering, receiving, cooking, and deciding whether to renew her meal-kit subscription.

This is more useful than:

The customer journey.

Journey Stages

A general purchasing journey might include:

Awareness → Consideration → Decision → Purchase → Use → Support → Retention

Retention.

But not every journey follows this sequence.

Employee Change Journey

Awareness → Understanding → Evaluation → Preparation → Adoption → Practice → ReinforcementReinforcement.

Healthcare Journey

Recognise need → Seek access → Assessment → Treatment → Discharge → Follow-upup.

B2B Purchase Journey

Need recognition → Research → Internal alignment → Procurement → Implementation → Adoption → RenewalRenewal.

Product-Use Journey

Setup → First use → Routine use → Problem → Support → Continued use or exitexit.

Choose stages that reflect the case.

What to Map at Each Stage

At each journey stage, examine the following.

Action

What is the person doing?

Goal

What are they trying to accomplish?

Thought

What questions or concerns are they considering?

Emotion

How might they feel?

Use evidence where possible rather than inventing dramatic emotions.

Touchpoint

Where does the person interact with the organisation?

Examples include:

  • advertising;

  • website;

  • application;

  • store;

  • employee;

  • email;

  • call centre;

  • product;

  • invoice;

  • delivery;

  • or partner.

Pain Point

What creates friction, delay, confusion, effort, cost, risk, or disappointment?

Evidence

What information supports the journey assessment?

Opportunity

What could the organisation improve, remove, simplify, or redesign?

Measure

How would the organisation know the experience improved?

A Practical Journey Table

Stage Action Thought or emotion Touchpoint Pain point Opportunity
Awareness Sees digital advertisement “Is this worth trying?” Social media Value is unclear Lead with time saved and reliability
Evaluation Reviews menu and price “Can I cancel easily?” Website Terms are difficult to find Make commitment and pricing transparent
Onboarding Creates preferences “Why are there so many steps?” Application Setup is too long Use guided defaults
Delivery Waits for order “Will it arrive before dinner?” Text and delivery Updates are inaccurate Provide real-time tracking
First use Prepares meal “This should be easier” Product and instructions Instructions are confusing Simplify and test instructions
Support Reports missing item “Will anyone help?” Chat Slow response Offer immediate recovery options
Renewal Decides whether to continue “Did this reduce my stress?” Application Value is not summarised Show savings, usage, and flexibility

The map makes the experience visible.

Moments That Matter

Not every journey stage has equal importance.

A moment that matters is a point that disproportionately shapes:

  • trust;

  • satisfaction;

  • adoption;

  • retention;

  • safety;

  • or the final decision.

Examples include:

  • first use;

  • first service failure;

  • onboarding;

  • payment;

  • delivery;

  • complaint resolution;

  • renewal;

  • and cancellation.

Ask:

  • Which moment most affects trust?

  • Where is abandonment highest?

  • Which failure is hardest to recover from?

  • Where does the person experience the most effort?

  • Which moment determines whether they continue?

  • Which point offers the greatest opportunity for differentiation?

A solution should focus on the moments that matter—not spread investment equally across the journey.

Frontstage and Backstage

The person experiences the frontstage journey.

The organisation supports that experience through backstage activities.

Frontstage

What the person sees or experiences:

  • website;

  • employee interaction;

  • product;

  • delivery;

  • communication;

  • and support.

Backstage

What enables the experience:

  • forecasting;

  • data;

  • scheduling;

  • employee training;

  • supplier coordination;

  • technology;

  • inventory;

  • policies;

  • and decision-making.

For example:

Customer receives an inaccurate delivery estimate
 ← order data are not integrated
 ← inventory status is delayed
 ← delivery partner receives route information late

late.

The visible customer problem originates in backstage processes.

Connecting the journey to Value Chain and Systems Thinking prevents teams from solving only the surface experience.

Current-State and Future-State Journeys

A current-state journey explains what the person experiences today.

A future-state journey explains how the experience should work under the recommendation.

Current-State Journey

Use it to identify:

  • pain points;

  • confusion;

  • delays;

  • workarounds;

  • emotional highs and lows;

  • failure points;

  • and unmet needs.

Future-State Journey

Use it to show:

  • what changes;

  • how the person learns about the change;

  • how adoption occurs;

  • which touchpoints are redesigned;

  • what support is provided;

  • and what outcome improves.

The future-state journey should not show a perfect experience.

It should identify:

  • new steps;

  • new effort;

  • new risks;

  • and new support requirements.

Journey Mapping as a Solution Test

Apply the recommendation to every relevant stage.

Ask:

  • Where does the person first become aware of the change?

  • Why would they pay attention?

  • What would motivate them to try it?

  • What must they learn?

  • What behaviour must change?

  • What could create confusion?

  • What new effort is required?

  • What happens when something goes wrong?

  • Is human support available?

  • What makes the person continue?

  • What would cause abandonment?

  • How can the organisation recover from failure?

A strategy may appear attractive until the team maps how someone must actually use it.

Adoption Is a Journey

Adoption should not be treated as one moment.

A person may move through:

Awareness → Understanding → Interest → Trial → First use → Repeated use → Habit → Advocacy

Advocacy.

At each stage, different barriers may appear.

Adoption stage Possible barrier Possible response
Awareness Person does not know the solution exists Targeted communication
Understanding Value is unclear Simple benefit explanation
Interest Risk feels too high Trial or guarantee
Trial Setup requires too much effort Guided onboarding
First use Experience fails Immediate support and recovery
Repeated use Value is inconsistent Reliability and reminders
Habit Existing routines remain easier Integrate into current behaviour
Advocacy Little reason to recommend Referral or community mechanism

This is particularly important for:

  • new technology;

  • employee change;

  • subscriptions;

  • healthcare interventions;

  • and behaviour-dependent strategies.

Accessibility and Inclusion

A journey that works for the “average” user may exclude others.

Ask:

  • Can people with disabilities use the solution?

  • Does it require reliable internet or a modern device?

  • Is the language understandable?

  • Does it assume high digital confidence?

  • Can people access human support?

  • Does the journey impose greater effort on some groups?

  • Are payment methods accessible?

  • Does the solution accommodate different schedules, locations, languages, or abilities?

  • Who drops out because the journey was designed around a narrow persona?

Inclusive design should be considered during solution development—development, not added after launch.

Emotional Experience

Emotions matter when they influence behaviour.

Examples include:

  • anxiety during a financial decision;

  • frustration during a service failure;

  • confusion during onboarding;

  • embarrassment when asking for help;

  • relief after resolution;

  • or trust after reliable delivery.

However, teams should not invent emotional detail without evidence.

Use:

  • interviews;

  • complaints;

  • observations;

  • survey comments;

  • behavioural data;

  • or clearly labelled hypotheses.

The purpose is not to make the journey dramatic.

It is to understand how emotion affects:

  • choice;

  • effort;

  • trust;

  • adoption;

  • and retention.

Journey Measures

Measures should be connected to stages and moments that matter.

Awareness

  • reach;

  • message recall;

  • traffic;

  • and qualified interest.

Consideration

  • engagement;

  • information completion;

  • time to decision;

  • and abandonment.

Purchase or Enrolment

  • conversion;

  • application completion;

  • payment failure;

  • and acquisition cost.

Onboarding

  • completion;

  • time to first value;

  • support requests;

  • and early abandonment.

Use

  • usage;

  • task completion;

  • reliability;

  • error;

  • and customer effort.

Support

  • response time;

  • resolution;

  • repeat contact;

  • satisfaction;

  • and recovery.

Retention

  • renewal;

  • churn;

  • repeat purchase;

  • lifetime value;

  • and referral.

Metrics help distinguish an attractive journey diagram from an improved real-world experience.

Deciphering Case Characteristics

Personas and journeys are particularly useful when:

  • customer behaviour drives the decision;

  • different segments have different needs;

  • adoption is uncertain;

  • a new service or channel is being introduced;

  • the recommendation changes the experience;

  • employee behaviour determines implementation;

  • vulnerable users may face barriers;

  • stakeholder resistance is likely;

  • a purchase involves several decision-makers;

  • or the problem occurs across several touchpoints.

Growth Cases

Use personas to identify:

  • which customers to prioritise;

  • what unmet need exists;

  • and how the value proposition should change.

Use journeys to identify:

  • acquisition barriers;

  • conversion problems;

  • onboarding;

  • and retention opportunities.

Digital Transformation Cases

Use personas to examine:

  • digital confidence;

  • trust;

  • privacy;

  • accessibility;

  • and need for human support.

Use journeys to determine which interactions should be:

  • automated;

  • redesigned;

  • simplified;

  • or preserved as human.

Employee-Change Cases

Use employee personas to understand:

  • workload;

  • fear;

  • motivation;

  • professional identity;

  • incentives;

  • and capability.

Use adoption journeys to design:

  • communication;

  • participation;

  • training;

  • support;

  • and reinforcement.

B2B Cases

Map:

  • user;

  • buyer;

  • decision-maker;

  • influencer;

  • procurement;

  • and implementation stakeholders.

Public and Not-for-Profit Cases

Include:

  • beneficiaries;

  • funders;

  • service users;

  • frontline employees;

  • and community stakeholders.

The person receiving value may not be the person paying for it.

A Worked Example

Return to the regional meal-kit company examined in earlier chapters.

The company plans to launch a partnership-led pilot in a new city.

The Priority Segment

The initial target segment is:

Time-constrained urban professionals and families who want convenient weekday meals and value local ingredients.

That segment remains too broad for solution design.

The team develops two provisional personas.

Persona One: Sarah—Sarah, the Reliability Seeker

Context

Sarah is a project manager with an unpredictable work schedule. She orders meal solutions several times per week.

Goal

Prepare fresh weekday dinners without planning, shopping, or wasting ingredients.

Motivation

She wants to reduce evening stress while maintaining a feeling of healthy, responsible eating.

Pain Points

  • delivery windows are unreliable;

  • subscriptions feel inflexible;

  • onboarding takes too long;

  • late changes are difficult;

  • and one failed delivery disrupts the entire evening.

Values

  • convenience;

  • reliability;

  • transparency;

  • quality;

  • and flexibility.

Behaviour

  • orders through mobile;

  • checks reviews;

  • compares commitment terms;

  • abandons services after repeated failures;

  • and will pay more for dependable delivery.

Barriers

  • distrust of subscriptions;

  • concern about delivery reliability;

  • and uncertainty about whether the meals fit her schedule.

Solution Implication

The pilot should emphasise:

  • flexible plans;

  • accurate delivery updates;

  • easy skipping;

  • rapid onboarding;

  • and reliability rather than discounting.

Persona Two: Daniel—Daniel, the Local-Value Buyer

Context

Daniel is a parent who wants convenient meals but also wants purchasing decisions to support regional producers.

Goal

Provide convenient family meals while buying locally where possible.

Motivation

He values community impact, ingredient transparency, and family involvement. 

Pain Points

  • “local” claims are often vague;

  • family preferences differ;

  • packaging feels wasteful;

  • and premium products are sometimes too expensive.

Values

  • local economic impact;

  • transparency;

  • affordability;

  • sustainability;

  • and family suitability.

Behaviour

  • researches ingredient origin;

  • reads packaging information;

  • responds to producer stories;

  • and looks for family-size value.

Barriers

  • price;

  • packaging waste;

  • and concern that local supply will be inconsistent.

Solution Implication

The pilot should include:

  • supplier transparency;

  • family options;

  • clear value;

  • packaging reduction;

  • and credible local-product stories.

The Current Journey

The team maps Sarah’s current experience.

Awareness

Sarah sees a digital advertisement.

  • Thought: “This could save time, but every service says that.”

  • Pain point: The message does not prove reliability.

Evaluation

She examines menus, pricing, delivery times, and cancellation terms.

  • Thought: “How difficult is it to skip or cancel?”

  • Pain point: Commitment terms require several clicks to find.

Registration

She creates an account and enters preferences.

  • Thought: “Why does this require so many steps?”

  • Pain point: The process asks for information before she has experienced value.

Order

She selects meals and a delivery window.

  • Thought: “Will this fit my changing schedule?”

  • Pain point: Delivery options are limited.

Delivery

The order is delayed, but updates remain vague.

  • Thought: “I could have shopped in less time than this.”

  • Pain point: The service has failed at the moment convenience matters most.

Preparation

One ingredient is missing.

  • Thought: “Now I still need to visit a store.”

  • Pain point: One operational error removes the core value proposition.

Support

She enters an automated support flow.

  • Thought: “I need a solution, not a chatbot loop.”

  • Pain point: Recovery is slow and impersonal.

Renewal

She considers cancelling.

  • Thought: “This created more stress than it removed.”

  • Pain point: The company offers loyalty points without addressing the failure.

The Critical Moments

The team identifies three moments that matter most:

  1. evaluating flexibility and commitment;

  2. receiving a reliable delivery;

  3. recovering from a service failure.

These moments influence trust, adoption, and retention.

The Proposed Journey

Evaluation

  • show flexible commitment terms prominently;

  • provide a delivery-reliability guarantee;

  • and explain the local value proposition clearly.

Registration

  • request only essential information;

  • use guided defaults;

  • and allow preferences to develop after the first order.

Delivery

  • provide real-time updates;

  • allow delivery-window changes before a clear cut-off;

  • and establish partner service standards.

Preparation

  • simplify instructions;

  • verify ingredient completeness;

  • and provide substitution guidance.

Support

  • identify service failures automatically;

  • offer immediate credit or replacement;

  • and provide human escalation.

Renewal

  • summarise meals, time saved, local purchases, and plan flexibility;

  • ask for targeted feedback;

  • and allow easy plan adjustment.

Backstage Requirements

The future journey requires:

  • integrated order and delivery data;

  • accurate inventory;

  • supplier-quality standards;

  • customer-service authority;

  • partner service-level agreements;

  • and employee training.

The customer journey has now influenced the operating model and implementation plan.

Testing the Journey

The pilot will measure:

  • registration completion;

  • time to first order;

  • delivery reliability;

  • ingredient accuracy;

  • support resolution;

  • customer effort;

  • eight-week retention;

  • plan-skipping;

  • and willingness to recommend.

The persona and journey have transformed a broad market-entry idea into a humanly realistic solution.

Personas and Journeys Are Not the Recommendation

Creating a persona or journey does not determine what the organisation should do.

A complete process is:

  1. define the decision;

  2. identify the priority segment or stakeholder;

  3. collect and assess evidence;

  4. build a focused persona;

  5. identify goals, motivations, behaviours, values, and barriers;

  6. map the current journey;

  7. identify critical moments and backstage causes;

  8. generate solution opportunities;

  9. design the future journey;

  10. test adoption, accessibility, and operational feasibility;

  11. develop and compare strategic alternatives;

  12. select the recommendation; and

  13. measure the experience during implementation.

Personas and journeys make the solution humanly realistic.

They do not replace financial, strategic, operational, or capability analysis.

Winning the Room: Presenting Personas and Journeys

A persona slide filled with stock photography and fictional detail rarely creates insight.

The judges need to understand:

  • who matters;

  • what they are trying to accomplish;

  • what prevents them;

  • and how that changes the recommendation.

Lead with the Human Insight

For example:

Our priority customer is not seeking the lowest-priced meal kit. She is trying to remove uncertainty and stress from weekday meal preparation.

Show Only Relevant Persona Elements

Include:

  • goal;

  • motivation;

  • pain point;

  • adoption barrier;

  • and design implication.

Focus the Journey

Do not show every possible touchpoint.

Show the critical journey:

Evaluation → Delivery → Service recovery → RenewalRenewal.

Connect Insight to Solution

For example:

Because one failed delivery destroys the core convenience promise, our recommendation prioritises reliability, transparent updates, and immediate recovery before introducing loyalty rewards.

Connect the Journey to Implementation

Explain what must change behind the experience:

  • data;

  • partner standards;

  • employee authority;

  • inventory;

  • and performance measures.

The analytical chain becomes:

Human need → Journey friction → Critical moment → Solution design → Operational requirementrequirement.

Coach’s Lens

A persona should not exist simply to make the presentation look more human.

It should change the team’s thinking.

  • If customers value convenience more than price, the recommendation may shift away from discounting.

  • If employees fear losing professional judgement, the implementation may preserve human decision rights.

  • If buyers value financial return but users value ease of use, the solution must satisfy both.

  • If the greatest pain occurs after purchase, spending more on acquisition may not solve the problem.

The test is simple:

Did the persona or journey change what we would recommend or how we would implement it? 

If not, ask whether the tool added value.

I often ask teams:

What is this person trying to accomplish—accomplish, and where does our solution make that easier? 

If the answer is unclear, the solution may still be designed around the organisation rather than the person.

Common Mistakes

1.
  • Demographics Without Insight

Insight: 

Age, income, and location do not automatically explain behaviour.

Improve it: Focus on goals, motivations, values, barriers, and context.

2.
  • Creating a Fictional Biography

    • Biography: 

    Decorative detail makes the persona appear realistic without improving the analysis.

    Improve it: Include only decision-relevant information.

    3.
  • Inventing Evidence

    • Evidence: 

    The team presents assumptions as though they came from research.

    Improve it: Distinguish evidence, inference, and assumption.

    4.
  • Creating the Average Customer

    • Customer: 

    The persona combines conflicting characteristics into one unrealistic person.

    Improve it: Build personas around meaningful behavioural patterns.

    5.
  • Creating Too Many Personas

    • Personas: 

    The analysis becomes fragmented.

    Improve it: Focus on personas whose differences change the solution.

    6.
  • Ignoring Buyers and Decision-Makers

    • Makers: 

    The team focuses only on the user.

    Improve it: Identify buyers, users, influencers, gatekeepers, and sponsors.

    7.
  • Designing a Persona That Agrees with the Solution

    • Solution: 

    The persona becomes evidence created after the recommendation.

    Improve it: Build the persona from case evidence before selecting the solution.

    8.
  • Making the Persona Decorative

    • Decorative: 

    The persona appears in the presentation but does not influence strategy.

    Improve it: Translate every important insight into a design or implementation implication.

    9.
  • Using a Generic Journey

    • Journey: 

    The team automatically uses Awareness, Consideration, Purchase, and Retention.

    Improve it: Define stages based on the person’s actual goal and experience.

    10.
  • Mapping Touchpoints Without Experience

    • Experience: 

    The map lists interactions but not what happens to the person.

    Improve it: Include actions, thoughts, barriers, evidence, and outcomes.

    11.
  • Inventing Emotions

    • Emotions: 

    The team assumes how people feel without evidence.

    Improve it: Support emotional insights or label them as hypotheses.

    12.
  • Treating Every Journey Stage Equally

    • Equally: 

    Resources are spread across the entire journey.

    Improve it: Identify moments that matter.

    13.
  • Ignoring Backstage Causes

    • Causes: 

    The team redesigns communication but not the operations causing the problem.

    Improve it: Connect frontstage experience to systems, people, data, and processes.

    14.
  • Showing a Perfect Future Journey

    • Journey: 

    New effort, barriers, and risks disappear from the proposed experience.

    Improve it: Test the future journey realistically.

    15.
  • Ignoring Accessibility

    • Accessibility: 

    The journey works only for a narrow “average” user.

    Improve it: Examine different abilities, languages, devices, schedules, and access conditions.

    16.
  • Treating Adoption as One Event

    • Event: 

    The team assumes awareness creates use.

    Improve it: Map awareness, trial, first use, repeated use, and retention.

    17.
  • Ignoring Failure and Recovery

    • Recovery: 

    The journey assumes everything works.

    Improve it: Design what happens when the product, service, technology, or partner fails.

    Mad

    MAD Skills Drill: From Persona to Solution Opportunity

    Drill

    Choose the most important customer, employee, user, or stakeholder in a case.

    Step 1: Define the Decision

    What recommendation or design question are you trying to answer?

    Step 2: Identify the Segment

    Describe the relevant group using:

    • behaviour;

    • need;

    • context;

    • and economic or strategic importance.

    Step 3: Build the Persona

    Include:

    • role and context;

    • goal;

    • functional, emotional, and social needs;

    • motivations;

    • pain points;

    • behaviours;

    • values;

    • barriers;

    • triggers;

    • trust;

    • channels;

    • and definition of success.

    Step 4: Label the Evidence

    For each important characteristic, identify whether it is:

    • supported;

    • inferred;

    • or assumed.

    Step 5: Map the Current Journey

    For each stage, identify:

    • action;

    • goal;

    • thought;

    • emotion where supported;

    • touchpoint;

    • pain point;

    • evidence;

    • and measure.

    Step 6: Identify Moments That Matter

    Select the three points that most influence:

    • trust;

    • adoption;

    • satisfaction;

    • retention;

    • or resistance.

    Step 7: Find the Backstage Causes

    For each critical pain point, identify the:

    • process;

    • system;

    • capability;

    • policy;

    • employee role;

    • or partner relationship producing it.

    Step 8: Generate Opportunities

    Ask how the organisation might:

    • remove the pain point;

    • reduce effort;

    • increase trust;

    • create value;

    • support adoption;

    • or recover from failure.

    Step 9: Design the Future Journey

    Apply the proposed solution.

    Identify:

    • what changes;

    • what the person must do differently;

    • what new barrier could emerge;

    • what support is required;

    • and how success will be measured.

    Step 10: Test the Solution

    Ask:

    • Is it desirable?

    • Is it accessible?

    • Is it operationally feasible?

    • Does it fit the organisation?

    • Will the person adopt it?

    • What assumption should be tested?

    Step 11: Deliver the Insight

    Prepare a 60-second explanation answering:

    1. Who are we solving for?

    2. What are they trying to accomplish?

    3. What is preventing them?

    4. Where is the most important journey failure?

    5. How does the solution improve that moment?

    6. What must change behind the experience?

    Do not read the entire persona. Present the human insight that changed the solution.

    Reflection Questions

    1. Did your team describe a demographic group or understand a person?

    2. Which persona characteristic was most important to the decision?

    3. Which characteristics were supported by evidence?

    4. Which were assumptions?

    5. Did the buyer and user have different needs?

    6. Where did the greatest journey friction occur?

    7. What backstage activity created that friction?

    8. Which moment most affected adoption or retention?

    9. What new pain point could your proposed solution create?

    10. Did the persona or journey change the recommendation?

    11. Did the journey account for accessibility and failure?

    12. What evidence should be gathered during a pilot?

    Chapter Summary

    Personas and journeys bring the human side of the case into solution development.

    • A persona helps teams understand:

      Who are we solving for?

    • A journey helps teams understand:

      What do they experience?

    Strong human-centred analysis follows this progression:

    Evidence → Persona → Goal or barrier → Current journey → Critical moment → Solution design → Adoption testtest.

    A useful persona goes beyond demographics to explain:

    • goals;

    • motivations;

    • behaviours;

    • values;

    • pain points;

    • barriers;

    • and context.

    A useful journey goes beyond listing touchpoints to explain:

    • what the person does;

    • thinks;

    • experiences;

    • and needs at each stage.

    Together, personas and journeys help teams test whether a solution is:

    • desirable;

    • accessible;

    • adoptable;

    • operationally feasible;

    • and humanly realistic.

    A weak persona describes a fictional person.

    A strong persona changes the solution.

    A weak journey shows a process.

    A strong journey reveals where and how value shouldmust be created.

    Key Takeaways

    ✓ A customer segment defines a group; a persona represents a meaningful behavioural pattern within that group.

    ✓ A useful persona is more than a demographic profile.

    ✓ Focus on goals, motivations, behaviours, values, pain points, barriers, triggers, trust, and context.

    ✓ Include only persona details that affect the decision.

    ✓ Ground personas in evidence and distinguish facts, inferences, and assumptions.

    ✓ Create multiple personas only when their differences change the solution or implementation.

    ✓ In B2B decisions, distinguish users, buyers, decision-makers, influencers, gatekeepers, and economic sponsors.

    ✓ Personas can represent customers, employees, managers, suppliers, partners, or other stakeholders.

    ✓ A persona explains who; a journey explains what happens to them.

    ✓ Define the person, goal, beginning, end, and context before mapping the journey.

    ✓ At each stage, examine actions, thoughts, touchpoints, pain points, evidence, opportunities, and measures.

    ✓ Focus on moments that disproportionately affect trust, adoption, satisfaction, and retention.

    ✓ Connect visible experiences to backstage systems, processes, capabilities, employees, and partners.

    ✓ Map both the current and proposed journey.

    ✓ Treat adoption as a journey from awareness through repeated use—not as a single event.

    ✓ Design for service failure and recovery.

    ✓ Consider accessibility and inclusion rather than designing only for an average user.

    ✓ Use personas and journeys to generate and test strategic alternatives.

    ✓ In the presentation, communicate the human insight and critical journey moment that changed the recommendation.

    Looking Ahead

    Understanding the person helps define what the solution must accomplish.

    The next challenge is to determine:

    What different strategic paths could solve that problem? 

    The next chapter introduces Strategic AlternativesAlternatives, —how to move beyond minor variations, develop genuinely different courses of action, and give the recommendation something meaningful to be chosen against.

    Back to top