What is a product teardown?

A product teardown connects a reading of public pages to the captured pages each finding is drawn from. In coExploro’s use of the term, the product is the subject, the captured page is the source, and the finding is an observation drawn from that page. That relationship sets the scope of the statement: a finding describes something visible in the capture, such as wording, a navigation label, or the position of a control. It does not stand for everything the product contains. An audit tests a subject against stated criteria and needs evidence for each test. A review presents an assessment, which can draw on experience beyond the pages under discussion. A scorecard organizes ratings against named dimensions. A product teardown keeps the page observation and its source together; an assessment or a rating alone does not supply that connection. The persona scores shown beside a sample summarize a reading without extending the set of pages the reading covers. The same distinction applies to recommendations. Public samples carry observations, while a private teardown also carries recommendations. Reading the public version therefore means examining what the sample states about the page, preserving its date and scope, and separating that statement from any proposed change. A product teardown is defined by the link between a finding and the captured page it was drawn from, not by the presence of a verdict.

Each finding in a product teardown describes a page detail from a dated capture, and the capture date sets the day the statement covers. A dated observation supports a statement about page content without verifying the claim the page makes. The Stripe sample, captured on 8 August 2026, identifies the hero wording as 'from your first transaction to your billionth'. The words and their placement in the hero are the observation. Describing that sentence as a range across customer size is a reading of the wording. Treating it as proof of service at every point in that range goes beyond the capture. A reader of the public sample can match the quotation to the finding text, identify the named page area, and check the capture date. Any screenshot reference stays inside the private teardown, so the public finding does not provide the same access to an image source. A reader with access to that reference can check only the visible words and their placement. The image does not verify transaction capacity, contract terms, or conditions absent from the frame. Opening the vendor’s page today is a separate check with a separate date, not a replacement for the sample’s source. coExploro’s methodology describes a reading grounded in captured pages, with findings traceable to their sources and with limits where the product experience is not visible. Those limits apply to the statement even when its quoted wording is available for inspection.

A product teardown reads the same captured pages through four roles: PM, Marketing, UX, and Designer. The roles are reading roles, and their labels do not guarantee coverage or validate a finding. Each role reads the same captured evidence and flags what it would worry about. The roles organize the reading rather than supply evidence of their own. Start with the text of a finding and identify the page detail it names before considering the role attached to it. A role label does not turn an interpretation into an observable fact, and agreement between roles does not add another capture. A product teardown also gives no guarantee that every role contributes to a completed teardown. Read the findings present in the output without filling a missing perspective with an assumed judgment. When a finding joins a visible detail to an assessment, separate the description from the assessment and ask which words the source supports. The description stays tied to the page; the assessment remains a reading of that evidence. A role’s score cannot resolve missing context, and a disagreement between roles remains a matter to examine in the findings’ wording. Reading by role therefore returns to the same task each time: locate the observation, preserve its source, and name the question that the capture leaves open.

The next step after reading a product teardown is to frame a question with its evidence boundary attached. Return to the Stripe hero observation from the 8 August 2026 capture: the sentence names a range from the first transaction to the billionth. A follow-up question asks where the public pages state the conditions attached to that range. The quoted hero wording alone does not answer it. Carry the sample’s name, capture date, page area, and observation into the question so another reader can distinguish the source from the investigation still to do. Include the public sample link, and note that any screenshot reference stays inside the private teardown. Keep an unanswered question open rather than turning the absence of an answer into a statement that the information does not exist. A page outside the capture belongs to another scope, and a later visit supplies evidence from another date. The handoff can name those missing sources without endorsing a vendor, a claim, or a design change. A teammate then has a statement to check and a boundary for continuing the work. The companion framework guide organizes that continuation around scope, evidence, review, and handoff. The outcome of reading a sample is a question grounded in an observation; a decision requires evidence that addresses the question itself.