How to use product teardowns to make your product better

A simple tool for helping you and your team develop your taste and make product decisions

The first time I came across the concept of the teardown I was just getting into product. I was interviewing at a startup with a young, self-taught guy who, as the head of product, was looking for his first product hire. I did my best, having no actual product experience at the time, just a freshly minted certificate from General Assembly and what I could only assume were easily transferable marketing skills. He, in return, was generous enough to give me some advice based on what he was doing to continuously upskill in product. One of those things, plucked from a bank of what he found interesting, was a website that posted UX teardowns where the onboarding experiences of popular websites would be picked apart and commented on. I was intrigued by this process: you take a snapshot of something as ordinary as an app you use mindlessly everyday and simply ask, what is it doing here? And, then, building on that: is it doing it well? It seemed so available, like struggling to get the SIM card out of an old phone only to find the back of your earring will do the trick. There was so much to be learned if we only stopped and considered how we as users were guided through the digital worlds built for us, instead of rushing! I didn’t get that job and that website has now gone dead, which is obvious from the selection of websites that were chosen for dissection: Wordpress, Kimoji, Hilary 2016. But both left a lasting impression on me.

When I started working with a client on rebuilding their web checkout experience, I knew I would start with a product teardown. There was a checkout already on the legacy website, but it had several known issues. I wanted the team to walk through it and consider those issues themselves. Perhaps there was a reason the checkout of the past had been built this way, underpinned by a twisty-turny kind of logic grown organically from a technical constraint invisible to the user, like the burl of a crooked tree. I wanted the team to judge the results of those decisions together as an act of disassembly, so that we would be starting with a shared understanding of where we were coming from and where we were going.

“Teardown” itself is an aggressive word for a process designed to expand our repository of possible opportunities and (when reviewing a product not our own) solutions, as well as improve our reasoning for choosing the path we take towards each. Perhaps it’s best to say that a teardown is a kind of forced honesty. You can spend months– or, godforbid, years!– building a checkout without ever really looking at whether it actually works, because taking a look requires admitting to someone, maybe yourself, that what you’ve built is broken. A teardown makes that unavoidable. As we sat together, clicking through the legacy checkout, we could see what was really there, the way you see what’s really there when the house lights come on at the end of the club night.

The importance of honesty is more pressing in a world littered with AI design and vibe coded products. Teardowns are one way of honing the craft of developing good products. Vibe coding means anyone can now build a bespoke tool, so knowing precisely how well your product serves its purpose– which is what a teardown gives you– matters more, not less. Technology journalist Casey Newton, in his personal foray into vibe coding, has found that if he can’t find a product that solves his specific problem, he can create it himself, to his taste: “If it’s boring, make it funny. If it’s ugly, make it pretty.” Rather than waiting for a development team to sling together a product in the shape of something that looks roughly right, users like Newton are taking matters into their own hands. It’s not clear how scalable or accessible this will become; Andreessen Horowitz estimates that roughly only 1% of the general population so far has vibe coded, or about the same as have run a marathon. It is possible but not certain, then, that we risk, in this new agentic world, competition not only from other industry players, but from individuals empowered to build for their own idiosyncratic needs. To compete, products must be intentional about what they do and do it well. Teardowns can help sharpen your ability to tell.

“We have never done this,” the tech lead of the checkout team told me after our teardown, about having the chance to compare the work against business and customer goals, especially when I was able to produce the existing but never-before-seen funnel metrics alongside the user journey. We came out of that session with a shared understanding of what we were coming from and where we could make the most difference. Those were the insights that we sifted into the new checkout, making the teardown a powerful tool that meant we started clear eyed and together. When the new checkout launched several months later, it was 12.5% faster and saw many more customers through to the end.

If you want to run a Product Teardown yourself, here is how you should run it:

1. Decide what you want to get out of the product teardown.

   To begin with, decide which of your personas you are going to walk through the product as. This matters because your many users do not want or need the same things. During the checkout teardown, I introduced our most loyal customer first, someone who already has an account and is familiar with the brand. This was because we were going to build the guest user experience last. Describe who they are and what their goals are, so that your team has a shared sense of this person (a regular customer has very different expectations than someone who has slid down the chute for the first time directly from a Google search). Share the business outcome, including the key metric you hope to improve with the feature or journey. This becomes the yardstick against which you measure.
   
   Note: there are different reasons you may want to run a teardown, including to:

   • Review the current live product before you make or continue making changes (as above)

   • Review your own work as you complete epics or initiatives

   • Conduct competitor analysis by reviewing other products
     

2. Set up a shared user journey map on a virtual whiteboard.
   Using a tool such as FigJam or Miro, set up a user journey map (the built-in templates work well here) that already has the product’s steps filled in across the top, so that your team is anchored from the beginning and you don’t need to spend time in your session filling these in. On my board, I had the image we used to represent our loyal customer, as well as the current funnel metrics and the conversion rate we were looking to improve. This would keep the team focused when they joined the session.
   

3. Walk the team through the product while they add notes to the user journey map.
   Make sure to invite the whole team so that you get a variety of perspectives: engineers, designers, delivery, data. Your team will see things in ways you don’t, and vice versa, which will only make the insights you come away with stronger, as well as shared. We benefitted by having a blended team that comprised both people who had worked on the legacy checkout we were reviewing as well as those with fresh eyes. The legacy team members brought context of backend systems and back office processes; the new team members brought alternate ways of doing things.
   
   Your job now is to narrate the demo, going unnaturally slowly, so that everyone can read everything on the screen, ask questions out loud (e.g. “Would I notice that message at the bottom if I was a customer doing this on their phone? It’s pretty important”) and bounce ideas and opportunities off one another. Have them all capture their thoughts onto sticky notes so you can review, group, and de-duplicate these at the end.
   

4. Review the user journey map together and make the takeaways actionable.
   Once you’ve demoed the product through to the end, share the user journey map and walk through that. What was most surprising to your team? Was there anything missing? Anything particularly delightful, or an opportunity to add delight in the near future?
   
   As you review the notes, ask what decisions have the team made so far that are likely to have the biggest impact on user and business goals, either negatively or positively. These become actions that can be prioritised.

Our original product teardown helped set us on the path to building a faster, more considered checkout, and subsequent teardowns allowed us to check our own work. That is what I still think of now: the team returning to the room to click through what we’d actually built, the lights well and truly on.