/product-teardown

Product teardown

Analyze a product in context and convert observations into transferable principles. Do not copy protected expression, brand assets, or distinctive implementation.

Choose a mode

• Page critique: one public page or screenshot.
• Marketing-site teardown: positioning, proof, pricing path, and conversion.
• Onboarding/activation teardown: first-use journey and time to value.
• Pricing/packaging teardown: plans, value metric, comparison, and purchase friction.
• Full-funnel teardown: acquisition through activation and visible retention loops.
• Comparison: evaluate multiple products on the same scoped lenses.

Infer the target product, application context, and learning objective from the request. Ask one blocking question only when the product or intended application is genuinely missing.

Evidence protocol

1. Record product, URLs or artifact names, capture date, viewport/device, authentication state, locale, and pages/states covered.
2. Distinguish visible evidence, user-provided behavior, sourced fact, and inference.
3. Cite URLs and describe the exact screen, state, or copy supporting each important finding. State access gaps rather than extrapolating.
4. Do not infer conversion, retention, revenue, strategy, or user sentiment from UI alone.

Lenses

Select only relevant lenses and explain material omissions:

• five-second comprehension and category;
• audience, alternative, differentiation, and message hierarchy;
• copy, information scent, calls to action, and objection handling;
• proof, trust, risk, privacy, and credibility;
• pricing, packaging, value metric, and purchase friction;
• navigation, primary task, empty/loading/error/recovery states;
• onboarding, activation, time to value, and progressive disclosure;
• accessibility, responsive behavior, performance cues, and inclusive design;
• visual hierarchy, typography, motion, and craft;
• visible sharing, collaboration, habit, or retention loops.

Workflow

1. Define scope and capture protocol.
2. Walk the actual journey in order, recording evidence before evaluation.
3. Evaluate relevant lenses against the product's audience and job, not generic taste.
4. Rank findings by user impact, confidence, frequency/reach, and effort.
5. Produce transferable principles with fit conditions, risks, and a concrete application to the user's product.
6. If implementation is requested, inspect the target repository before proposing or making changes.

Output contract

Return:

• scope and evidence ledger;
• concise journey or page narrative;
• findings table with evidence, lens, impact, confidence, and recommendation;
• strengths worth preserving;
• weaknesses or unanswered objections;
• transferable principles mapped to the user's product, including when not to apply them;
• access gaps and next evidence to collect.

Verify

• Capture date, routes/states, viewport, and access boundary are explicit.
• Every important claim is tied to visible or sourced evidence.
• Pricing, onboarding, and product behavior are not inferred from a landing page unless marked unknown.
• Recommendations fit the target user's product and constraints.
• Transferable principles avoid copying expression or distinctive assets.
• Findings include impact, confidence, and limitations rather than unsupported certainty.