Building successful products that customers really want and love is really hard. In fact, most product efforts fail!
I opened the first post in this series with those exact words in November 2015. Eleven years later, I stand by every one of them. What I no longer stand by, at least not entirely, is what I thought the solution was. This is the final entry in the Product Discovery series, and I want to use it to reflect honestly on where the Product Discovery Canvas got things right, where the world moved past it, and how those same convictions live on in How We Work with clients today.
What the Canvas got right
When I introduced the Product Discovery Canvas, my goal was guided product discovery on a single page: something teams could approach quickly, collaboratively, and repeatedly. Put it up on a wall. Get everyone talking. Draft a vision statement. Name your users and customers. Define goals and success measures. Tell stories. Then, and this was always the heart of it, validate and learn. Pretotype it. Fake it and test it before you make it. Build, measure, learn.
The deepest conviction under all eight boxes was this: real learning comes from real users interacting with real things. Not from more meetings. Not from better decks. That conviction came from teachers I named in the first post, including David Hussman, Steve Blank, Jeff Patton, Alberto Savoia, and Eric Ries, and eleven years of client work have only strengthened it. Teams that filled out the canvas together built shared understanding. Teams that honored the blank boxes ("blanks are okay; they are a clear understanding of what the team does not yet know") avoided the trap of false confidence. Teams that pretotyped saved themselves from building products nobody wanted.
None of that has aged a day. Shared understanding still matters. Knowing what you don't know still matters. Testing before building still matter
What I'd tell my 2015 self
Here is the humbling part. The canvas, and pretotyping itself, existed because of a simple reality: building the real thing was expensive. Months of engineering, real budgets, real careers on the line. So we invented clever ways to learn without building. Landing pages. Paper prototypes. Manually delivering the service behind the scenes while the product pretended to. Faking it was a rational response to the cost of making it.
That reality has changed. In an era of agentic AI, where human domain expertise and product judgment direct AI Agents that execute at a speed humans alone cannot match, the cheapest way to test whether a product idea holds up is often to build a working version of it and put it in front of real users. Not a mockup. Not a demo. A system that runs.
The wisdom I'd offer my 2015 self is this: the canvas was never really about the boxes. It was about compressing the distance between an idea and evidence. When building was slow, a wall of sticky notes was the progress bar to evidence. Today, working software frequently is.
How We Work today: the 6-Week Product Sprint
To be clear: the canvas didn't retire. It is still in our tool belt, and we still put it to work in the Discovery Sprint (Week 0), where we align on the vision, the users, and the single most important thing the product must do before the clock starts. What changed is what happens next. The canvas no longer hands off to months of building; it hands off to weeks of building and learning with real users. Augmented, not abandoned.
That is exactly what our 6-Week Product Sprint does. It draws on two frameworks I've deployed with clients for well over a decade: the Design Sprint from Google Ventures, which proved you could answer critical business questions in five days rather than five months, and the Dojo Challenge, a six-week cycle of a small dedicated team building and learning alongside real users in tight loops. We rebuilt both for agentic AI. The phases are the same. The learning cycles are the same. What changed is who does the work, and how fast.
Phase 1 (Weeks 1–2): Concept to First Working Version. We start with the question the canvas always asked in its own way: what is the single most important thing this product must do? Everything else is deferred. That definition becomes a structured suite of acceptance and behavioral tests, presented to you (and often co-created with your team) before the first version ships. By the end of Week 2, real users are interacting with a live, deployed system that has already passed that suite.
Phase 2 (Weeks 3–4): First Version to Beta. Here the old Box 7, do customers want it?, gets answered properly. Not by what users say, but by how they actually behave: where they went, where they stopped, what confused them. Our engineers direct AI Agents to revise the product against that behavioral data. By Week 4, a measurably improved Beta is live.
Phase 3 (Weeks 5–6): Beta to Launch-Ready V1. Hardening. The test suite that has been guarding quality since Phase 1 expands to cover the edges, AI Agents and engineers hunt down bugs, and infrastructure is configured for security and real-world scale. Your team receives a complete handoff: documented code, the reasoning behind how the whole system is built, from user experience to infrastructure, and a compliance evidence package where required, built alongside the product rather than retrofitted after it.
Every phase ends at a phase gate: the build is tested against the eval suite before anything advances. And here is where an old canvas lesson matured into something sharper. Back then I said blanks are okay. Today I say: a failed phase gate in Week 2 is a successful outcome. You've learned, for six weeks of spend and not six months, that the core assumption needs to change. Either you adjust and continue, or you stop. Both decisions are far cheaper than discovering the truth in Week 24. Discovery didn't disappear from our practice. It became continuous, and it produces deployable systems instead of documents.
The through-line
Eleven years ago I asked teams to gather around a wall and be honest about what they didn't know. Today I ask them to gather around a live product and let real users tell them. The medium changed; the discipline didn't. Humans still bring the domain expertise, the product judgment, and the accountability that AI Agents cannot replace. The canvas taught us the questions. The 6-Week Product Sprint lets us answer them with working software.
This closes the Product Discovery series, but as I said in that first post, I would like to hear about your experiences. Questions, suggestions, successes, frustrations or whatever: info@agileInnov.com. And if you have a product idea that deserves evidence rather than another deck, the best next step is a 30-minute strategy call. If the sprint is a fit, we'll tell you how. If it isn't, we'll tell you that too.