This post is a collaboration with Matthew Mamet. Matthew and I worked together for many years at TripAdvisor. More recently, we’ve both been knee-deep helping clients build in a more AI-native way. This essay grew out of what we’ve seen—and one experience Matthew had while helping a large nonprofit rethink its membership and fundraising platform.
As teams climb the AI learning curve, they’re accelerating, but new failure modes are also emerging. AI lets anyone on a product team build almost anything. That doesn’t make the team obsolete. It makes the team more important.
Matthew learned this the hard way — in a room with fifteen people.
He was helping a large nonprofit replace its membership and fundraising platform. In two days, with help from AI, he had produced a North Star document and a rough wireframe. Eighteen months earlier, the same work would have taken a designer and at least a week.
The speed felt like progress.
Then a longtime membership operations leader began picking apart the wireframe. One of the features was already live. Another one couldn’t be built at all.
Matthew had lost the room. The next morning, he met with the engineering lead to figure out what happened. The lead mentioned two features the AI had invented out of thin air. Details that were missed in the rush to put the wireframes in front of stakeholders.
In reality those details were incidental to what Matthew was trying to build alignment around, but they sank the whole meeting. Once the room lost trust in the wireframe, they lost trust in the entire process. We’ve since seen versions of the same failure across the industry. They all trace back to a missing step that product teams once took for granted.
Join me at Leaders Lab in Berlin
We’re less than a month away from Productlab Conf, and only a few tickets remain for Leaders Lab—a full-day workshop on how to lead your team through the AI era, a time ripe with opportunity and rife with challenges.
Save your spot and join me in Berlin →
The step that disappeared
Matthew moved too fast because a step had vanished — one we’ve since realized was doing more work than most teams understood.
A designer with deep system knowledge would have caught the hallucinations. Instead, the designer saw the wireframes at the same time as everyone else.
We believe this is the hidden change AI has made to product work. The old process never asked product, design, and engineering to collaborate. It forced them to. A PM needed a designer to make the idea usable. The designer needed an engineer to make it workable. The engineer needed both of them to know what was worth building.
The handoffs were slow…. and sometimes a little painful. They were also checks & balances that help teams do their best work.
Now a PM can build a prototype. A designer can ship working software. An engineer can create a credible first-pass design. AI is an average performer at most of these jobs, and average turns out to be plenty — plenty to make something polished, plausible, and ready to circulate.
We used to think of collaboration as part of the creative process. In practice, it was also the price of creation. Now it is optional.
That sounds liberating. It can also be expensive.
Why everyone shipping everything is a bad idea
We understand the obvious response: embrace the speed. Build more. Ship more. Let the data decide.
We think this is one of the strongest arguments for AI-native product development — and we don’t think it’s foolish. In consumer software and SaaS, you can let the users decide. All you need is a little traffic, a conversion event, and a decent analytics setup. Why spend weeks debating an idea when you can put it in front of customers tomorrow?
The temptation will only get stronger. AI keeps lowering the cost of turning an idea into working software. That makes “ship it and see” feel rational. But more experiments do not automatically produce more truth. Even under ideal conditions, a 95% significance threshold accepts a false positive one time in twenty. At 90%, it is one in ten.
Dashboards record behavior after launch. The quality of the work was decided earlier. Run enough average experiments and some will look like winners by chance. Slice the data enough ways and almost any result can acquire a respectable explanation.
It has the shape of rigor without the rigor.
A solo builder can now produce something polished enough to test. But, good enough is not necessarily customer-worthy.
Domain experts see what “good enough” conceals: the PM sees a weak hypothesis, the designer sees a confusing interaction, the engineer sees a technical assumption that breaks under real load.
That extra judgment improves the experiment before a customer ever enters it.
From orchestra to jazz band
We’ve come to think of the old product team as an orchestra. A conductor (the PM often with the Head of Product in the wings) set the pace. Sheet music (the OKRs) scripted each note. The performance was planned before anyone picked up an instrument.
We think the AI-native product team looks more like a jazz band.
The players still have their different instruments to play. Nobody expects the drummer to become the trumpet player because both can keep time. But the lead passes from player to player. One player introduces an idea. Another answers it. A third changes the direction. The music emerges from the exchange.
That freedom works because jazz musicians share a standard.
A standard is a playbook everyone knows cold before they sit down. The melody is understood. The chord changes are not renegotiated during the solo. The fixed part gives the players room to improvise.
We believe product teams now need the same thing.
If the process no longer forces people to collaborate, the standard has to. It must tell the team what good looks like, what is ready to ship, what everyone else is building, and what gets cut.
Without a shared standard, the room fills with competing solos.
As a builder, know where your range ends
AI has turned more people into full-stack builders. Each person’s skill profile still has peaks.
An engineer may produce a credible interface and miss the details a designer catches in seconds. A PM may build a working prototype and overlook the technical assumption that breaks under real load. Specialized judgment remains the difference between capable work and exceptional work.
Customers experience the finished product. They never see the compressed timeline or the small team behind it. Their expectations come from the best software they used that morning.
Full-stack builders need an honest map of their range. Exceptional work begins when we recognize the edge of our judgment and bring in someone whose craft goes deeper.
The question we should ask each other is simple: Does this deserve the customer’s attention?
Set the team’s bar for launch
After the nonprofit meeting, Matthew’s team wrote a rule. The next version would go through a product review meeting first, with a small internal group and the technical leads in the room. No business stakeholders. Only what survived that review would move forward later in the week.
The fix took ten minutes.
And it worked. For the rest of the engagement, the cross-functional team vetted ideas together before sharing them more broadly. We’ve both carried that lesson into our work since. That simple rule restored the collaboration that the old production process once supplied for free.
Without a shared bar, the lowest threshold wins. The person most comfortable shipping becomes the team’s de facto quality standard.
Our advice: set the bar before that happens.
Curate harder than you create
When building was scarce, product teams organized around prioritization: choose carefully what to build.
Now that building is plentiful, we believe teams need to organize around curation: choose carefully what to ship.
This is a harder shift than it appears. A roadmap can hold a dozen good ideas, each with a smart champion and a plausible case. When the cost of trying them approaches zero, “we can build it” stops being a useful filter.
Abundance needs a filter.
The strongest teams we’ve worked with make that filter explicit—sharp enough to rule out work that is good but unnecessary:
Every release must materially advance this customer outcome. If it does not, keep refining it—or do not ship it.
That is the discipline we believe AI makes more valuable. When a team can build ten plausible versions, its advantage comes from recognizing which one deserves the customer’s attention.
More prototypes give the team a wider field from which to choose the few ideas worth shipping.
Don’t let speed outrun judgment
Before the next planning cycle, we ask teams to answer three questions:
Where has AI removed a handoff that used to bring in another discipline?
What can now reach a customer without the benefit of a specialist’s judgment?
What shared standard tells the team whether the work is good enough to ship?
Matthew’s team answered these questions only after the room had gone cold. Their new rule fit on one line: product team review first, business stakeholders later. It’s a rule we now recommend to any team whose building speed has outpaced its review process.
The next draft returned to a smaller room. People who knew the customer and the system pulled at its assumptions, corrected the details, and tightened the story. By the time it reached stakeholders, it carried the judgment of the team.
That rhythm held for the rest of Matthew’s engagement. AI kept making drafts faster. The extra capacity went into more passes backstage, while stakeholders saw fewer, stronger ideas. It is the same rhythm we now try to create in our own work with teams.
As building gets cheaper, we believe this is where the advantage moves: toward teams that can turn abundant creation into work finely tuned to the customer.
The instruments are already in everyone’s hands. The hard part is deciding what deserves to be heard.
Lead your team through the AI era
Productlab Conf is less than a month away. Join me in Berlin for Leaders Lab, a full-day workshop on navigating the opportunities and challenges of the AI era. Only a few tickets remain.
This is spot on: "Full-stack builders need an honest map of their range." Many builders fall in love with the 'new' product development process which enables them to build test ship within hours or days (if it's a mobile app) but it's really the blocking and tackling that has to be thought through and the range or limitations that exist. EG now more than ever UAT and QA is critical for all types of products.