Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How a CTO Uses Customer Journey Mapping to Align Engineering
Transcript
- Lucas: So a couple of months ago I was talking to a CTO at a B2B SaaS company — about 150 engineers, strong product culture — and he told me they'd stopped doing feature-count standups. Completely. And replaced them with something called journey reviews. Luna: Journey reviews. As in customer journey mapping, brought into the weekly engineering cadence? Lucas: Exactly that. And I'll be honest, my first reaction was — 'that sounds like a workshop you run once and then it collects dust.' But he showed me how they use it as a living system. And the results were pretty striking. Luna: Alright, I'm intrigued. What's the core idea — instead of asking 'what did you ship this week,' you ask 'what did you improve for the user this week'? Lucas: That's exactly it. But the mechanism is more specific. They built a full journey map of their product — every step a user takes from first landing on the site, through signup, onboarding, first value, daily use, renewal, even churn. Each step has a pain-point score — one to five — based on support tickets, session recordings, and NPS comments. And then each sprint, every team picks one pain point from the map to address. Luna: So the journey map is essentially the backlog prioritization tool. That's a pretty big shift from the typical 'here's the feature roadmap from the product team' approach. Lucas: It is. And look, if today's conversation gives you something useful, the reason we can do deep dives like this without ads is listener support. If you want to keep that going, you can find us at buy me a coffee dot com slash fexingo — it's a simple way to back the show. Luna: Yeah, that's genuinely how we stay independent. No sponsors, no pop-ups. Just listeners who find value here. And we really appreciate that. Lucas: So back to the journey map. The CTO I spoke with — let's call him Mark — took a very pragmatic approach. He didn't try to map the entire customer lifecycle in one go. He started with one critical flow: the first seven days from signup. And that's where they found their biggest win. Lucas: They discovered that 12 percent of new users who started the signup process never completed it. And the reason wasn't pricing or feature gaps — it was the password reset flow. To reset a password, users had to go through seven steps, including a confirmation email that sometimes took three minutes to arrive. The journey map made that pain visible because each step had a severity tag. The password reset step was scored a five — highest pain. Luna: Seven steps for a password reset... that's like asking someone to fill out a form before they can get a glass of water. So what did they do? Lucas: They moved it from seven steps to two. Removed the email requirement entirely, used a one-time code sent via SMS, and added a social login option. The result: signup completion rate went from 88 percent to 96 percent in three weeks. And that directly impacted a key business metric — monthly active users grew by 5 percent just from that fix. Luna: And I'm guessing the product team originally had a dashboard rebuild on the roadmap, which was a much sexier project. Lucas: Exactly. The product team had a big initiative to rebuild the analytics dashboard — six months of work, lots of front-end complexity. But the journey map showed that the dashboard wasn't a major pain point. It was rated a two. Meanwhile, the password reset flow was bleeding users. So Mark used the journey map to have a data-backed conversation with the VP of Product: 'We can either build a shiny dashboard that existing users will like, or we can fix a broken door that's losing us 12 percent of new users.' The VP agreed to deprioritize the dashboard. Luna: That takes guts. And it also requires the engineering team to trust that the journey map is the right prioritization tool, not just another management fad. Lucas: Mark told me the key was making the journey map transparent and owned by the whole team. They have a shared Miro board — anyone can add a pain point, tag it with severity, and link it to a support ticket or a session recording. Then every two weeks, they do a journey review — thirty minutes, cross-functional, including a customer success rep and a product manager. They look at the top three pain points by severity and decide which one to tackle next sprint. Luna: So it's not just engineering — it's customer success, product, even sales being in the room. That's a very different dynamic from most sprint planning sessions I've seen. Lucas: It is. And the sales team actually became one of the biggest advocates. Because they were the ones hearing about the password reset frustration from prospects. They had anecdotal data, but the journey map gave them a quantified, shared language. One sales rep told Mark: 'I can finally point to a number and say "this is why we're losing deals at the trial stage." That alignment across teams is probably the biggest win. Luna: What about the initial skepticism? I imagine some engineers were like 'we're spending time mapping instead of coding.' Lucas: Mark said there was definitely pushback at first. A couple of senior engineers argued that the map was 'too high-level' and didn't reflect system complexity. But he framed it differently — he said 'the journey map is a hypothesis. The code is the reality. If the journey map suggests a fix, build it, measure it, and if the pain score doesn't go down, we update the map.' That turned it into a learning tool rather than a bureaucratic artifact. Luna: I like that — treat it as a living model. How often do they update it? Monthly? Lucas: They update the pain scores weekly — based on the latest support ticket volume and NPS data. But the actual map structure — the steps and flows — they revisit quarterly. Because as the product evolves, new touchpoints appear and old ones fade. For example, when they launched a mobile app, they added a whole new branch to the map. Luna: And then the engineering teams can self-organize around the pain points? Or does Mark assign work? Lucas: Mostly self-organizing. During the journey review, they agree on the top priority pain point. Then teams volunteer or are assigned based on skill set. But Mark emphasized that they avoid forcing a team to work on something they don't have context for. If a team doesn't know the codebase for a particular flow, they pair with a team that does. That cross-pollination has actually reduced silos over time. Luna: It sounds like a pretty effective way to break the 'feature factory' pattern. Instead of just shipping output, you're constantly asking 'did the user's experience get better?' Lucas: Exactly. And the numbers back it up. Over six months, Mark's team reduced the average pain score across the journey map from 3.4 to 2.1. Their NPS went up by 15 points. And — this is the part that got the CFO's attention — customer support ticket volume dropped by 22 percent, which let them reassign two support reps to other roles. Luna: So it's not just a warm fuzzy alignment exercise. It hits the P&L. Lucas: Exactly. And that's why Mark says he'll never go back to feature-count standups. The journey map gives him a single source of truth for what matters to users. And it aligns engineering, product, and business goals without a ton of top-down mandates. Luna: Where do you see this approach breaking down? Any pitfalls Mark mentioned? Lucas: He mentioned two. First, if you don't keep the pain scores updated, the map becomes stale and loses credibility. Second, it's easy to over-engineer the map itself — too many steps, too much detail. He said start with one critical journey, not the whole product. And make sure the map is a tool for conversation, not a deliverable. Luna: Good advice. So for a CTO listening — what's the first step? Should they grab a Miro board and start mapping tomorrow? Lucas: Mark's advice: pick one user journey that has the highest support ticket volume or the biggest drop-off in your analytics. For most SaaS companies, that's the signup or onboarding flow. Map it in one afternoon with a small cross-functional team. Don't try to make it perfect. Then assign pain scores based on real data — support tickets, session replays, NPS comments. Share it broadly, and then pick one low-hanging fruit to fix in the next sprint. Measure the impact. If it works, expand the map to other journeys. Luna: That's a concrete starting point. I could see a lot of teams benefiting from that. Lucas: For sure. And I think the bigger lesson here is that engineering alignment doesn't have to come from a top-down roadmap. It can come from a shared understanding of what the user actually experiences. The journey map is just a lens — but it's a powerful one. Luna: Yeah. And it shifts the conversation from 'are we building the thing right' to 'are we building the right thing.' Lucas: Exactly. And that's a question worth asking every sprint.