Three-Check Product Review
Review the problem, solution, and ship readiness at three distinct gates
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 99%
The Three-Check Product Review creates three deliberate moments of alignment across an initiative. The first check approves the problem, first principles, priorities, and intended outcome before the team spends heavily. The second reviews the proposed approach, including product and design choices plus technical architecture or infrastructure. The third examines the finished work and asks whether it is ready to ship, meets the original goals, and clears the quality bar. Each gate should use a clear pre-read and include the relevant cross-functional partners so feedback does not remain trapped inside separate design or engineering reviews. Apply the process selectively: teams should retain autonomy over reversible, noncritical decisions, and small teams may need less ceremony. The aim is timely shared feedback, not leadership control over every detail.
Origin
After seeing product reviews fail when design and technical feedback happened in separate functional meetings, Skarstad described an ideal sequence of three check-ins: first principles, solution approach with technical review, and final readiness to ship.
Core principles
- 01Align on the problem before investing in a solution
- 02Review product, design, and technical implications as one team
- 03Leadership feedback should not surprise one function in isolation
- 04The final gate tests both goals and quality
- 05Review burden should match decision importance and team size
How to run it
- 1
Approve the problem
Review what the team is trying to do, what problem it is solving, the governing first principles, and what matters most. Confirm alignment before detailed design begins.
Pro tip Treat this as the most important gate because it prevents a polished solution to the wrong problem.
Watch out Skipping problem alignment often causes expensive rework at a later review.
- 2
Review the approach
Evaluate how the team intends to solve the approved problem and what it plans to build. Include product, design, engineering, and any architecture or infrastructure implications in the same shared review context.
Pro tip Send a focused pre-read that states the decisions and feedback the team needs.
Watch out Separate functional reviews can create contradictory changes that the rest of the team never hears about.
- 3
Check ship readiness
Inspect the completed experience against the original goals, first principles, and quality bar. Confirm that the relevant leaders and functions understand what will launch and feel it is ready.
Pro tip Make the final decision criteria explicit before the meeting so the review does not become open-ended taste feedback.
Watch out A final review cannot compensate for choosing the wrong problem at the start.
- 4
Scale the ceremony
Use the three gates for important work in larger or less-connected organizations. Reduce formality for small teams and let reversible, noncritical decisions move without unnecessary leadership approval.
Pro tip Standardize scheduling and attendance in large organizations so teams know how to obtain feedback without chasing leaders.
Watch out Making every change pass all three formal gates can obstruct autonomy and shipping speed.
In the wild
A team first gains approval on the customer problem and first principles. It later presents the selected design alongside an engineering architecture review, then returns with the built experience for a final goals-and-quality check before launch. Designers, engineers, product leaders, and relevant leadership receive the same context at each key point.
→ Strategic mistakes surface before build, technical constraints enter the solution review, and the final launch contains fewer surprises.
Common mistakes
Reviewing inside functional silos
Design or technical feedback given in isolation can alter the work without informing the cross-functional team that owns the whole outcome.
Waiting until the product is built
A late approval meeting discovers foundational disagreement only after the team has paid most of the implementation cost.
Gating every two-way door
Low-risk reversible choices should remain with the team so the review system protects quality without stopping delivery.
Is it for you?
Best for
Larger product organizations where leadership cannot stay in every working session and multiple functions review the same initiative.
Not ideal for
A small, tightly connected pre-product-market-fit team whose members already share context continuously.
From the episode
Nickey Skarstad (Airbnb, Etsy, Shopify, Duolingo) on translating vision into goals, operationalizing product quality, second-order decisions, brainstorming, influence, and much more