1. Courses
  2. Product Management
  3. Product Teardowns & Idea Lab
  4. Stop 1

35 minIntermediate

How to break down any product

A teardown takes a real product apart to find the decisions behind it: who it serves, what loop keeps people coming back, how it makes money and why rivals struggle to copy it. This lesson gives you a method you can reuse on any product, a one-page template, and the habit that separates a useful teardown from a screenshot tour: every claim is labelled as a sourced fact, something you saw, or your own inference.

By the end you can

  • Start a teardown from a decision you need to make, and pick the products that will answer it
  • Walk a product as every side of it uses it: customer, worker, merchant and admin
  • Map a product's core loop and find the step where the loop breaks
  • Follow the money and guess the metrics, growth loops and moat, with each claim labelled as fact, observation or inference
  • Turn a teardown into copy, adapt and avoid decisions for your own product

The everyday picture

A cook eats at a rival restaurant that is always full. She does not stop at "the curry was good". She works out what is on the plate and what is missing, guesses how it was made, and checks the price against what the ingredients cost. She watches the kitchen through the window, notices how fast tables turn on a Tuesday, and sees that the waiters take orders on tablets that print straight to the kitchen.

Then she goes home and decides. She copies the tablets, because her kitchen has the same problem with lost order slips. She adapts the curry, because her customers like it less spicy. She avoids the free refills, because the rival owns its own bakery and she would pay full price for bread. That is a teardown: take the dish apart, understand why each choice works there, and decide what fits here.

Start from a decision

A is a study of someone else's product, done so that you decide something better about your own. Without a decision, teardowns drift into screenshot tours: forty images of onboarding screens and a verdict that the colours are nice. Nobody acts on those.

So write the question first, in one sentence, before you open the app. Good teardown questions sound like these:

  • Copy: "Should the Rider app assign riders the way food-delivery apps do?"
  • Compete: "Why do some customers order from a quick-commerce app instead of ours, and what would win them back?"
  • Partner: "Should we list our stores on a grocery marketplace, or keep customers in our own app?"
  • Learn a pattern: "How do mobile wallets make it safe to send money to a phone number?"

The question decides which products to study and how deep to go. Pick from three groups. The leader in the job you care about shows what good looks like at scale. The substitute your users actually use is often more useful: for an internal tool it may be the spreadsheet, the chat group or a phone call, and Watching the work showed how to study those. A product from another industry with the same mechanism brings fresh ideas: a ride-hailing app teaches a grocery delivery team about dispatch, and a bank's approval screens teach a warehouse team about sign-offs.

The question also sets the depth. A copy question needs the mechanism in detail. A partner question needs the business model and who owns the customer. Spend your hours where the decision lives, and write one line on the other lenses.

Quick check

Imran wants to cut how long riders wait at stores for orders to be picked. Which teardown plan fits best?

Seven lenses

