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;
  • 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;
  • 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 don't understand it;
  • users find it difficult;
  • employees cannot deliver it;
  • managers resist it;
  • decision-makers don't trust it;
  • vulnerable customers cannot access it;
  • suppliers cannot support it;
  • the experience doesn't 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;
  • 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 doesn't explain:

  • what Sarah is trying to accomplish;
  • why she behaves as she does;
  • what frustrates her;
  • what she values;
  • what would make her change;
  • 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 a single delay 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 Implication.

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 accurate delivery information. 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;
  • whether the economics are attractive.

The persona helps the team understand:

  • motivations;
  • context;
  • behaviour;
  • emotions;
  • barriers;
  • adoption.

Segmentation and personas should support one another. A persona should represent a meaningful pattern within a segment, not an imaginary average customer.

A Persona Is Not a Fictional Biography

A persona doesn't need:

  • a favourite television program;
  • a photograph;
  • a detailed family history;
  • a made-up quotation;
  • 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 whether this characteristic helps us understand the person's needs, behaviour, decisions, or experiences; if it doesn't, 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;
  • 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;
  • 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? Goals must be expressed from the person's perspective. For example, prepare healthy weekday meals without spending significant time on 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;
  • 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;
  • responses to failure.

Values

What principles or outcomes shape the person's decisions? Examples include:

  • convenience;
  • affordability;
  • trust;
  • autonomy;
  • privacy;
  • sustainability;
  • personal service;
  • quality;
  • fairness.

Barriers

What prevents the person from adopting or succeeding? Barriers may be:

  • financial;
  • physical;
  • emotional;
  • informational;
  • technological;
  • organisational;
  • social;
  • 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;
  • 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 the service, 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 doesn't purchase a product only because of its features. They may be trying to achieve a functional, emotional, or social outcome.

·        Functional Job

o   What practical task must be completed? Prepare dinner quickly.

·        Emotional Job

o   How does the person want to feel? Feel less overwhelmed at the end of the day.

·        Social Job

o   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;
  • 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;
  • vulnerable groups face different barriers.

Don't create many personas to appear thorough. Each persona should reveal a meaningful difference that changes:

  • the value proposition;
  • channel;
  • relationship;
  • solution;
  • implementation;
  • 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;
  • resistance to change.

A supplier persona may reveal:

  • margin pressure;
  • demand uncertainty;
  • information needs;
  • cash-flow concerns;
  • reasons for cooperation or resistance.

A community persona may reveal:

  • local priorities;
  • lived experience;
  • historical trust;
  • 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;
  • the solution depends on behaviour change.

Personas may add less value when:

  • the decision is primarily technical;
  • stakeholders have similar needs;
  • sufficient customer evidence doesn't exist.

The tool should clarify a 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 as they work toward 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;
  • other stakeholder.

The stages should reflect the actual experience, not 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;
  • 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. Not every journey follows this sequence.

·        Employee Change Journey

o   Awareness → Understanding → Evaluation → Preparation → Adoption → Practice → Reinforcement

·        Healthcare Journey

o   Recognise need → Seek access → Assessment → Treatment → Discharge → Follow-up

·        B2B Purchase Journey

o   Need recognition → Research → Internal alignment → Procurement → Implementation → Adoption → Renewal

·        Product-Use Journey

o   Setup → First use → Routine use → Problem → Support → Continued use or exit

Choose stages that reflect the case.

What to Map at Each Stage

At each stage of the journey, 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?

o   Examples include:

o   advertising;

o   website;

o   application;

o   store;

o   employee;

o   email;

o   call centre;

o   product;

o   invoice;

o   delivery;

o   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

Commit 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 stage of the journey is equally important.

A moment that matters is a point that disproportionately shapes:

  • trust;
  • satisfaction;
  • adoption;
  • retention;
  • safety;
  • the final decision.

Examples include:

  • first use;
  • first service failure;
  • onboarding;
  • payment;
  • delivery;
  • complaint resolution;
  • renewal;
  • 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;
  • support.

Backstage

What enables the experience:

  • forecasting;
  • data;
  • scheduling;
  • employee training;
  • supplier coordination;
  • technology;
  • inventory;
  • policies;
  • 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. 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;
  • 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;
  • what outcome improves.

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

  • new steps;
  • new effort;
  • new risks;
  • 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. At each stage, different barriers may appear.

Adoption stage

Possible barrier

Possible response

Awareness

Person doesn't 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;
  • 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 require greater effort by 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 must be considered during solution 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;
  • trust after reliable delivery.

However, teams should not invent emotional detail without evidence. Use:

  • interviews;
  • complaints;
  • observations;
  • survey comments;
  • behavioural data;
  • clearly labelled hypotheses.

The purpose is not to make the journey dramatic. It is to understand how emotion affects:

  • choice;
  • effort;
  • trust;
  • adoption;
  • retention.

