Internal tools lose the betting table — the small things that fix real customer friction stay "3 sprints away" forever. Build the playground that changes that: your APIs, your design shell, agent-ready scaffolding — and one live tool per participant by the end.
The method
The scaffold's quality determines what gets built on it. Layer one is a standardized API surface — documented contracts, so no tool reverse-engineers your systems. Layer two is a shared design shell — one navigation, one auth, one look that every tool inherits. Layer three is agent-ready scaffolding: describe the problem, and the agent generates a UI that already understands your patterns and connects to the right APIs.
The receipt: this is how apps.aampe.com was built — seven internal tools shipped outside sprint cycles, one now integrated into the main product's navigation, with the full story published. A public example of the same approach: mangoesoftheworld.com.
Agenda
Team-facing — pairs and groups from one org work their own stack.
Inventory every tool idea the team has deferred and rank the list by customer friction in the first half hour. The "3 sprints away" pile becomes visible.
Done looks like A ranked backlog the whole team agrees on.
Document contracts for two or three core systems. Every future tool inherits them instead of reverse-engineering.
Done looks like An API surface doc agents can build against.
Stand up the shared shell — navigation, auth, visual frame — from a worked starter template, adapted to your brand.
Done looks like The shell running on your stack.
Wire the harness — brief, contracts, gates — and smoke-test with a stub tool. Between sessions, each participant drafts a one-paragraph brief for their pick.
Done looks like The scaffold complete: APIs + shell + harness.
Each participant builds their tool on the shell with Claude Code — describing the problem, letting the scaffold carry consistency. Cross-review in pairs, fix by small passes.
Done looks like One real tool per participant, passing review.
Deploy every tool onto the shared shell. Then write the lab's operating note: owner, cadence, and the rule for when a tool graduates into the main product.
Done looks like Tools live, backlog re-ranked, lab owned.
Fit
The AI Workflow Audit — the audit surfaces what the lab should build. The Product Context Pipeline — pipeline outputs feed the friction ranking. AI-Ready Design Systems — system readiness feeds the shell.
FAQ
API docs or access, your design system (or at least brand tokens), one deferred tool idea per participant, and at least one person with deploy rights.
Your own hosting by default; a managed sandbox works for cohort speed. Decided per team when we scope.
Mixed teams work best. The scaffold exists so non-engineers can ship — that's the point — but standing it up in session one goes faster with one engineer in the room.
Each participant drafts their tool brief against the finished scaffold in between — so session two is all building, no setup.
Seats
Message with "Product Lab", your team size, and your stack.