Analyzing the Customer Journey with a Product Teardown

Paul Cowles
11 min readJan 18, 2018

Tear·down (definition): An act of completely dismantling something.

Brief

In 2017, the Hootsuite Mobile Team started using a new process for examining our product through the lens of one of our customer personas. We’ve been calling this process a “Customer Journey Teardown”. Put simply, a teardown is a whole-team analysis of a customer journey through the lens of a particular persona. After running through the process with a few teams, we felt it produced an important alignment between our teams and our customers.

Look at your product through the lens of a particular persona. Photo by Paul Skorupskas

The purpose of the process is to align design, product, and engineering teams with the user experience of a particular customer persona. Its purpose is to create empathy by having every member of the team step into the shoes of the customer and be focused on their problems. You may consider doing a teardown before or after an Empathy Mapping exercise.

A teardown is focused on what we have today, not what we want to build tomorrow. By revisiting what we have already created, our attention is centered on recognizing existing problems rather than our predisposition for simply adding new features on top of what could be a flawed foundation.

Our design team has built up, over the years, a rich set of user personas that influence and guide our product and business. A teardown sits on top of this work — and is in fact, not possible without it first being in place. A teardown leverages insights from user research in an actionable context. Teardowns do not replace conversations with customers or any other aspect of your user research.

It is far too common for user research findings to be underutilized, and not integrated with, engineering teams and agile processes. We also identified that a major factor of de-motivation across the teams were flaws in the experience that have been known for a long time and left as is, unfixed. Teardowns are a great way for preventing this from happening — with the caveat that if you come together as a group to identify problems, you have to be disciplined enough to follow through and fix some of them. If you do not, the team may lose confidence in the process, and perhaps even the company. Generally speaking, it’s more inspiring to be a part of an organization that pays attention to the customer journey and wants to optimize the customer experience.

Below we will take you through how to prepare for, execute on, and follow up with a customer journey teardown. Our current belief is that this is a rinse-and-repeat cycle that should be done again and again every few months. This ensures that over time, the team can see the tangible impact on the user experience of the persona being used.

Preparation

Make sure to invite designers, engineers, and product managers (plus other stakeholders). A teardown is an exceptional opportunity to align the entire team on the customer experience and to use the product like a customer would.

Step into the shoes of your customer. Photo by Nadine Shaabana

The group will focus on the experience from a persona’s perspective throughout the entire session. Use an existing persona or create one, based on your user research, for this exercise. Be succinct and practical if creating a new one: give this persona a name, a story, and a goal or intent relevant to this teardown. In order to use time efficiently, it’s best to clarify the persona ahead of the session. Include details in the teardown invitation and once the group convenes reiterate the information to establish a shared baseline understanding. Make the persona’s goal more specific to add additional focus on the teardown.

Next, pick a Customer Proxy and a notetaker. The Customer Proxy’s objective is to act as the persona and to walk the group through each step of the journey, describing out loud what is and isn’t working while the entire group is encouraged to add commentary. The notetaker documents the insights raised by the participants and will share them with the group after the teardown. Any participant can act as a moderator to make sure the group completes the persona’s goal by the end of the session.

Last but not least, it is important to have everyone 100% present for the whole duration of the exercise (usually 60 minutes). While many of us think ourselves capable of winning an Oscar, thinking and acting as another person is not as straightforward as it seems. Therefore, put laptops and phones away.

Teardown

Thinking like a customer often means that the journey starts outside of the product. Where and what triggered the workflow towards accomplishing the goal? Was it a conversation, an article, or an existing process? Have the Customer Proxy start in a Google search, an App store listing, or by hand entering a URL into a web browser. Consider finding and acquiring your product as part of the analysis.

By taking a holistic approach to the customer experience, the group will be able to create a deeper empathy with the user. The group, led by the Customer Proxy, will review and discuss points of friction or misalignment, fundamental realizations of value (“aha moments”), and even “deal breaking” defects and flaws which would lead the customer to abandon the experience. The discussion tends to span user interfaces and experience, messaging and positioning, interactions, effort, and workflows.

At times, the Customer Proxy will come to forks in the road where they could go in multiple directions within the product. You may want to go down the first path until exhausted and then return and try the next path. Alternatively, you can explicitly save paths for future teardowns when you revisit the persona the next time.

Explore the variety of paths in the product workflow. Photo by Caleb Jones

It is critical that the notetaker capture as much of the conversation as possible. Categorize and deduplicate comments post teardown. Try to avoid making judgements pre capture — the notetaker’s role is to capture as much as possible, and not be filtering comments based on their own judgement as to what is and is not important. You may wish to experiment with video taping the teardown sessions to allow for capturing comments at a later time or being able to compare teardowns over time.

If the group is not offering comments and insights readily, have the moderator probe the team with open ended questions. “What would you think here?”, “What does this tell you now?”, “How do you feel at this point?” are the types of questions that often generate discussion if it is not already free flowing.

The journey ends when the Customer Proxy has accomplished the originally stated goal of the persona or thrown their hands up in the air and given up. Do not try and process the notetaker’s findings at the end of the session, save that for the next time the group gets together. The end of a teardown can be quite invigorating, teams often feel energized despite recognizing a plethora of problems in their own product. Let that energy carry forward by not jumping to solution generation immediately after you finish your teardown.

Post Teardown