Journey Measures

Measures should be connected to stages and moments that matter.

·        Awareness

o   reach;

o   message recall;

o   traffic;

o   and qualified interest.

o   Consideration

o   engagement;

o   information completion;

o   time to decision;

o   abandonment.

·        Purchase or Enrolment

o   conversion;

o   application completion;

o   payment failure;

o   and acquisition cost.

o   Onboarding

o   completion;

o   time to first value;

o   support requests;

o   early abandonment.

·        Use

o   usage;

o   task completion;

o   reliability;

o   error;

o   and customer effort.

o   Support

o   response time;

o   resolution;

o   repeat contact;

o   satisfaction;

o   recovery.

·        Retention

o   renewal;

o   churn;

o   repeat purchase;

o   lifetime value;

o   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;
  • the problem occurs across several touchpoints.

Growth Cases

Use personas to identify:

  • which customers to prioritise;
  • what unmet need exists;
  • how the value proposition should change.

Use journeys to identify:

  • acquisition barriers;
  • conversion problems;
  • onboarding;
  • retention opportunities.

Digital Transformation Cases

Use personas to examine:

  • digital confidence;
  • trust;
  • privacy;
  • accessibility;
  • need for human support.

Use journeys to determine which interactions should be:

  • automated;
  • redesigned;
  • simplified;
  • preserved as human.

Employee-Change Cases

Use employee personas to understand:

  • workload;
  • fear;
  • motivation;
  • professional identity;
  • incentives;
  • capability.

Use adoption journeys to design:

  • communication;
  • participation;
  • training;
  • support;
  • reinforcement.

B2B Cases

Map:

  • user;
  • buyer;
  • decision-maker;
  • influencer;
  • procurement;
  • implementation stakeholders.

Public and Not-for-Profit Cases

Include:

  • beneficiaries;
  • funders;
  • service users;
  • frontline employees;
  • 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, the Reliability Seeker

·        Context

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

·        Goal

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

·        Motivation

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

·        Pain Points

o   delivery windows are unreliable;

o   subscriptions feel inflexible;

o   onboarding takes too long;

o   late changes are difficult;

o   one failed delivery disrupts the entire evening.

·        Values

o   convenience;

o   reliability;

o   transparency;

o   quality;

o   flexibility.

·        Behaviour

o   orders through mobile;

o   checks reviews;

o   compares commitment terms;

o   abandons services after repeated failures;

o   will pay more for dependable delivery.

·        Barriers

o   distrust of subscriptions;

o   concern about delivery reliability;

o   uncertainty about whether the meals fit her schedule.

·        Solution Implication

o   The pilot should emphasise:

o   flexible plans;

o   accurate delivery updates;

o   easy skipping;

o   rapid onboarding;

o   reliability rather than discounting.

Persona Two: Daniel, the Local-Value Buyer

·        Context

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

·        Goal

o   Provide convenient family meals while buying locally where possible.

·        Motivation

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

·        Pain Points

o   "local" claims are often vague;

o   family preferences differ;

o   packaging feels wasteful;

o   premium products are sometimes too expensive.

·        Values

o   local economic impact;

o   transparency;

o   affordability;

o   sustainability;

o   family suitability.

·        Behaviour

o   researches ingredient origin;

o   reads packaging information;

o   responds to producer stories;

o   looks for family-size value.

·        Barriers

o   price;

o   packaging waste;

o   concern that local supply will be inconsistent.

·        Solution Implication

o   The pilot should include:

o   supplier transparency;

o   family options;

o   clear value;

o   packaging reduction;

o   credible local-product stories.

The Current Journey

The team maps Sarah's current experience.

·        Awareness

o   Sarah sees a digital advertisement.

o   Thought: "This could save time, but every service says that."

o   Pain point: The message doesn't prove reliability.

·        Evaluation

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

o   Thought: "How difficult is it to skip or cancel?"

o   Pain point: Commitment terms are difficult to find.

·        Registration

o   She creates an account and enters preferences.

o   Thought: "Why does this require so many steps?"

o   Pain point: The process requires information before she has experienced any value.

·        Order

o   She selects meals and a delivery window.

o   Thought: "Will this fit my changing schedule?"

o   Pain point: Delivery options are limited.

·        Delivery

o   The order is delayed, but updates remain vague.

o   Thought: "I could have shopped in less time than this."

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

·        Preparation

o   One ingredient is missing.

o   Thought: "Now I still need to visit a store."

o   Pain point: A single operational error undermines the core value proposition.

·        Support

o   She enters an automated support flow.

o   Thought: "I need a solution, not a chatbot loop."

o   Pain point: Recovery is slow and impersonal.

·        Renewal

o   She considers cancelling.

o   Thought: "This created more stress than it removed."

o   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

o   show flexible commitment terms prominently;

o   provide a delivery-reliability guarantee;