Look at the product through seven lenses, in this order. Each answers a different question, and together they explain why the product is built the way it is.

  1. Users and jobs. Who uses it, on every side, and what job each person hires it for (the jobs-to-be-done idea from pm-02). A food-delivery app has at least four sides: the customer, the rider, the restaurant and the platform's operations team. Products are usually shaped by the side with the hardest job, and that is rarely the customer.
  2. Core loop. The is the repeating cycle that creates value and brings people back. Write it as four to six steps that end where they began. Then find where the loop breaks: the step where a failure stops people coming back. That step is where the company spends most of its engineering, and where you will find the cleverest design.
  3. Business model. Who pays, for what, how much, and what one unit costs to deliver. How products create value covered the common models; Unit economics goes deeper. In a teardown you rarely know the real costs, so estimate them from public numbers and label the estimates.
  4. Metrics. Guess the north star and two or three input metrics the team probably watches (pm-21 explains metric trees). Read the company's own reports: what a company chooses to report to investors tells you what it manages.
  5. Growth. How new users arrive: referrals, content, sales teams, partners, or a loop where each user brings the next (Growth loops).
  6. Moat. What a well-funded rival could not copy within two years: network effects, scale, switching costs, a licence, data, or a process that took years to build (pm-10 introduced Helmer's 7 Powers; pm-30 covers marketplace moats).
  7. What you'd change. Two or three changes you would make if you ran it, each with the reason and the risk. This forces you to understand the trade-offs the team made, because most obvious improvements were rejected for a reason.
Customer orders pays item price and fees Shopper picks in the retailer's store Item missing loop breaks Delivered in slot the promise is kept Orders again a weekly habit forms More orders per store density rises more work per shopper, faster slots
The core loop of a grocery marketplace such as Instacart, as we infer it from public facts. More orders per store give each shopper more work per hour, which attracts more shoppers and opens faster slots. The loop breaks at picking: a missing item means a refund, a substitution or an unhappy customer.

Quick check

In the loop above, why does the teardown mark "item missing" as the place to look hardest?

Walk it as every side

Do the job yourself, for real, before you read anything about the product. Sign up, complete the main task, and then try the edges: cancel, ask for a refund, order something that is out of stock, lose signal halfway through, pay in cash. Write down each step, how long it took, and what the product did when something went wrong. Note the date and the app version, because products change every few weeks.

Then find the other sides. Most marketplaces publish their driver, rider, shopper or merchant apps, and many let anyone install them. Even when you can't sign up, the other side's help pages are public, and they are the richest source you have. Help centres and pricing pages describe the rules each side lives under: how payouts work, what gets an account suspended, which features need an admin. Square's pricing page, for example, says offline card payments are declined if the device does not reconnect within 24 hours. One sentence like that tells you about a hard trade-off between selling during an outage and losing money to cards that later fail.

Add three cheap sources. Job postings show what the company is building next and which skills it lacks. Engineering blogs and conference talks explain the hard parts in the company's own words; this site's system design teardowns of Uber, WhatsApp and Amazon are built from them. App store reviews sorted by "most recent" show what breaks for real users this month, though they over-represent angry people.

For an internal tool or an operations product, walking it means shadowing the work. You can't install a rival chain's store app, but you can watch your own staff use the spreadsheet that competes with yours, or visit a supplier who uses three retailers' portals and ask what each one does better.

Facts, observations and inference

Most of what makes a product work is not public. You won't see the dispatch algorithm, the fraud rules or the real cost per order. A teardown is still useful if you are clear about what you know and what you are guessing. Label every claim as one of three kinds:

  • Fact, with a source and a year. "Instacart has about 600,000 shoppers, most of whom shop fewer than 10 hours a week (company figures as reported on Wikipedia, read in 2026)."
  • Observed, with a date and the conditions. "On 3 October, on a mid-range Android phone on 4G, the app offered a replacement for a missing item before checkout."
  • Inference, with your reasoning and a confidence. "Shoppers picking from the retailer's own shelves means it needs no warehouses, so it can add a retailer in weeks (inference, medium confidence)."

Sources are not equal. From strongest to weakest: audited filings and annual reports; the company's own documentation, pricing and help pages; engineering posts and talks by the people who built it; regulators' and industry bodies' data; reputable press with named sources; your own observation; reviews and forums; and anonymous claims, which you should leave out. When an inference matters to your decision, try to upgrade it: find a filing, a help page or a person who knows.

Put a year on every fact, because products move. Square charged 2.75% per swipe in 2011; its US price for an in-person card payment is now 2.6% plus 15 cents on the free plan. A teardown that mixes the two years without saying so will mislead whoever reads it.

Fact, with a source shoppers pick in the retailer's own store ask why Inference, labelled no warehouses, so it adds retailers fast check our context Does the reason hold for us? yes partly no Copy same reason Adapt change a part Avoid reason missing
From fact to decision. A sourced fact becomes an inference about why the company chose it. The inference is checked against your own constraints before you copy, adapt or avoid the idea.

Quick check

A teardown draft says "The app is popular because its prices are the lowest in the city." How should it be labelled and improved?

From teardown to decision: copy, adapt, avoid

The last step is the only one your team will act on. For each mechanism you found, ask what made it work there. Usually it is a constraint: density (many orders close together), a rule (a licence only a few companies hold), money (years of losses funded by investors), scale (millions of users), or a habit (customers who already pay a certain way). Then ask whether that constraint holds for you.

  • Copy when the reason holds for you too. Food-delivery apps time a rider's arrival to when the food is ready because idle riders cost money. Idle riders cost Mangrove money too.
  • Adapt when the reason partly holds. A ride-hailing app raises prices when demand jumps. A grocery chain whose customers compare prices every week may get the same balancing effect with a rider rain bonus and fewer "Now" slots, without raising prices.
  • Avoid when the reason is missing. A design that only works with millions of users, years of investor funding or a licence you don't hold will fail when you copy it, however elegant it looks.

End the teardown with one test. The cheapest way to check whether a copied mechanism works for you is usually a small pilot in one store or one city, using the methods in Testing ideas cheaply.

Do it

Write a one-page teardown in about three hours, ending in a decision for your own product.

  1. Write the decision question and pick the products

    One sentence. Then choose one to three products: the leader, the substitute your users use, or a product from another industry with the same mechanism.

  2. Do the job yourself, as every side

    Complete the main task and three edge cases. Install or read up on the other sides' apps. Record steps, minutes and what happened when things went wrong, with the date and app version.

  3. Map users, jobs and the core loop

    List every side and its job. Write the loop in four to six steps and mark where it breaks.

  4. Follow the money

    Who pays, for what, and roughly how much. Estimate one unit's economics from public numbers and label each estimate.

  5. Guess the metrics, growth and moat

    Name the likely north star and two inputs, the main growth loop, and what a rival could not copy within two years.

  6. Keep an evidence log

    Every claim gets a label (fact, observed or inference), a source or a date, and a confidence for inferences. Upgrade the inferences your decision depends on.

  7. Decide and propose one test

    Copy, adapt and avoid, each with the reason that holds or doesn't. End with the cheapest test of the riskiest copy.

    Markdown
    # Teardown: Instacart (as a model for a local grocery marketplace)
Owner: Imran · Date: 14 Oct · Time spent: 3.5 hours

## Decision question
Should Mangrove list its stores on the marketplace, and how,
without losing customers who order in our own app?

## Users and jobs
- Customer: groceries delivered in a chosen slot, from a store they know
- Shopper: flexible paid hours (most work under 10 h a week) [fact, read 2026]
- Retailer: online sales without building delivery [inference]
- Brands: reach shoppers at the moment of choice (ads) [fact: ad tools since 2022]

## Core loop (breaks at: item missing at picking)
order -> shopper picks in store -> delivered in slot -> orders again
-> more orders per store -> more work per shopper -> faster slots

## Money
- Customer: item prices, delivery fee, service fee (5% when added in 2018) [fact]
- Retailer: pays the marketplace for orders [inference: terms not public]
- Brands: advertising [fact that it exists; size not checked]
- 2024: revenue about $3.38B, net income about $457M [fact]

## Metrics (guess)
North star: orders delivered as promised per week [inference]
Inputs: active customers, orders per customer, share of items found

## Growth and moat
Growth: retailers bring their own customers into the app [inference]
Moat: owns the customer relationship and order data across many
retailers (an aggregator); shopper supply in every city [inference, medium]

## Evidence log (sample)
| Claim                          | Label    | Source / date         |
|--------------------------------|----------|-----------------------|
| About 600,000 shoppers         | Fact     | Company figures, 2026 |
| Substitute offered pre-checkout| Observed | Android, 4G, 3 Oct    |
| Owns the customer relationship | Inference| Receipt and brand seen first |

## Copy / adapt / avoid for Mangrove
- Copy: substitution choice before checkout (9% of our orders have a cut item)
- Adapt: list "Later" slots only, 40 stores in one city; keep "Now" in our app
- Avoid: sharing customer contacts; their shoppers picking at our peak hours

## Test
8-week pilot. Measure new customers reached, and how many existing
Mangrove customers move their orders to the marketplace.
Stop if more than 1 in 5 pilot-city orders on the marketplace come
from our existing app customers.

Bring it to your team

Ask these when someone shares a teardown or proposes copying a competitor.

  • What decision is this teardown meant to inform, and does it end with one?
  • Which sides of the product did we actually use or study, and which did we only imagine?
  • Where does their core loop break, and what did they build at that step?
  • Which of these claims are facts with sources, which did we see ourselves, and which are our guesses?
  • What constraint makes this work for them, and does it hold for us?
  • What is the cheapest test before we copy it?

Red flags

  • Forty screenshots and no decision.
  • Claims about a company's internals with no source and no "inference" label.
  • Facts with no year, mixing an old price or feature with today's.
  • Only the customer side studied for a product whose hard problems are on the worker or merchant side.
  • "They do it, so we should" with no constraint check.

Practice

Label the claims

Here are eight lines from a teardown draft about a grocery marketplace. Label each as fact, observed or inference. For each inference, name a source that could upgrade it. Rewrite any line that is none of the three into one of them.

  1. Instacart was founded in 2012.
  2. Most of its shoppers work fewer than 10 hours a week.
  3. It makes most of its profit from advertising.
  4. When I ordered on 3 October, it offered a replacement for a missing item before checkout.
  5. Retailers list on it because they can't build their own app.
  6. It added a 5% service fee in 2018.
  7. Its north star is probably orders per active customer per month.
  8. The app is slow.
  • Lines 1, 2 and 6 are facts, and you name the kind of source (filings or company figures) and keep the year
  • Line 4 is an observation with a date
  • Lines 3, 5 and 7 are inferences, each with an upgrade source
  • You notice evidence against line 5 (the company bought a white-label store-app maker)
  • You rewrite line 8 as a measured observation
Show a model answer

1 Fact (company filings or a reliable reference, 2012). 2 Fact (company figures; record when you read them, because shopper numbers change). 3 Inference: the annual report's revenue breakdown would upgrade or kill it; without it, "advertising is a growing revenue line" is as far as you can go. 4 Observed, already dated; add the device and network. 5 Inference, and a weak one: interview two or three retailers, and note that buying a white-label store-app maker in 2018 suggests some retailers do want their own app. 6 Fact (2018). 7 Inference: check what the company reports to investors each quarter, since companies usually report what they manage. 8 None of the three; rewrite as "Observed, 4 October: search results took 3 to 4 seconds on a mid-range Android phone on 4G, five tries".

Tear down your own product as a rival would

A rival wholesaler wants to win Mangrove's partner shops. Write the seven lenses of a one-page teardown of the Partner app from the rival's point of view, using only these facts. About 1,800 independent corner shops order wholesale stock through Mangrove. About 4,000 partner orders a week; about 62% are placed in the Partner app and about 1,500 a week by phone to about 40 sales reps. About 1 phone order in 12 is corrected after delivery. About 12% of app order lines are short-shipped because the app shows stock the DC can't ship. The app is built by an outside agency. Four DCs and about 120 drivers make about 15,000 deliveries a month. End with the one weakness the rival would attack first.

  • You name at least three sides (shop owner, sales rep, DC staff or driver) and the job of each
  • Your core loop ends where it begins and names where it breaks (short-shipped lines)
  • You separate facts given here from your inferences, and label them
  • Your moat lens is honest: what is hard to copy, and what isn't
  • The weakness you pick is backed by a number from the facts
Show a model answer

Users and jobs: shop owners restock without losing a day at the market; sales reps keep their accounts and commissions; DC pickers and drivers ship what was ordered. Core loop: owner orders, DC picks, driver delivers, the shop sells, the owner reorders; it breaks when lines are short-shipped (about 12% of app lines) and the owner phones a rep next time. Business model: wholesale margin on goods; the app is a cost-saving channel (fact: about 1,500 phone orders a week take rep time). Metrics (inference): share of orders in the app (62%), lines delivered as ordered. Growth: reps move shops onto the app; no referral loop (inference). Moat: four DCs, 120 drivers and existing relationships with 1,800 shops are hard to copy; the app itself is not, because an agency built it and nothing in it is unique (inference). What the rival would attack: reliability. Promise "what you order is what arrives", because 12% short-shipping and the 1 in 12 corrected phone orders are the pain shops already feel.

Check yourself

Your team wants to add a "delivered in 15 minutes" promise because a quick-commerce rival shows one. Which teardown finding should most affect the decision?

You can't find any public information about how a delivery app assigns riders. What should the teardown do?

A teardown of a ride-hailing app recommends that Mangrove copy its in-app tipping for riders. Which question tests whether the idea transfers?

Flashcards

Open my review

Key takeaways

  • Start with a decision question; it picks the products and the depth.
  • Walk the product yourself as every side, and read the other sides' help and pricing pages.
  • Map the core loop and look hardest where it breaks.
  • Label every claim as fact, observed or inference, and put a year on every fact.
  • End with copy, adapt and avoid, each tied to a constraint, and one cheap test.

Sources and further reading

  • Instacart, Wikipedia (founding, retailers, shoppers, service fee, acquisitions and 2024 results as reported there), read October 2026
  • Aggregation Theory, Ben Thompson, Stratechery, 2015
  • Square pricing, Square, read October 2026 (offline payments rule and current card rates), and Block, Inc., Wikipedia (the 2011 rate)
  • Status as a Service, Eugene Wei, 2019
  • Hamilton Helmer, 7 Powers: The Foundations of Business Strategy, Deep Strategy, 2016
Episode transcriptTasting the rival's curry · about 10 minutes · tap any line to play from there
  1. NadiaImran, I hear a grocery marketplace emailed you this week.
  2. ImranIt did. They want to list all three hundred and twenty of our stores in their app. Millions of customers, their own shoppers, no work for us. It sounds great, which makes me nervous.
  3. NadiaGood instinct. So how will you decide?
  4. ImranI was going to download their app, take screenshots of everything, and compare it with ours.
  5. NadiaThat's what most people do, and it usually ends with forty screenshots and no decision. Today is about doing a teardown that ends with a decision.
  6. NadiaPicture a cook who eats at a rival restaurant that's always full. She doesn't stop at the curry was good. She works out what's on the plate, guesses how it was made, checks the price against what the ingredients cost.
  7. NadiaShe watches the kitchen through the window. She notices the waiters take orders on tablets that print straight to the kitchen. Then she goes home and decides.
  8. ImranDecides what, exactly?
  9. NadiaWhat to copy, what to adapt, and what to avoid. She copies the tablets, because she loses order slips too. She adapts the curry, because her customers like it milder. And she avoids the free bread refills, because the rival owns a bakery and she'd pay full price.
  10. ImranSo the point isn't the dish. It's understanding why each choice works there, and whether it would work here.
  11. NadiaExactly. And that starts before you open the app. Write your decision question in one sentence. Yours would be?
  12. ImranShould we list our stores on the marketplace, and if so how, without losing the customers who already order in our own app.
  13. NadiaGood. That question already tells you where to dig. A partner question needs the business model and who owns the customer. If your question were about copying their substitution feature, you'd dig into the mechanism instead.
  14. ImranAnd which products do I study? Their app has almost nothing public about it.
  15. NadiaPick from three groups. The leader in the job, the substitute your users actually use, and a product from another industry with the same mechanism. For you, the best documented company with the same model is Instacart, so you tear that down and label everything.
  16. ImranThen what do I actually look at?
  17. NadiaSeven lenses, in order. Users and jobs on every side. The core loop. The business model. Metrics. Growth. The moat. And finally what you'd change.
  18. ImranEvery side meaning customers and shoppers?
  19. NadiaCustomers, shoppers, the retailers, and the brands that buy ads. Products are usually shaped by the side with the hardest job, and that's rarely the customer.
  20. NadiaNow the core loop. If you can see the screen, the first diagram is a column of five boxes. If not, picture this. Customer orders. Shopper picks in the store. Delivered in the slot. Customer orders again. More orders per store.
  21. ImranAnd a dashed line loops from the bottom back up.
  22. NadiaRight. More orders per store means more work per shopper hour, which brings more shoppers and faster slots. Each turn makes the next one more likely. That's what a core loop is.
  23. NadiaThen look for where the loop breaks. In the diagram there's an orange box off to the side of the picking step. Item missing.
  24. ImranBecause a customer who gets a broken order is less likely to come back.
  25. NadiaYes. And that's where the company spends most of its engineering, so it's where the teardown learns the most. For us that's not abstract. About nine percent of our app orders have an item cut.
  26. ImranHow do I see the shopper side? I can't sign up as one of their shoppers.
  27. NadiaOften you can install the other apps. When you can't, read the other side's help and pricing pages. They describe the rules each side lives under.
  28. NadiaSquare's pricing page is a good example. It says offline card payments are declined if the device doesn't reconnect within twenty-four hours. One sentence, and you learn about a hard trade-off between selling during an outage and losing money on cards that fail later.
  29. ImranThat's exactly the question our POS team argues about.
  30. NadiaThen add job postings, engineering blogs and talks, and recent app store reviews. And use the product yourself first, with the date and the app version written down. What you saw, with a date, is worth more than an article's summary.
  31. ImranHere's my worry. Most of what matters isn't public. I won't see their costs or their algorithms.
  32. NadiaRight, so you label every claim as one of three kinds. A fact, with a source and a year. Something you observed, with a date and the conditions. Or an inference, with your reasoning and a confidence.
  33. ImranGive me one of each for Instacart.
  34. NadiaFact: it has about six hundred thousand shoppers, most working fewer than ten hours a week, by its own figures. Observed: on the third of October the app offered a replacement before checkout. Inference: shoppers pick in the retailer's own store, so it needs no warehouses and can add retailers fast.
  35. NadiaThe second diagram shows what happens next. If you're looking, it's a chain going down. A fact, then ask why, an inference, then check our context, and then a diamond that asks does the reason hold for us.
  36. ImranAnd three boxes at the bottom. Copy, adapt, avoid.
  37. NadiaYes means copy, partly means adapt, no means avoid. And put a year on every fact. Square charged two point seven five percent per swipe in two thousand eleven. Its in-person price on the free plan today is two point six percent plus fifteen cents. Mix those up and you mislead whoever reads your teardown.
  38. ImranHow do I know whether the reason holds for us?
  39. NadiaAsk what constraint made it work there. Density, a licence, years of investor money, millions of users, or a habit customers already have. Then check whether you really have the same constraint.
  40. NadiaHere's what goes wrong when you skip that. A team sees a rival's delivered in fifteen minutes badge and copies the badge. But the rival has small warehouses built for picking, accurate stock and dense neighbourhoods. The team has none of that.
  41. ImranSo the promise breaks on the first rainy evening.
  42. NadiaAnd the team has taught customers not to trust it. They copied the visible feature and missed the system behind it.
  43. ImranSo for the marketplace offer, here's where I'd land. Copy the substitution prompt before checkout, because of our nine percent. Adapt the listing: only scheduled Later slots, forty stores in one city, and keep the thirty-minute Now orders in our own app.
  44. ImranAnd avoid sharing customer contacts, or letting their shoppers pick in our stores at peak hours.
  45. NadiaWhat makes you nervous about the full listing?
  46. ImranMy inference is that the marketplace owns the customer relationship. The receipt comes from them, their brand comes first. Ben Thompson calls that an aggregator. If our two million customers start ordering through them, we've handed over the relationship.
  47. NadiaSo what's the test?
  48. ImranAn eight-week pilot. Measure the new customers we reach, and how many existing customers move their orders across. If more than one in five marketplace orders in that city come from our own app customers, we stop.
  49. NadiaThat's the method. Let me say the steps once. Write the question and pick the products. Do the job yourself as every side, edge cases too. Map the users, jobs and core loop, and mark where it breaks.
  50. NadiaFollow the money with labelled estimates. Guess the metrics, growth and moat. Keep an evidence log where every claim has its label. Then copy, adapt, avoid, and one test. About three hours for a one-page teardown.
  51. ImranAnd the lesson has the one-page template filled in for Instacart, evidence log and all.
  52. ImranFor my next review, three questions. What decision is this teardown for? Which of these claims are facts, which did we see, and which are guesses? And what constraint makes this work for them, and do we have it?
  53. NadiaAdd one. Which sides did we actually study? A lot of teardowns only look at the customer app, and the hard problems are on the worker side.
  54. NadiaHere's one to think about. You can't find anything public about how a delivery app assigns riders. What should your teardown say about dispatch? Take a second.
  55. ImranI'd describe what I can see from the rider and restaurant side, and then give my explanation of the logic, labelled as inference, with how confident I am.
  56. NadiaRight. Leaving it out loses the lens your decision might depend on. Writing your guess as a fact misleads the people who act on it.
  57. ImranLet me sum up. One, start with a decision question, and it picks the products and the depth. Two, find the core loop and look hardest where it breaks. Three, label everything, and only copy when the reason it works holds for us.
  58. NadiaGood. One nuance on the third. Avoid isn't a failure. Writing down what you won't copy, and why, is often the most useful line in the whole teardown.
  59. ImranSo next we try it on something real?
  60. NadiaNext time, mobile wallets. Why the hard part of sending money to a phone number is a shopkeeper's cash drawer.
Finished reading?Mark it complete to fill in its stop on your course line.

Use it at work

Unit economics of an order

What one order earns after delivery, packaging and payment fees, and the contribution margin.

Open in the Finance Lab
Next stopTeardown: sending money with a mobile wallet
Was this lesson helpful?
Questions and discussion

Loading the discussion…