The team has disbanded and gone back to work and now is the time to distribute the raw notes to every participant that was part of the teardown session. Tools like Google Docs make it easy to invite everyone into a shared space while also limiting who can edit the document versus adding comments or suggestions. Sharing the raw notes early allows participants to correct anything captured incorrectly or to expand on anything that isn’t inherently obvious. Ask participants to refine the notes within 48 hours of distribution, before you start processing them.

A typical teardown session generates hundreds of observations. At this point, it can feel overwhelming as you realize just how many improvements could be made to your product. As with any backlog, they will vary widely in the impact on the business or on the number of affected customers. At least one representative from design, product management, and engineering need to sit together and prioritize the list of problems. At this stage, the group is trying to order by impact only, not yet by cost, timing, or complexity.

It’s now time to take your list and add the dimension of how much effort it will take to solve the problem. You won’t be able to debate solutions for every problem on the list, so we’ve found it best to start at the top and work downwards. As a interdisciplinary team, you’re trying to figure out which subset of problems you are going to try and solve for customers first. Typically, you’re looking for a small number of observations at the intersection of highest impact and lowest effort. If your goal is to be revisiting teardowns monthly, the number of selected problems to tackle should be much smaller than if you want to be revisiting teardowns once per quarter. Select a number of problems to action on that best matches the cadence of your teardowns and the capacity of your team to make changes. Keep solutioning at a macro level, at this point you should only be doing rough t-shirt sizing to help with selection.

Now that you have a subset of actionable items, give the opportunity to your design team to take the items away, and to follow the standard process you have in place for designing changes to your product. In a few hours, weeks, or months, they will reconvene the cross functional team to do the final review of the proposed solutions.

Once a solution has been reviewed collectively and given the green light to move forward, the engineering team may add the work to a current release or sprint by creating an epic with associated stories and tasks. Before the team starts executing, be sure to identify a key performance indicator (KPI) that you expect to see improve with the change. After implementation and testing is complete, the change is deployed to customers. Part of the deliverable is instrumentation or tooling used to track changes to the KPI. In some cases, the team may choose to A-B test the product change against the current baseline. It is imperative that as you introduce changes, you measure customer response and validate whether or not your assumptions stemming from the teardown were correct. Not every change coming out of a teardown will prove correct or successful, and so you need to know which ones to rethink or rollback.

Close the loop by recapping the results of the changes that were made based on observations of the original teardown group. After your initial teardown, you may find it good practice to start each subsequent teardown with a recap of the results from the previous session. It is motivating for everyone to see that action was taken from prior time invested, and how the results of those actions impacted the customers and the business.

Adjust the cadence of your teardown sessions based on how fast you can deliver changes to customers, measure the impact, and determine success. Do not try and schedule your second teardown session before you can fully complete the first. Once you have greatly improved the experience of the current persona, switch personas for the next session.

Case Study: Solopreneur on iOS or Android

In 2017, our iOS and Android teams did teardowns to analyze the customer journey for a solo/small business persona which we named Judith. For our teardown, Judith runs a catering business and wants to share her menu on social to get more business. She has heard of Hootsuite from a friend and has found us in the Apple App Store. She needs to schedule messages to multiple social networks — namely Instagram, Twitter, and Facebook.

Judith and her catering business. Photo by Sasha

Observations

The team started by looking at the App Store listing, they quickly noticed numerous optimizations that could be made to better speak to Judith. After downloading and installing the app, the team then went through the process of signing up for the first time as Judith.

In talking out loud, the team noted that the first screen was oriented towards existing users, presenting sign in options with priority, and downplaying the creation of a new account. “Create Account” didn’t even look like a link or a button.

It was also unclear whether or not signing in with Twitter would also make Judith a Hootsuite account. The team agreed that this was confusing and gave Judith apprehension as it wasn’t clear what she would be giving Hootsuite by signing in with Twitter. The team identified that Judith didn’t want Hootsuite to automatically post something to her Twitter account without her knowledge.

Before (left) and after (right) our teardown optimizations.

Solution

Adjusting the first landing page for Judith was given top priority after processing all the observations from the teardown. Our design team went away, did more user research, reached out to other stakeholders, and then came back with a solution that prioritized new sign ups over existing sign ins, and also made it more clear that using Twitter was creating a Hootsuite account.

The iOS and Android teams implemented the changes, added tracking to measure conversions on this page, and rolled the change out to customers slowly over a two week period. During that period we A-B tested, 50% of new users saw the old design and 50% saw the new design.

Results

At the end of the two week period, the iOS team looked at the results for their platform. We compared the conversion rate for new users successfully signing up and getting past the initial page they landed on. The old design had a stable 15% conversion rate, and the new design had a significantly increased 22% conversion rate. With the improvements, 7% more new users were signing up and beginning to use the product. You can’t make everybody happy all the time and we did hear from some existing customers that they didn’t like having to make an extra tap before signing in. However, as we had consciously decided as a business strategy to optimize for the new user signing up, we deemed the change a success.

Now that we had successfully implemented a change to the first step of onboarding the team could focus deeper along the customer journey in the next teardown session.

Tools and Feedback

We use a common Google Docs template to bootstrap all our teardown sessions. We’re sharing it with you in hopes that you find it useful and also make it even better.

Have questions? Do something similar with your team? Have ideas for improving this process? We’d love to hear from you. Feel free to contact us at guillaume.darabian@hootsuite.com or paul.cowles@hootsuite.com.

--

--