At Canvas 26 in San Francisco. Ravi Mehta — product strategy advisor, longtime product leader, and teacher of Reforge’s AI strategy and AI prototyping courses — laid out a bold vision for product teams: unlearn the MVP, trade the assembly line for a jazz band, and expect the playbook to reset every six months.
Ravi Mehta opened his Canvas 26 session in San Francisco with a frank message for the product leaders in the room: the best practices they’ve built careers on are due for a rethink, and that rethink never really stops: “Key questions to keep asking ourselves every six months is, ‘What are the unique assets that we have? What’s the unique data? What are the unique workflows? What are the unique customer insights?’”
“We gotta unlearn our best practices”
And that’s not where the questions end. Next, Ravi tackled a big one: What do product teams need to unlearn?
“One of our best practices is minimum viable product. How many customers want a product that just barely solves their need? Nobody. The MVP as a best practice was not designed for customers; it was actually designed for us.”
The process used to be built to trade effort for signal, Ravi explained. You’d start with a spec that was cheap to write, then a wireframe, then a detailed design — climbing an escalation path that built conviction before anyone spent real resources on code. Reach enough conviction and you’d commit to the expensive build; come up short and you’d start over. That constraint has disappeared: working software has become so cheap to produce that standing up a prototype can be faster than writing the spec.
In its place, Ravi suggests making working software an essential part of the product development process from discovery through delivery:
“That enables us to shift from building to ship to building to learn. And if we’re building to learn, we can actually learn much faster, we can learn much better, and it allows us to elevate our bar from minimum viable product to building minimum lovable products, which actually achieve the aspiration that we had when we set out to solve a particular problem for customers.”

Building to learn changes the evidence teams run on, too: hand a working prototype to support, sales, or customers, says Ravi, and “we can actually get much more qualitative data earlier in the process.”
“It works much more like a jazz band”
The next product practice to get the ax: the assembly line. “An assembly line is like a sequence of risk-gated milestones,” Ravi said, where each stage is expensive, so you only progress from ideation to spec to design to launch when you have high conviction. “Because that whole process has collapsed, we don’t need an assembly-line model any longer. We can use a model where it works much more like a jazz band.” Everyone plays their instrument but now everyone can riff off each other.
But, Ravi noted, riffing can mean stepping on toes: What will really hurt organizations trying to go AI-native, he warned, is staying territorial about whose job is whose. When anyone can spin up a prototype, rigid role lines stop making sense. Teams have to get comfortable with some duplicated effort, some work that gets thrown away, and some crossing of team lines, all in service of a better end product.
“That comes back to a very human thing, which is being comfortable with failure, being comfortable with iteration, being comfortable with blurry lines. But the organizations that can do that really well are set up to take full advantage of AI.”
When asked whether the jazz-band approach really works for big companies, or if it’s mostly for startups, Ravi confirmed that it works for organizations of all sizes. In fact, he thinks it’s how people want to build. Echoing Tomer Cohen’s session from earlier in the day, he added that roles will have to fundamentally change, some things will flatten, and leaders have to hand teams real autonomy “to move at the speed that’s necessary right now.”
“Certain things move at AI speed. Certain things move at human speed.”
The third habit that requires rethinking, according to Ravi, is assuming every kind of work moves at the same speed. He broke it down: “There’s certain things that move at AI speed — generating code, generating documents, generating tickets. And there’s certain things that move at human speed.”
He reached for the framing Miro CEO Andrey Khusid introduced earlier that day in the keynote: “We’re seeing this inversion, where 80% of the work used to be on execution and 20% on the strategy and the thinking. Because that 80% is now moving so much faster, the focal point has moved to strategy, customer adoption, discovery, and alignment — all of the things that require humans to be in the loop.”
Watch Andrey speak about how thinking has become the entire (or at least 80% of the) job
So, what should a product leader change right away? That depends on where the organization sits on the AI transformation curve. Early on, a team holds three kinds of people:
- “The AI enthusiasts who are already using AI to work 10x faster”
- “The AI curious, who are excited about AI but just don’t know where to start”
- “The AI skeptics who are leaning back.”
The number-one move is to turn the “curious” into “enthusiasts” through mentoring, brown-bag sessions, and generous access to tools.
The organizations that have moved past that stage are building at an astonishing rate, but Ravi warns:
“The product role is shifting from prioritization to curation. When we can build lots of things, the really important thing is not to ship everything that we build, but to make sure that what we do ship really matters for the company.”

“The hardest part”
Ravi tied it all together: “The hardest part is gonna be, how do you get the humans in the loop completely aligned, completely up to speed?”
Building to learn is how you get there. By bringing together the whole team and its agents on a shared canvas, you align on the right approach before you build.