The standard sign-on flow, the CRUD app, the templated onboarding: one-click tasks now. That's genuinely good. The now challenge lands somewhere else.
It's around the moment you try to vibe together a string of zero-shot prompts to define the thing that actually makes your product different. Left to its own tendencies, AI settles for the average of everything it has ever seen, especially if you never told it not to.
Call it "The Commodity Floor".
LLMs are statistically biased toward the average. That's the feature and the flaw.
The thing that has to clear that floor is your Innovation Pattern: the specific capability that separates your product from a commodity competitor.
It might live as a workflow, a data model, a UX decision, or a business rule. Whatever form it takes, your job is not to specify it down to every circumstance; it is to identify the one thing that cannot drift, and encode it as a constraint the AI cannot override.
Leave it implicit and it erodes toward the average, one reasonable-looking default at a time.
This isn't a new failure mode. In The Lean Startup, Eric Ries tells the story of Grockit, which built a “lazy registration” feature because it was an accepted design best practice. Testing showed it wasn't worth the effort: build capacity spent on the accepted thing, with full confidence it mattered. Build-measure-learn exists precisely to catch that. That's a fifteen-year-old lesson and it still holds.
What AI changes is the speed and the conviction: it hands you the average thing faster - and looking more finished - than anything before it. The decision of which problems are worth solving, and why, still belongs to Product. That accountability remains where it belongs.
Holding that accountability takes a structure, not just good intentions. This is where the Product Trio earns its second life.
For years it was a meeting: Product, Engineering, and Design in a room together - or the Three Amigos with QA in the mix. At its best, it was the most useful hour on the calendar. Distinct points of view; people challenging each other's positions in good faith; a synthesis no one would have reached alone. The value was never the cadence, but rather the productive tension.
That tension is the part you can rebuild.
Run the Trio as three AI personas, each holding a different accountability: strategic intent, technical feasibility, and user experience. Not one bot with three moods, but three distinct points of view, each willing to argue its corner, none required to agree with where Product wants to go. The friction is the point. You are in the room not as a supervisor checking outputs, but as the one who knows when the synthesis is right.
The architecture leverages two modes, and they are not the same job.
The first is solo: One live PM + three AI personas.
The productive tension that used to need a full room to convene is now something you can design and run on your own. Each persona holds its own line and is not required to agree with where Product wants to go. You are not looking for easy validation; you are looking for synthesis.
And you cannot dictate the answer, even though you are the one accountable for it. Dictate it, and the personas simply agree; easy agreement is the Commodity Floor by another name. So you influence, you argue, you make the case. That discipline is key.
So it's critical to be careful: in Solo mode, it's easy to be the LinkedIn evangelist. No one to convince, and nothing forcing you to face the hard part. Addy Osmani of Google calls it the 70% problem: AI produces the scaffolding fast, but the last 30% - the security, the edge cases, the behaviour under real load - stays as hard as it ever was.
Solo lets you ship the 70% and walk away from the 30%, the table stakes Product rarely had to carry before. Skip it, and the confidence comes cheap.
Done with discipline, though, Solo produces something the evangelist never keeps: proper documentation. The artifacts that the Team needs to execute effectively and honestly against the nuanced intent.
While Solo and Team are two different modes, they are part of one workflow - bridged by the worked specs, and the decisions the personas argued into shape along the way. You carry that documentation into the human room, where it becomes the engagement with the Team. The PM used to spend days building materials that described the concept. Now, less time produces higher fidelity — not a deck about the thing, but a spec, or even a prototype. The room spends its best hour interrogating something much more real.
And the human room needs to stay intact. It is the original, "organic" Product Trio: a room of real people. The only thing AI changed is that each discipline now brings its own tooling to its own work.
The room can now move faster than it used to. It doesn't stop being a room of people, and they enhance the process with what no persona can: lived experience, relationships, and a real stake in the outcome.
And just as in the real-life Trio model, the "Prewire" remains a crucial step. Because they are people, they have to be brought along, and that is what the Product Trio session is for. Align the people who matter and surface the hard questions in the room, and everything that follows - from the refinements and team syncs up to the roadmap and executive alignment - arrives already low-stakes, because the hard part already happened.
That is the whole point of a prewire. It is not a new idea, but it now matters more because the one thing AI reliably added was speed, and the temptation to browse rather than battle.
Wherever AI does the work, it does not push back the way a person would. It tends to comply. That is the trap.
One version is easy to see: dictate to the personas and they fall into line.
The quieter version, however, shows up when the output is convincingly competent. It is easy to nod it through, to mistake fluency for correctness, and to let the work run without the scrutiny it needs. AI is fast, and it is confident - but it is not accountable. You are.
The trap springs hardest when you hand the build to an autonomous agent. That is the moment the system is tested - not by the AI but by you. Hover over every decision and you smother the speed you came for; wave it all through and you are rubber-stamping work you never checked. The way out is not vigilance, but rather structure.
The structure is a clear source of truth and one rule about who may change it. The build must be guided to run against a written source of truth; the artifact the planning work hands to it, shaped between Solo and Team.
Ordinary problems - the thousand small decisions any build requires - get solved in place, by the agent, as they should. But when the build meets something the source of truth did not anticipate and cannot absorb - something that would change what the product is, and how it ultimatey ascends beyond the commodity floor - it does not get to quietly redraw the foundation.
The change routes back upstream: it becomes the input to a fresh planning session, the source of truth is revised there, and only then does the build resume against the new version.
That is change control - the discipline every regulated shop already knows - applied to AI-assisted development. The bar is deliberately high. Most problems never travel; only the ones that move the product do. Implementation can raise anything, but it cannot redefine the product on its own. That is the line that keeps strategy and build aligned, across every session, every agent, and every shortcut your newly found velocity would otherwise tempt you to take.
A framework is only worth what it survives. Mine had to survive a real product, so I built one. Vechelon is software for the way cycling clubs actually run group rides, which today is a patchwork of group chats, spreadsheets, and tribal knowledge.
My own club is serving as the first trial. The Innovation Pattern is not the app, but rather the operational layer that the tribal knowledge was doing badly. The end-to-end process requires real users, and real accountability, which was exactly why it was the right place to find out whether the process kept its integrity under the load of a real build.
Ultimately the build, along with the framework, did hold. And it held because of where it started.
The source of truth for Vechelon - meaning the charter, the PRD, and the specs - wasn't written by me and handed to the AI. I produced it in a structured planning session with the three personas, closer to a real debate than a drafting exercise. Those documents became the design the build agent worked against. From there the build ran largely on its own, until implementation hit something the documents hadn't anticipated.
I built the agent to stop at those moments rather than improvise. It surfaced the constraint, I worked the solution with it, and the change-control rule from the previous section locked the decision back into the documents before the build resumed.
That is what governance means here: not a review at the end, but a designed stopping point in the middle. The creativity is structured, not suppressed.
The result is real production software, in live trial with my own club, with a second club in Ireland weighing adoption and another lead behind that. Not a prototype. Evidence.
The mechanics underneath all this are worth naming, because they are not obvious.
The first is context.
A session starts to drift when it runs too long; coherence degrades as the window fills, and the work quietly gets worse. Context limitation is real, so design for it. The practice I landed on: end each session by having it produce a structured summary of decisions made, open questions, and inputs for the next stage, then open the next session with that document as its starting context. I usually supplement the document with a seeded prompt from the previous session. Nothing is built, it's a working habit; and you can adopt it on day one. Continuity carries forward; the noise doesn't. For the processes that recur, I did build something: reusable skill files that load the focused context on demand, so the working window stays clean.
The second is web vs. command line - where the work happens.
The web interface is for Product work, the strategy, the framing, the judgment. The command line is for development, working against files rather than a conversation that degrades. The split is not perfectly clean, but it is cognitively useful: the environment tells you which kind of thinking the moment calls for.
The third is the document set.
The charter, the PRD, the spec, the documents that have drifted toward ceremony over the years, but are now doing real structural work again. Not because anyone reads them end to end, but because they are what keeps the AI aligned to the intent across sessions, across agents, across time. The old core competencies of Product are not relics of a slower era. They are the governance layer that makes speed safe, and producing them is faster now too. The discipline is unchanged. The overhead is not.
This is also where it scales past you. In a real organization you may not own the AI environment; the tools, the models, and the infrastructure could sit elsewhere or change beneath you. But the documents travel with the work regardless. They are the guardrails that hold whether or not you control the ground they run on.
It asks for nothing: no governance, no discipline, no system. Just prompts and outputs and the comfortable feeling of progress. What it will never give you is the thing that makes your product different, because that takes a person who has encoded what "different" means, and can build from that the conditions the AI needs to protect it.
None of this changes the underlying equation as much as the hype suggests.
What AI does is put the weight back on what Product always claimed was its value: judgment, and knowing when the answer is right. The Trio worked because it forced that discipline on a human room. It works now for the same reason, and the discipline matters more, not less, because AI can move fast and confidently in the wrong direction as easily as the right one.
That is the realization: not that AI changes everything, but that it changes what it costs to be careless.
The speed is real. So is the drift. If you want a differentiated outcome, you have to build the system that earns it. The governance is not the overhead. It is the work.
---
The process described here is open-sourced as the Product Trio Agentic Process at github.com/neilstryjski-git/product-trio. Vechelon is currently in live trial; details at vechelon.productdelivered.ca, and clubs interested in trialling it can reach out to Neil directly.
Mentorship program and in-person event experiences are at an extra cost.
Join for free!Join the TPMA Slack Community with 1000+ members
Free Virtual TPMA events for the entire TPMA Season
Become the first to know about in-person events and networking opportunities
The standard sign-on flow, the CRUD app, the templated onboarding: one-click tasks now. That's genuinely good. The now challenge lands somewhere else.
It's around the moment you try to vibe together a string of zero-shot prompts to define the thing that actually makes your product different. Left to its own tendencies, AI settles for the average of everything it has ever seen, especially if you never told it not to.
Call it "The Commodity Floor".
LLMs are statistically biased toward the average. That's the feature and the flaw.
The thing that has to clear that floor is your Innovation Pattern: the specific capability that separates your product from a commodity competitor.
It might live as a workflow, a data model, a UX decision, or a business rule. Whatever form it takes, your job is not to specify it down to every circumstance; it is to identify the one thing that cannot drift, and encode it as a constraint the AI cannot override.
Leave it implicit and it erodes toward the average, one reasonable-looking default at a time.
This isn't a new failure mode. In The Lean Startup, Eric Ries tells the story of Grockit, which built a “lazy registration” feature because it was an accepted design best practice. Testing showed it wasn't worth the effort: build capacity spent on the accepted thing, with full confidence it mattered. Build-measure-learn exists precisely to catch that. That's a fifteen-year-old lesson and it still holds.
What AI changes is the speed and the conviction: it hands you the average thing faster - and looking more finished - than anything before it. The decision of which problems are worth solving, and why, still belongs to Product. That accountability remains where it belongs.
Holding that accountability takes a structure, not just good intentions. This is where the Product Trio earns its second life.
For years it was a meeting: Product, Engineering, and Design in a room together - or the Three Amigos with QA in the mix. At its best, it was the most useful hour on the calendar. Distinct points of view; people challenging each other's positions in good faith; a synthesis no one would have reached alone. The value was never the cadence, but rather the productive tension.
That tension is the part you can rebuild.
Run the Trio as three AI personas, each holding a different accountability: strategic intent, technical feasibility, and user experience. Not one bot with three moods, but three distinct points of view, each willing to argue its corner, none required to agree with where Product wants to go. The friction is the point. You are in the room not as a supervisor checking outputs, but as the one who knows when the synthesis is right.
The architecture leverages two modes, and they are not the same job.
The first is solo: One live PM + three AI personas.
The productive tension that used to need a full room to convene is now something you can design and run on your own. Each persona holds its own line and is not required to agree with where Product wants to go. You are not looking for easy validation; you are looking for synthesis.
And you cannot dictate the answer, even though you are the one accountable for it. Dictate it, and the personas simply agree; easy agreement is the Commodity Floor by another name. So you influence, you argue, you make the case. That discipline is key.
So it's critical to be careful: in Solo mode, it's easy to be the LinkedIn evangelist. No one to convince, and nothing forcing you to face the hard part. Addy Osmani of Google calls it the 70% problem: AI produces the scaffolding fast, but the last 30% - the security, the edge cases, the behaviour under real load - stays as hard as it ever was.
Solo lets you ship the 70% and walk away from the 30%, the table stakes Product rarely had to carry before. Skip it, and the confidence comes cheap.
Done with discipline, though, Solo produces something the evangelist never keeps: proper documentation. The artifacts that the Team needs to execute effectively and honestly against the nuanced intent.
While Solo and Team are two different modes, they are part of one workflow - bridged by the worked specs, and the decisions the personas argued into shape along the way. You carry that documentation into the human room, where it becomes the engagement with the Team. The PM used to spend days building materials that described the concept. Now, less time produces higher fidelity — not a deck about the thing, but a spec, or even a prototype. The room spends its best hour interrogating something much more real.
And the human room needs to stay intact. It is the original, "organic" Product Trio: a room of real people. The only thing AI changed is that each discipline now brings its own tooling to its own work.
The room can now move faster than it used to. It doesn't stop being a room of people, and they enhance the process with what no persona can: lived experience, relationships, and a real stake in the outcome.
And just as in the real-life Trio model, the "Prewire" remains a crucial step. Because they are people, they have to be brought along, and that is what the Product Trio session is for. Align the people who matter and surface the hard questions in the room, and everything that follows - from the refinements and team syncs up to the roadmap and executive alignment - arrives already low-stakes, because the hard part already happened.
That is the whole point of a prewire. It is not a new idea, but it now matters more because the one thing AI reliably added was speed, and the temptation to browse rather than battle.
Wherever AI does the work, it does not push back the way a person would. It tends to comply. That is the trap.
One version is easy to see: dictate to the personas and they fall into line.
The quieter version, however, shows up when the output is convincingly competent. It is easy to nod it through, to mistake fluency for correctness, and to let the work run without the scrutiny it needs. AI is fast, and it is confident - but it is not accountable. You are.
The trap springs hardest when you hand the build to an autonomous agent. That is the moment the system is tested - not by the AI but by you. Hover over every decision and you smother the speed you came for; wave it all through and you are rubber-stamping work you never checked. The way out is not vigilance, but rather structure.
The structure is a clear source of truth and one rule about who may change it. The build must be guided to run against a written source of truth; the artifact the planning work hands to it, shaped between Solo and Team.
Ordinary problems - the thousand small decisions any build requires - get solved in place, by the agent, as they should. But when the build meets something the source of truth did not anticipate and cannot absorb - something that would change what the product is, and how it ultimatey ascends beyond the commodity floor - it does not get to quietly redraw the foundation.
The change routes back upstream: it becomes the input to a fresh planning session, the source of truth is revised there, and only then does the build resume against the new version.
That is change control - the discipline every regulated shop already knows - applied to AI-assisted development. The bar is deliberately high. Most problems never travel; only the ones that move the product do. Implementation can raise anything, but it cannot redefine the product on its own. That is the line that keeps strategy and build aligned, across every session, every agent, and every shortcut your newly found velocity would otherwise tempt you to take.
A framework is only worth what it survives. Mine had to survive a real product, so I built one. Vechelon is software for the way cycling clubs actually run group rides, which today is a patchwork of group chats, spreadsheets, and tribal knowledge.
My own club is serving as the first trial. The Innovation Pattern is not the app, but rather the operational layer that the tribal knowledge was doing badly. The end-to-end process requires real users, and real accountability, which was exactly why it was the right place to find out whether the process kept its integrity under the load of a real build.
Ultimately the build, along with the framework, did hold. And it held because of where it started.
The source of truth for Vechelon - meaning the charter, the PRD, and the specs - wasn't written by me and handed to the AI. I produced it in a structured planning session with the three personas, closer to a real debate than a drafting exercise. Those documents became the design the build agent worked against. From there the build ran largely on its own, until implementation hit something the documents hadn't anticipated.
I built the agent to stop at those moments rather than improvise. It surfaced the constraint, I worked the solution with it, and the change-control rule from the previous section locked the decision back into the documents before the build resumed.
That is what governance means here: not a review at the end, but a designed stopping point in the middle. The creativity is structured, not suppressed.
The result is real production software, in live trial with my own club, with a second club in Ireland weighing adoption and another lead behind that. Not a prototype. Evidence.
The mechanics underneath all this are worth naming, because they are not obvious.
The first is context.
A session starts to drift when it runs too long; coherence degrades as the window fills, and the work quietly gets worse. Context limitation is real, so design for it. The practice I landed on: end each session by having it produce a structured summary of decisions made, open questions, and inputs for the next stage, then open the next session with that document as its starting context. I usually supplement the document with a seeded prompt from the previous session. Nothing is built, it's a working habit; and you can adopt it on day one. Continuity carries forward; the noise doesn't. For the processes that recur, I did build something: reusable skill files that load the focused context on demand, so the working window stays clean.
The second is web vs. command line - where the work happens.
The web interface is for Product work, the strategy, the framing, the judgment. The command line is for development, working against files rather than a conversation that degrades. The split is not perfectly clean, but it is cognitively useful: the environment tells you which kind of thinking the moment calls for.
The third is the document set.
The charter, the PRD, the spec, the documents that have drifted toward ceremony over the years, but are now doing real structural work again. Not because anyone reads them end to end, but because they are what keeps the AI aligned to the intent across sessions, across agents, across time. The old core competencies of Product are not relics of a slower era. They are the governance layer that makes speed safe, and producing them is faster now too. The discipline is unchanged. The overhead is not.
This is also where it scales past you. In a real organization you may not own the AI environment; the tools, the models, and the infrastructure could sit elsewhere or change beneath you. But the documents travel with the work regardless. They are the guardrails that hold whether or not you control the ground they run on.
It asks for nothing: no governance, no discipline, no system. Just prompts and outputs and the comfortable feeling of progress. What it will never give you is the thing that makes your product different, because that takes a person who has encoded what "different" means, and can build from that the conditions the AI needs to protect it.
None of this changes the underlying equation as much as the hype suggests.
What AI does is put the weight back on what Product always claimed was its value: judgment, and knowing when the answer is right. The Trio worked because it forced that discipline on a human room. It works now for the same reason, and the discipline matters more, not less, because AI can move fast and confidently in the wrong direction as easily as the right one.
That is the realization: not that AI changes everything, but that it changes what it costs to be careless.
The speed is real. So is the drift. If you want a differentiated outcome, you have to build the system that earns it. The governance is not the overhead. It is the work.
---
The process described here is open-sourced as the Product Trio Agentic Process at github.com/neilstryjski-git/product-trio. Vechelon is currently in live trial; details at vechelon.productdelivered.ca, and clubs interested in trialling it can reach out to Neil directly.
Toronto Product Management Association (TPMA) is a community focused on development, growth and networking of Product professionals in the Greater Toronto Area.
