Home / How We Work
How We Work
We don't build decks. We don't build pilots. We build products — deployed, user-tested, and ready for production — in a fixed six-week Product sprint.
Built on proven frameworks
The 6-Week Product Sprint draws on three frameworks that Bill Allen has deployed with clients for over a decade.
The Product Discovery Canvas — developed by Bill Allen — is guided product discovery on a single page that teams can approach quickly, collaboratively and repeatedly. The Design Sprint — developed at Google Ventures — showed that you could answer critical business questions in five days rather than five months, by building and testing with real users immediately instead of planning indefinitely.The Dojo Challenge extended that thinking across six weeks: a small, dedicated team working in tight cycles alongside real users, building and learning continuously rather than delivering a single big reveal at the end.
These frameworks have the same conviction at their core: real learning comes from real users interacting with real things. Not from more meetings. Not from better decks.
We took these frameworks and rebuilt them for an era of agentic AI. The phases are the same. The learning cycles are the same. What changed is who does the work — and how fast. Humans bring the domain expertise, product judgment, and accountability that AI Agents cannot replace. AI Agents bring the execution speed that humans alone cannot match. Together, they compress what used to take months into weeks.
Why it matters
Real users interacting with a live, deployed product in the first two weeks. Not a mockup. Not a demo. A system that runs.
Risk is explicit and bounded. If the core idea doesn't hold up in Week 2, you know before you've committed to a multi-year engagement.
Progress you can see and test. Every phase gate ends with something real — not a status report.
For regulated industries: the compliance requirements are set before the first line of code is written, and the evidence package is produced alongside the product, not after.
The 6-Week Product Sprint
We start with one question: what is the single most important thing this product must do? Everything else is deferred. Your Product Manager, our engineers, and AI Agents work collectively to build the first working version against that definition. By the end of Week 2, real users are interacting with a live, deployed system.
Our engineers direct AI Agents to build, test, and deploy variations — monitoring how real users respond and adapting in real time to answer one question: do customers want it? The Agents revise the product against that behavioral data. By Week 4, a Beta is live.
We raise the bar: AI Agents and engineers close every gap — performance, edge cases, and reliability. By Week 6, your team gets a complete handoff: documented, production-ready code; full system documentation from UX to infrastructure; and, where required, a compliance evidence package built alongside the product, not bolted on after.
For enterprise and regulated industry clients
Most AI projects treat compliance as a final step — something to address after the product is built. That approach produces two outcomes: either the compliance review delays launch by months, or the review uncovers architectural problems that are expensive to fix after the fact.
We take the opposite approach. Before the first line of code is written, we establish the compliance requirements for your industry and context. Every decision during the sprint is made against those requirements. Every agent action is logged. By Week 6, you have both a working product and the documentation your legal and compliance teams need.
This is not extra overhead. It is the only approach that produces a compliant system without a post-build remediation project. We build against two leading frameworks:
The National Institute of Standards and Technology AI Risk Management Framework. A US government standard for identifying and managing the risks of AI systems. Widely required in healthcare and financial services procurement. Our sprints produce artifacts aligned with this framework.
An international standard for AI management systems. Provides a certified, auditable structure for responsible AI deployment. Relevant for multinational clients and organizations seeking third-party certification of their AI governance practices.
For clients where data sovereignty matters
For clients in healthcare, banking, or any context where sensitive data cannot leave your infrastructure, we offer private deployment. The AI models that power the sprint run on your own servers or a private cloud environment you control. Your data never touches a third-party API.
This is not a compromise on capability. The open-weight models we deploy in private environments — including models from Meta, Mistral, and others — are competitive with leading commercial offerings for most enterprise applications. In some regulated contexts, private deployment is not just a preference — it is the only procurement option available.
Private deployment typically adds two to four weeks of infrastructure work and is priced accordingly. It also removes the procurement blocker that most AI vendors can't get past in regulated industries.
What comes next
After Week 6, many clients move directly into a governance retainer: monthly support that keeps the system current, the compliance documentation up to date, and the test suite running against production. This is how you keep a system governed rather than compliant-at-launch-and-drifting-by-month-six.
For clients ready to build further: Product Sprint 2 begins where Product Sprint 1 left off, using everything learned in the first cycle to build faster and more confidently.
Questions
Products that have a clear primary problem to solve, accessible user data, and a defined user group to test with in Weeks 2 and 4. If you're not there yet, that's exactly what the Discovery Sprint is for. The Product Sprint works best when the client can bring real users into the process — not for products that require extensive pre-launch secrecy or where user access is highly restricted.
That is a successful outcome, not a failure. A failed phase gate in Week 2 means you've learned — for six weeks of spend and not six months — that the core assumption needs to change. We diagnose what failed, adjust the scope, and decide together whether to continue with a revised approach or stop. Either decision is cheaper than finding out in Week 24.
Not during the sprint, though welcomed. You do need a Product Manager (or equivalent point of contact) who can make product decisions, provide access to required systems, and brief real users. Your engineering team becomes relevant at handoff — the codebase they receive is documented and ready for them to take over.
Yes. The Discovery Sprint (Week 0) produces an integration map that documents how the sprint product connects to your existing infrastructure. This is where we surface and resolve integration complexity before the clock starts.
It depends on scope, deployment requirements, and regulatory context — a Discovery Sprint, the full six-week build, and an optional post-launch governance retainer are priced separately. Rather than post a number that doesn't fit your situation, we'd rather walk through it live: book a free strategy call and we'll give you a real figure for your project, not a range that may not apply.
More than you might expect — in short, focused bursts. Your Product Manager works closely with our team throughout: available for check-ins, ready to provide feedback on the first version in Week 2 and the Beta in Week 4, and able to make or escalate decisions quickly. The sprint moves fast because both sides move fast.
Reference
A structured five-day process for rapidly testing and validating ideas with real users, developed at Google Ventures. Replaced months of internal debate with a compressed cycle that produces answers fast by building and testing rather than discussing.
A six-week intensive improvement cycle in which a small, dedicated team works alongside real users in rapid learning loops. The emphasis is on continuous iteration against real behavior — not planning a perfect solution in advance.
A set of tests that run automatically every time a new version of the product is built. Each test checks whether the product meets a specific agreed criterion — accuracy, response time, safety behavior. Nothing advances to the next phase until the eval suite passes.
A checkpoint at the end of each sprint phase where the build is tested against the eval suite criteria. If it passes, the sprint advances. If it fails, the sprint pauses while the team diagnoses the problem.
The National Institute of Standards and Technology AI Risk Management Framework. A US government standard that provides structured guidance for identifying, assessing, and managing the risks of AI systems.
An international standard for AI management systems, analogous to ISO 9001 for quality management. Provides a certified, auditable framework for responsible AI deployment.
AI models whose underlying structure is publicly available, allowing them to be deployed on private infrastructure rather than accessed via a third-party cloud API. Examples include Meta's Llama, Mistral, and Qwen families.
The audit-ready documentation your legal, compliance, and risk teams need to sign off on an AI system: records of what the system was built to do, how it was tested, what data it processed, what guardrails were in place, and how it performed.
Is the Product Sprint right for your project?
We'll ask about your problem, your timeline, and your constraints. If the Product Sprint is a fit, we'll tell you how. If it isn't, we'll tell you that too.