Journey Mapping: A Product Development Process Case Study

Underpinning every successful product is a successful product development process. As a senior product manager at Toptal, I’ve found that treating that process as a product in its own right results in measurable improvements that touch every facet of our work.

The team I lead comprises an engineering manager, nine software engineers, and one quality assurance engineer. Our work covers a wide spectrum of products and features that facilitate a healthy supply-and-demand balance for our talent network. In the sections that follow, I share how we evolved our product development process using customer journey mapping and arrived at greater efficiency, communication, and collaboration.

When the Process Is the Product, the Team Is the User

Products that are unsuccessful or ineffective often result from what a team, or even a single person, thinks users want and need, not what they actually want and need. A good product, however, is built on the qualitative and quantitative data derived from extensive user research sessions. Likewise, the product development process itself can be unsuccessful or ineffective when it is designed by a leader who assumes they know what their teams need.

As product manager or team lead, you should engage in the same kind of user research that you would carry out for a product—shadowing, interviewing, and surveying—with your team to make sure your process is similarly successful. The goal is to understand how your team is using the product development process and address any pain points they encounter along the way.

Build a Customer Journey Map

There are various ways to collect feedback from users, but customer journey mapping is the product discovery technique I use with my engineers. The result is a diagram that illustrates the steps users go through when engaging with your company, whether that be through a product, online experience, retail experience, service, or any combination of these. The more touchpoints your users have, the more complicated—and therefore necessary—a map becomes.

This technique explores users’ actions and emotions around that engagement to reveal pain points and opportunities. It’s an excellent way to uncover problems in your process.

Within the diagram, users are depicted as hypothetical personas. Each persona should have a short bio, including a description of their inner motivations and responsibilities, as this helps to humanize them. Each persona should represent a key type of user to offer a sense of the diverse wants and needs the solution must address.

Journey maps are organized by user stages. Each stage represents a major goal the user is trying to achieve in their overall journey. For each stage, and for each persona, ask your team to consider:

• Actions: What does the user do?
• Emotions: How does the user feel?
• Pain Points: What bothers the user?
• Opportunities: What are some possible solutions?

Asking the team “What bothers you about this product and how can we fix it?” would not be a useful way to gather information because, at the time the question is asked, they may not recall use cases or how they felt when they experienced an issue. Asking them to split the interaction into steps and asking them how users encounter each step helps the team surface the emotions associated with each stage of the journey.

Applying This Theory to Our Toptal Team

To understand how this theory applies in action, consider the journey map for the product development process that I created with my engineering team.

Using Miro, I created the journey map board, splitting the product development process into eight major stages:

• Roadmap Planning, and Defining Objectives and Key Results (OKRs)
• Product Specification
• Technical Analysis and Work Breakdown
• Implementation
• Quality Assurance and User Acceptance Testing (UAT)
• Pre-release
• Release
• Post-release

I chose two personas—software engineer and product manager—as these are the main users who engage with the process.

• Sergey, the software engineer: Sergey ensures the initiatives are delivered on time and to a high standard, while maintaining a robust code base and understanding of the latest technologies and tools.
• Matt, the product manager: Matt ensures the team prioritizes its efforts by working on the most impactful initiatives first. He also listens to stakeholder needs and communicates updates to the team regularly.

Prior to the session, I filled out the journey map for Matt, the persona in my role, in order to get an idea of how much time was required to complete the exercise, as well as to set the team’s expectations of the format. Next, I scheduled two 90-minute sessions across two consecutive days to ensure my team had enough time to complete the exercise without losing focus or energy. Because most engineers are unfamiliar with the journey mapping process, I shared links to the Miro board and a YouTube tutorial to help them prepare. Before the beginning of the first session, I confirmed that everyone understood the concepts.

As facilitator, I asked the team to suggest the actions, emotions, pain points, and opportunities for Sergey’s persona. Some team members were shy at first, but once a few people shared their thoughts, the session started to flow. I filled out cards on the Miro board based on their input.

Key Learnings From the Journey Mapping Process

The journey mapping process yielded five main takeaways:

1. Keep the sessions short and focused. If there are more than a few stages within the journey map, I advise splitting the effort into two or three sessions to maximize productivity and to prevent team members from losing focus.
2. Be a role model. Filling out the Product Manager swimlanes before the session sets a tone of honesty and openness, and demonstrates how to express these issues, encouraging team members to share their own emotions and pain points more readily.
3. Create emotional safety. Team members may find it intimidating to share their struggles—most likely from a fear of being judged—but try your best not to intervene. Sooner or later, a more courageous team member will break the ice and things will start moving. When that happens, show empathy and appreciation. This will reassure other members that they are in a safe environment and they will feel more comfortable sharing their thoughts.
4. Create a follow-up plan with your team. Some problems may be hard to solve, especially if the solution involves other teams or departments, but plan to keep your team updated about any relevant communication with, or changes from, those responsible parties who may impact the results of the journey mapping process.
5. End with action steps. Create a list of action items, and assign an owner and deadline to each, which will help you realize tangible results from the session. Some examples that resulted in our case are depicted in the following table:

​​

Why Was the Journey Mapping Exercise Effective?

The journey mapping exercise was extremely successful in presenting potential opportunities for improvement and fostering team spirit. It helped us in the following ways:

1. It uncovered issues where I believed things were running smoothly and reinforced the importance of not making assumptions. For example, I assumed that everyone had sufficient training on Jira, which was not the case. On the other end of the spectrum, I thought asking the engineering team to record demo videos for new pieces of functionality burdened them, when in fact they valued the exercise because it helped them improve their presentation techniques and lessened their anxiety around being in front of a camera.
2. It illuminated some improvements I could make, such as restructuring initiative cover pages to make them more accessible for engineers.
3. It empowered the engineering team to take responsibility for the outcomes within their control because they were the ones proposing changes that they could test and further iterate. It was primarily a bottom-up process.
4. It revealed that the pain point hot spots were predominantly around roadmap planning and implementation.
5. It forged stronger working relationships among the team by acknowledging shared challenges. For example, a number of individuals on our team thought they were the only ones struggling with the CI/CD pipeline for a particular subsystem when, in fact, most of the team was struggling.

Scaling Considerations

If every product manager or team lead for engineering goes through this process with their team, a common set of problems will likely arise, indicating which issues should be addressed first. Teams should follow the updated process for a few months, then the feedback loop must be revisited again. This cycle should continue until the product development process is natural and easy, and supports the needs of the users in building top-quality software products.

In the case of my team, our new process has delivered tangible improvements on several fronts:

• The average time for tickets in review has been reduced by 22%.
• The product OKR completion rate has risen above 90% over the course of the last three quarters.
• The service-level agreement time for high-priority bugs has been met in 100% of cases.
• There have been no failed releases due to deployment problems.
• The average number of post-release reported bugs has decreased by 37%.

If your team is involved in building products, then your process should be subject to continuous scrutiny and improvement. If one function is not performing well, or if its product development process is weaker, that will impact the end result. While I used this practice for an engineering team, it can easily translate to user research, design, UI/UX, and content teams.

Your product development process is your most important product. Use this exercise to help perfect it, and see how much it elevates every product your team makes.