How to do a product teardown (framework, template and worked example)

A product teardown is a structured walk through a real product in which you record what a user experiences, explain why the team probably built it that way, and decide what you would keep, fix or copy. The fastest useful format is three labels: Works, Doesn't and Steal this. Scope one flow, walk it as a real user, label every observation, then end with one or two changes you would test and the metric that would prove you right.

Key takeaways

• Tear down one flow, not a whole app. "Zepto's first order from a cold install" is a teardown; "Zepto" is a book report.
• Every note should be observable, specific and labelled: Works, Doesn't or Steal this. If you cannot point at a screen, it is an opinion, not a note.
• Separate what you saw from what you infer. Hypotheses about the business are allowed, but label them as hypotheses.
• Count things. Taps to first value, permission prompts, screens before sign-up and seconds to first useful result turn taste into evidence.
• A teardown is finished when it ends in a recommendation with a metric, not when you run out of screenshots.

What is a product teardown?

A product teardown is an evidence-based critique of a specific product experience, written from the user's side of the screen and finished with recommendations. The term is borrowed from hardware, where engineers take a device apart to see how it was built. In product management you take apart decisions instead of components: why this screen comes first, why this permission is requested here, why this button is bigger than that one.

It helps to be clear about what a teardown is not.

A good teardown borrows from all three but stays anchored on one flow and one user.

Why product managers should do teardowns regularly

Teardowns are the cheapest way to build product sense: the ability to predict how a real user will react to a product decision. You cannot A/B test someone else's app, but you can study what its team has already shipped. They pay off in three ways:

1. Pattern library. After twenty teardowns you stop inventing onboarding, paywalls and empty states from scratch.
2. Interview preparation. "Pick an app you love and tell me how you would improve it" is one of the most common product sense prompts. A teardown habit means you already have three prepared answers. See our list of product manager interview questions for the variations.
3. Portfolio evidence. For career switchers, a sharp public teardown proves thinking a resume line cannot. Our guide on how to become a product manager in India covers how to use them in a portfolio.

The Works / Doesn't / Steal this framework

Most teardown templates ask for a dozen sections and get filled with filler. Three labels force a decision on every observation.

Works is a decision that helps the user reach their goal faster, with less doubt or less effort. Example: the address is saved in one tap.

Doesn't is a decision that adds friction, confusion or risk, or that serves the business at the user's expense without a good reason. Example: six permission prompts before the first order.

Steal this is a pattern worth copying into a different product, with a note on where you would use it. Example: delivery time shown before sign-up.

Three rules keep the labels honest:

1. One observation per note. "Onboarding is cluttered" is not a note. "Screen 2 asks for notifications before I have seen a single product" is.
2. Attach the why. Each note gets one line of reasoning: what user need, metric or constraint makes this good or bad.
3. Steal this must travel. A Steal this note only counts if you can name another context where it would work. If it only works inside this product, it is a Works note.

How to do a product teardown, step by step

1. Scope one flow and one user

Write a single sentence: "A first-time user on a mid-range Android phone, opening the app with the intent to place their first order." Choose flows where decisions are dense: onboarding, first purchase, search, checkout, cancellation, upgrade to paid, or the first five minutes after sign-up.

2. State the job the user is hiring the product for

Name the job and the moment. "Get groceries for tonight's dinner in under 20 minutes" leads to different critique from "stock up for the week at the best price". If you do not know the job, talk to two real users first; our customer interviews guide shows how to run short ones.

3. Walk the flow as that user and record everything

Use a fresh install so you see what a new user sees, and screen-record the session. Note your device, OS, app version, city and network, because many Indian consumer apps behave differently by location and platform.

4. Map the flow as a table

One row per screen or system event. Columns: step, what the product shows, what the user must do, and the friction you felt. This is where counting happens.

5. Label every observation

Go row by row and turn friction and delight into Works, Doesn't and Steal this notes. Aim for roughly as many Doesn't notes as Works notes. A teardown with only praise is fan mail; one with only complaints usually means you did not ask why the team chose it.

6. Infer the business logic, and label it as inference

Ask what the team is probably optimising. A permission prompt that annoys you may exist because location accuracy drives delivery promises. Write these down as hypotheses ("Likely trade-off: …"). This is the difference between a user's review and a PM's teardown. If you want a sharper lens, try to guess the product's North Star metric and check whether the flow serves it.

7. Recommend one to three changes, with a metric

Pick the changes with the best impact for the least effort, and say how you would measure each one. "Move the notification prompt to after the first order is placed; watch notification opt-in rate and first-order conversion." If you have several candidates, a quick pass with one of the common product prioritisation frameworks keeps you honest.

8. Share it and let people argue

Post it, present it, or bring it to a group. The best feedback on a teardown is someone saying "that Doesn't is actually a Works, here is why".

A copyable product teardown template

Copy this into your notes app, Notion or a doc. It is deliberately short.

PRODUCT TEARDOWN
Product + flow:      [e.g. App name, first order from cold install]
User + context:      [who, device, OS, app version, city, network]
Job to be done:      [what the user is trying to get done, and by when]
Date of walkthrough: [YYYY-MM-DD]

1. FLOW MAP
| # | Screen / event | User must... | Friction or delight |
|---|----------------|--------------|---------------------|
| 1 |                |              |                     |

