The correct order of CX work

Customer experience work has a correct order: generative research, problem definition, strategy, prioritization, prototyping, testing, delivery, and post-release monitoring. Each step depends on the one before it. Research grounds the problem definition; the problem anchors the strategy; strategy decides what to prioritize; only then do concepts get built, tested, and shipped, with monitoring closing the loop. Most teams know these steps. Far fewer hold the order. The classic failure is starting at the solution and backfilling a strategy to justify what was already built.

Why it matters to the business

Skipping the research step means steering by inside-out assumption, and inside-out views are systematically wrong: Bain's study of 362 firms found 80% believed they delivered a superior experience while only 8% of customers agreed. Getting the sequence right pays where it counts. McKinsey found journey performance correlates 30-40% more strongly with customer satisfaction than performance at any single point of contact, and reports journey improvements lifting revenue 10-15% while cutting cost-to-serve 15-20%.

Skipping the end of the sequence is just as costly. Gartner found 83% of organizations struggle to use journey maps to identify and prioritize CX efforts: research artifacts produced without the prioritization, delivery, and monitoring steps that give them consequence.

How to use it

• Open every initiative with generative research and a written problem definition before any solution work begins.
• Gate build funding: no engineering budget until the problem and strategy documents cite customer evidence.
• Prioritize from strategy, not from the loudest stakeholder; keep the ranked backlog visible.
• Prototype and test before engineering commits; treat internal drafts as hypotheses to validate with customers, never as truth.
• Define post-release measures and name the owner who acts on them before launch, not after.

Where teams get it wrong

Teams experience the sequence as slow and jump ahead to feel fast. The speed is borrowed: it returns as rework, low adoption, and strategic drift, paid back at the most expensive point in the process. Designing solutions before research is guessing, and a strategy written after the build is not a strategy; it is a press release for a decision already made.

Ask your team

• For our biggest current initiative, which came first: the research or the solution?
• Can anyone show me the written problem definition this project answers?
• What are we monitoring post-release, and who owns acting on what it shows?

Strategy without research is fiction.