Stop Solving the Wrong Problems. Start Journey Mapping
- Steven Granese
- 1 day ago
- 5 min read
The leadership team approved a project because it seemed like good idea: customers mentioned wanting specific features in surveys and competitors already offered similar capabilities. After six months of planning, it took the product team about nine months to build, test and deliver the finished product. Everyone paused to applaud the launch and celebrate their big win. However, after the excitement wore down, reality settled in. One month after the new launch, user adoption of new features sat at only 5%. Customer support reports that the complaints and issues followed the same patterns as before, and only increase in volume. The sales team is saying that that new features are not impacting the decisions of new targets. Leadership has moved onto the next project, but nothing seems to be improving.
I've watched this pattern repeat at company after company when product leaders jump straight to identifying new solutions without deeply understanding the problems customers actually face. Too many organizations are in such a rush to crank out new capabilities that they don’t slow down enough to understand where the market is headed and what their customers truly need. What is missing is the art of design thinking, where product leaders create space to explore customer problems and iterate on innovative ways to solve those problems. One of my favorite design thinking techniques is called Customer Journey Mapping. Journey Mapping is a technique that prevents waste by helping product leaders to examine how users engage and experience the services and products of an organization. It works by creating a visual story of every touchpoint a customer encounters, from first awareness through purchase and beyond. The map reveals where customers feel frustrated, confused, or delighted, and more importantly, it shows why those emotions happen. When teams understand the problem deeply, they stop building features and start solving issues that matter.
What A Journey Map Actually Shows
A journey map connects three things that usually live in separate reports: what customers do, what they think, and how they feel. Recently, I worked with a healthcare company where patients rated their overall experience as "poor" but nobody could figure out why. We built a journey map that tracked the entire appointment process from scheduling to follow-up. The map showed that patients felt anxious (emotion) when they couldn't get appointment confirmations (behavior) because they assumed the system had lost their request (thought). Product managers wanted to redesign the scheduling interface, but the journey map revealed the real issue lived three steps later in the confirmation process. The visual format matters because it helps everyone to look at the same customer reality instead of arguing based on their individual departmental perspective. Teams lay out the customer's path horizontally across the top, then stack behaviors, thoughts, and emotions underneath each step. Below that, they add the backstage processes (the internal systems customers never see) that create the experience customers receive.
Front Stage Problems Usually Have Backstage Causes
Customers see a simple booking form, but behind that form sits a mess of legacy systems, third-party integrations, and manual processes that create delays and errors. The healthcare company I mentioned had a three-day delay between when patients requested appointments and when they received confirmations. Patients blamed the website for being broken. Customer service blamed IT for slow systems. IT blamed the third-party scheduling vendor. The journey map showed everyone they were all partially right and completely wrong. Five separate systems had to exchange data before anyone could send a confirmation: the booking system captured the request, the reservation system checked availability, the billing system verified insurance, and then the email system sent confirmation. Each handoff added delay, and any failure meant the whole chain stopped. Once teams map both what customers see (front stage) and what makes it work (backstage), they stop arguing about symptoms and start fixing root causes.
When teams understand the problem deeply, they stop building features and start solving issues that matter.
How To Identify Problems Worth Solving
Teams find dozens of potential issues when they map a customer experience, but the majority don't deserve resources. I look for three characteristics that make a problem compelling:
The problems happens frequently enough to affect lots of customers
The problem creates genuine negative emotions (not mild annoyance)
Our team has the ability to actually fix it!
During one mapping session, a retail team identified 47 different pain points across their shopping experience. We spent two hours debating which ones mattered before I made them apply the three filters. Only five problems were both frequent and painful. Of those five, the team could only control three (the other two required changing vendor contracts that weren't up for renewal). Those three problems became the entire product roadmap for the next quarter. Without the journey map, product managers would have kept prioritizing based on whoever shouted loudest in meetings or whatever the CEO mentioned last. The map creates objective criteria for separating real problems from noise.
Why Validating Problems Matters
I learned the hard way that teams can't skip understanding problems and jump straight to solutions. Early in my career, our team built an entire mobile app based on assumptions about what customers wanted. We spent eight months developing features, designing interfaces, and testing performance. Launch day came, and we got exactly 200 downloads in the first month. Then we did the journey mapping we should have done at the beginning. Customers didn't want a mobile app. They wanted our website to work properly on their phones because they were already on our website when they needed help. We built something nobody asked for because we never mapped their actual experience. This is why understanding comes before solving in any good product process. Teams need to explore the full range of problems customers face (divergent thinking) before they narrow down to the specific one worth solving (convergent thinking). Journey mapping makes this exploration concrete instead of theoretical.
Turning Maps Into Decisions
A beautiful journey map sitting in a slide deck helps nobody, and I've seen too many companies treat mapping as a one-time workshop activity. The map needs to live where teams make daily decisions about what to build and why. I worked with one client that printed their journey map on a 6-foot poster and mounted it on the wall where the product team held sprint planning. Every feature discussion started with two questions: which stage of the customer experience does this improve, and which validated problem does this solve. Product managers who couldn't point to a specific pain point on the map didn't get their features prioritized. This discipline sounds harsh, but it kept the team focused on customer problems instead of interesting technical challenges. Journey maps should be reference tools that get marked up, updated, and argued over. Teams should treat them like living documents that evolve as they learn more about customers and as customer needs change.
Making Journey Mapping Work
Teams don't need expensive consultants or complex software to start journey mapping tomorrow. I've run effective mapping sessions with just sticky notes and a conference room wall. The key is getting representatives from every department that touches the customer: sales, marketing, product, support, operations, and technology. Each person sees different parts of the customer experience, and the map helps everyone understand the entire system. Teams start by listing every touchpoint where customers interact with the company. Under each touchpoint, they write what customers do (observable behaviors), what they think (attitudes and beliefs), and how they feel (emotions). Then they add the backstage processes that create each touchpoint. The gaps between what customers expect and what processes deliver become the problem list. Teams apply the three filters (frequent, painful, solvable) to find compelling problems. Now the team has a roadmap based on validated customer needs instead of internal opinions.