2. COUNTS
Screens before first value:
Taps to first value:
Permission prompts before first value:
Fields typed:
Time to first value (seconds):

3. NOTES
WORKS:      [observation] -> [why it helps the user or business]
DOESN'T:    [observation] -> [cost to the user, and the likely trade-off]
STEAL THIS: [pattern] -> [where else it would work]

4. HYPOTHESES (inferred, not observed)
- The team is probably optimising for:
- Likely trade-off behind the biggest Doesn't:

5. RECOMMENDATIONS
| Change | Expected effect | Metric to watch | Effort (S/M/L) |
|--------|-----------------|-----------------|----------------|

6. OPEN QUESTIONS
- What would I need data or user interviews to confirm?

Worked example: a quick-commerce first order (Zepto)

Here is the method applied to a first order on Zepto, the quick-commerce app. Treat it as an illustration, not a live audit: these flows change often and differ by platform, city and app version, so re-run it on your own phone before quoting any detail.

Scope: a first-time user on Android, opening the app to buy a few grocery items for tonight. Job: "Get what I forgot for dinner, quickly, without a trip to the shop."

Flow map

Works

• Value before identity. The user sees what is available and how fast it will arrive before being asked for a phone number. Asking for commitment after showing value is the single most transferable onboarding lesson.
• Delivery time as the headline. The promise the product sells is the first thing on screen, not buried in a banner.
• Login at the moment of intent. Asking for a phone number at checkout feels reasonable because the user now has a reason to give it.
• Fewer OTP steps. Where one-tap login works, a step that often fails on patchy networks disappears.

Doesn't

• Address entry can still be the slowest step. Choosing a pin on a map and then typing flat number, floor and landmark is necessary in Indian addressing, but it is where a first-time user is most likely to hesitate. Likely trade-off: delivery partners need precise details, and a wrong address costs more than a slower first order.
• Promotions compete with the task. Home-screen banners help average order value but distract from the "I need three things" job.
• Location denial is a cliff. If a user refuses location, the manual fallback has to be excellent, because everything else depends on it.

Steal this

• Show the promise before sign-up. Any product with a measurable promise (time, price, availability) can show it before asking for an account: a clinic booking app showing the next free slot, a B2B tool showing a real sample report.
• Defer login to the moment of intent. Works for most marketplaces and content products where browsing is the hook.
• Use a trusted identity provider to skip OTP. Relevant for any Indian consumer app where SMS delivery is a drop-off point.

Recommendations

Note what this teardown avoids: it never claims to know Zepto's internal metrics or motives. Observations, labelled inferences, testable changes.

What to measure in an onboarding teardown

Counting makes teardowns comparable across products. Use the same five numbers every time:

"First value" depends on the product: the first search result, the first song played, the first completed order. Define it in the scope line.

Common product teardown mistakes

1. Tearing down the whole app. You run out of energy before you reach anything specific.
2. Confusing taste with evidence. "I don't like the colour" is not a note. "The primary button has the same visual weight as the secondary one, so the next step is unclear" is.
3. Ignoring the business. A teardown that never asks why the team chose a design reads like an app-store review.
4. Testing as a power user. Years of use hide the friction. Use a fresh install, or watch someone new use it.
5. Ignoring Indian context. Low-end Android phones, patchy networks, shared devices, multiple languages and UPI-first payments change what good looks like. Note your device and network.
6. No recommendation. A list of observations without a "so what" is unfinished. End with one to three changes and a metric for each.

How to run a product teardown with a group

Group teardowns surface more Doesn't notes, because everyone brings a different device, habit and patience level. A 60-minute format:

Product Circle's teardowns follow this shape: one product every two weeks, taken apart together, with notes in exactly these three labels.

Frequently asked questions

What is the purpose of a product teardown?

A product teardown helps you understand why a product works the way it does and what you would change or copy. For product managers it builds product sense, creates a library of proven patterns and gives you prepared examples for product sense interviews.

How long should a product teardown take?

A focused teardown of a single flow takes 60 to 90 minutes: about 20 minutes walking and recording, 30 minutes labelling notes and 20 minutes writing recommendations. If it is taking a full day, your scope is too wide.

What should a product teardown include?

At minimum: the flow and user you scoped, a step-by-step flow map, a few counts such as taps and screens to first value, labelled Works, Doesn't and Steal this notes, your hypotheses about the business trade-offs, and one to three recommendations with a metric each.

Can a product teardown help me get a product manager job?

Yes, if it is specific and ends in testable recommendations. Hiring managers use teardowns to judge how you observe, prioritise and reason about trade-offs. Two or three sharp teardowns of products relevant to the company you are applying to are more persuasive than a long generic one.

What is the difference between a product teardown and a competitive analysis?

A competitive analysis compares several products on features, pricing and positioning. A product teardown goes deep on one experience, from the user's side, and ends in specific changes. Tearing down the same flow in two rival apps combines both.

Do your next teardown with other product people

Teardowns get sharper when someone disagrees with you. If you want a regular rhythm, Product Circle runs a product teardown every two weeks, with notes in Works, Doesn't and Steal this, alongside the other parts of the membership. Membership is by application; see how to join.

• Product teardowns
• Product sense
• UX