o   clearly explain the local value proposition.

·        Registration

o   request only essential information;

o   use guided defaults;

o   allow preferences to develop after the first order.

·        Delivery

o   provide real-time updates;

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

o   establish partner service standards.

·        Preparation

o   simplify instructions;

o   verify ingredient completeness;

o   provide substitution guidance.

·        Support

o   identify service failures automatically;

o   offer immediate credit or replacement;

o   provide human escalation.

·        Renewal

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

o   ask for targeted feedback;

o   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;
  • 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;
  • 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 doesn't 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 don't 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;
  • 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;
  • design implication.

Focus the Journey

Don't show every possible touchpoint; show the critical journey: Evaluation → Delivery → Service recovery → Renewal.

Connect Insight to Solution

For example, because a single failed delivery undermines 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;
  • performance measures.

The analytical chain becomes: Human Need → Journey Friction → Critical Moment → Solution Design → Operational Requirement.

Coach's Lens

A persona should not exist 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 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

·        Demographics Without Insight: Age, income, and location don't automatically explain behaviour. Focus on goals, motivations, values, barriers, and context.

·        Creating a Fictional Biography: Decorative detail makes the persona appear realistic without improving the analysis. Include only decision-relevant information.

·        Inventing Evidence: The team presents assumptions as though they came from research. Distinguish evidence, inference, and assumption.

·        Creating the Average Customer: The persona combines conflicting characteristics into one unrealistic person. Build personas based on meaningful behavioural patterns.

·        Creating Too Many Personas: The analysis becomes fragmented. Focus on personas whose differences drive changes in the solution.

·        Ignoring Buyers and Decision-Makers: The team focuses only on the user. Identify buyers, users, influencers, gatekeepers, and sponsors.

·        Designing a Persona That Agrees with the Solution: The persona becomes evidence created after the recommendation. Build the persona from case evidence before selecting a solution.

·        Making the Persona Decorative: The persona appears in the presentation but doesn't influence strategy. Translate every important insight into a design or implementation implication.

·        Using a Generic Journey: The team automatically uses Awareness, Consideration, Purchase, and Retention. Define stages based on the person's specific goal and experience.

·        Mapping Touchpoints Without Experience: The map lists interactions but not what happens to the person. Include actions, thoughts, barriers, evidence, and outcomes.

·        Inventing Emotions: The team assumes how people feel without evidence. Support emotional insights or label them as hypotheses.

·        Treating Every Stage of the Journey Equally: Resources are distributed across the entire journey. Identify the moments that matter.

·        Ignoring Backstage Causes: The team redesigns communication but not the operations causing the problem. Connect the frontstage experience to systems, people, data, and processes.

·        Showing a Perfect Future Journey: New effort, barriers, and risks disappear from the proposed experience. Test the future journey realistically.

·        Ignoring Accessibility: The journey works only for a narrow "average" user. Examine diverse abilities, languages, devices, schedules, and access conditions.

·        Treating Adoption as a Single Event: The team assumes that awareness creates use. Map awareness, trial, first use, repeated use, and retention.

·        Ignoring Failure and Recovery: The journey assumes everything works. Design what happens when the product, service, technology, or partner fails.

MAD Skills 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;
  • 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;
  • definition of success.

Step 4: Label the Evidence

For each important characteristic, identify whether it is:

  • supported;
  • inferred;
  • assumed.

Step 5: Map the Current Journey

For each stage, identify:

  • action;
  • goal;
  • thought;
  • emotion where supported;
  • touchpoint;
  • pain point;
  • evidence;
  • measure.

Step 6: Identify Moments That Matter

Select the three points that most influence:

  • trust;
  • adoption;
  • satisfaction;
  • retention;
  • resistance.

Step 7: Find the Backstage Causes

For each critical pain point, identify the:

  • process;
  • system;
  • capability;
  • policy;
  • employee role;
  • 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;
  • 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;
  • 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 failure in a journey?
  5. How does the solution improve that moment?
  6. What must change behind the experience?

Don't 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 had the greatest impact on 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 we are solving for.

·        A journey helps teams understand their experiences.

Strong human-centred analysis follows this progression: Evidence → Persona → Goal or Barrier → Current Journey → Critical Moment → Solution Design → Adoption Test. A useful persona goes beyond demographics to explain:

  • goals;
  • motivations;
  • behaviours;
  • values;
  • pain points;
  • barriers;
  • context.

A useful journey goes beyond listing touchpoints to explain:

  • what the person does;
  • thinks;
  • experiences;
  • needs at each stage.

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

  • desirable;
  • accessible;
  • adoptable;
  • operationally feasible;
  • 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 to create value.

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 which strategic paths could solve that problem. The next chapter introduces Strategic Alternatives: how to move beyond minor variations, develop genuinely different courses of action, and give the recommendation something meaningful to be chosen against.