Why Starting With End-to-End Customer Journeys Isn't Good For The Customer

In my role as Associate Director at Pivotal Labs in Sydney. I often meet with potential clients who are struggling to design and build successful software products. The root cause of their struggle can be a combination of different factors: from bloated processes within their organizations and legacy systems that make it difficult to build software that’s deployed quickly or simply not understanding customer needs and building a product that doesn’t resonate. 

At Pivotal Labs, we help teams and organizations understand where their pain points are, work to tackle them and adopt modern product development practices. Something I have noticed particularly in Australia is the use of end-end customer journeys to define product development initiatives. This is often used by organizations that are keen to communicate the end vision to stakeholders. From my interactions I have heard that this upfront research and planning helps to ease the fears of risk-averse decision makers. Are these practices reducing risk or creating greater risk? 

What is a customer journey?

A customer journey highlights steps customers make to engage with your company, product, and all related touch points. It is sometimes drawn as a series of sequential steps and activities. For existing products, some research can identify these touch points and is a useful exercise to highlight areas that may require attention/simplification. 

But there are some common pitfalls with end-to-end customer journeys:

Outsourcing the research

Using a design agency or a separate team to research the problem space and identify customer journeys is not helpful for the product team that will inherit the initiative. It's imperative for the product team consisting of product managers, designers, and developers to understand the problem space and to empathize with customers. Getting laser focused on solving customer problems is really hard when you simply do not have the context. When this research is performed without product teams, expect mediocre results. 

One-time research

Performing research in one go is risky. You end up making quite a leap of faith that your research was conducted correctly, your insights are valid and that your solution will solve customer problems before you have written a line of code. Assumptions built on top of assumptions. Like building products research should also be iterative. Understand your customer pain points and how they are currently trying to solve for that problem. Mock together low-fidelity prototypes to see if you have understood the problem and if your solution solves for it. 

How To Get Started

So if we don’t research end-to-end journeys upfront what’s the alternative? A concept used by successful product teams is ‘Just enough for now.’ The concept refers to research, design and development. The idea is to keep the build - measure - learn cycle as short as possible and work to release value to customers as soon as possible. 

1. Gather a small team consisting of; a product manager, a product designer and a developer. This is important so that you ensure you are looking at the problem together as a team. Great products are made by teams that create empathy for the customer. Furthermore, these 3 disciplines will ensure the team is looking at any potential solutions from a desirability, feasibility and viability lense.
2. Timebox your activities to a few weeks.
3. Gather your assumptions, what are your leap of faith assumptions that must hold true for this initiative to work?
4. Prioritize your assumptions by the riskiest assumptions
5. Gather information both qualitative and quantitative to validate/invalidate your assumptions
6. Understand the problem space and check how customers are solving their needs currently. How satisfied are customers and how important is this problem to customers?

By this stage, you have run through the first diamond of the double diamond above. The team will have a list of customer problems ranked in order of priority. They will have a good idea of how big these problems are and the opportunity they present to the organization if solved better than current solutions. Note they may not find an opportunity that is worthy of investing in. That’s actually great and far better than spending months identifying end-end customer journeys. It's far more cost effective to spend 2 weeks disproving a multi-million dollar initiative than spending 6 months investigating every touch point of customer journeys that will never come into fruition.

If you do find some problems worthy of investing in, the team can now ideate together to find solutions to those problems. 

At Pivotal Labs, we use a number of techniques to facilitate ideation in a cross-functional team including design studios and low fidelity prototypes. We keep speaking with our target customers and validate our solutions and how well they solve the problems we identified earlier. We hypothesize, prioritize, and ideate as a team. This won’t be end-to-end and it won’t be a one-time activity, but you are more likely to get to a point where you are solving real problems and fast. 

Overcoming The Need For a Plan

Here’s how to make the argument to a stakeholder on your team that really wants to see that end-to-end vision: If the idea is to get value out to customers as fast as possible, does it make sense to explore every customer touch point? The time spent doing that intensive research could’ve been spent building and delivering an MVP for customers and get them excited about. Repeating this cycle gets the team to “learn by doing” and is actually a faster way to truly understand the customer’s end-to-end journey. It’s also a lot more engaging work than research and makes the team stronger.

At the Pivotal offices in Sydney, we have worked with a number of our clients to overcome this need for excessive upfront research and move to a ‘just enough model.’ Together we have worked with their teams to explore, de-risk, and incrementally build products that deliver great customer value. If you are interested in learning more about our pairing model for your teams or are interested to learn how we use eXtreme Programming, Lean Product Management, and Customer-Centered Design at Pivotal Labs, please get in touch. 

About the Author

Amjad Sidqi is an Associate Director of Product Management at Pivotal Sydney. He's had 13+ years of leadership experience in building teams, product development and Agile Transformation and prior to Pivotal has managed and launched products in several industries from e-commerce, airlines, government, and NGOs.