Propose & Curate: How Guided AI Development Changes the Product Owner Role
When engineers build faster than Product Owners can specify,
you need a new model.
The Short Version
When an engineer guides their AI through development, features emerge in minutes to hours instead of weeks. At this speed, upfront specification is more expensive than building and discarding. Instead of "client orders, consultant delivers," a new model emerges: Propose & Curate. The engineer proposes finished features. The Product Owner decides what ships.
This fundamentally changes the Product Owner (PO) role. Less writing, more deciding.
What is Guided AI Development?
An experienced engineer guides an AI through development. They provide direction, context, and domain knowledge. The AI delivers speed, code quality, and systematic validation.
The engineer understands the client problem, makes architecture decisions, and steers direction. The AI reads the codebase, implements, tests, and validates. Neither part works without the other: AI without guidance produces technically correct but domain-irrelevant results. The engineer without AI works at conventional speed.
The AI implements a feature in 30 minutes to 4 hours. The engineer thinks ahead to the next three features in the same time.
The result is not automation. It is amplification.
The Silent Assumption in Consulting
The client pays for development time. Every hour in the wrong direction costs money and trust. Both sides invest in specification: the client wants to be sure they get what they ordered. The consultant wants to be sure they deliver what was agreed.
The silent assumption behind this: Implementation is expensive. Failed development is business-damaging. That is why everyone invests in specification, alignment, and acceptance.
This assumption was correct for decades. Guided AI Development changes the cost structure so radically that the processes built on it no longer fit.
The Economics Behind It
| Model | Feature Duration | Cost of Discarding |
|---|---|---|
| Traditional (1 developer) | 1-2 weeks | 7,500-15,000 EUR |
| Traditional (team) | 1-2 sprints | 30,000-60,000 EUR |
| Guided AI Development | 30 min to 4 hrs | 100-500 EUR |
A typical specification workshop: 2-3 hours, PO plus consultant plus domain experts. Add follow-up: writing the spec, review, approval. Total cost for a solid specification: 2,000-4,000 EUR.
In the same time, Guided AI Development can build, test, and present the feature as a finished result. The client does not see a description of what they will get. They see the result.
When failed development becomes cheaper than specification, the logic inverts. It is cheaper to build a feature and discard it than to fully specify it upfront.
Why Traditional Acceptance Does Not Work
The Bottleneck
6 features per day, one client who must accept each individually. Features pile up. The team waits. The speed advantage evaporates.
More concretely: 6 features are waiting on the staging environment. The client is reviewing feature 3. Features 4 through 6 build on it. A change request on feature 3 invalidates everything after it.
Acceptance Without an Order
Formal acceptance processes provide assurance: the client confirms they received what they ordered. But when the client did not order anything, but rather received a proposal, formal acceptance becomes foreign. The client has not placed an order to accept. They are evaluating a suggestion.
Separating Quality from Product Value
Two different questions that get conflated in the traditional model:
| Question | Who Answers | When |
|---|---|---|
| Does it work? | Engineer + AI (tests, CI, review) | Before the presentation |
| Is it secure? | Engineer + AI (security audit) | Before the presentation |
| Does it fit the product? | Client | During the presentation |
| Do we want this? | Client | During the presentation |
The engineer and AI ensure quality. The client evaluates product value. These are two different activities. In the traditional model, the client sits in acceptance testing clicking buttons. In the Propose & Curate model, they make product decisions.
Propose & Curate
The process is short: engineer and AI identify an improvement, or the client has an idea. The feature is built on a branch in 30 minutes to 4 hours. The engineer presents: what was built, why, before/after. The client decides: Accept, Reject, or Modify. Accept means merge and ship. Reject means delete the branch. Modify means adjustment and re-presentation.
Three Roles
Engineer (Navigator): Understands the client domain, identifies problems and opportunities, steers the AI, presents results. Not a prompt writer. An experienced architect who amplifies their expertise through AI.
AI (Driver): Reads the codebase, implements, tests, validates. Does not work autonomously. Every decision about architecture, scope, and direction is made by the human.
Client (Curator): Evaluates finished features. Decides what goes into the product. Sets direction without having to pre-specify every detail.
Not Only the Client Has Ideas
In traditional consulting, the client has a monopoly on requirements. The consultant executes. Guided AI Development opens three feature sources:
Client-initiated. The client describes an idea in one to three sentences. No complete spec needed. The cost of misinterpretation is low. The engineer steers the AI, the feature is built. If it does not fit, it gets adjusted.
Audit-generated. The engineer has the AI run automated audits. Product audits analyze code against engineering standards. UX audits evaluate usability heuristics per user role. Security audits identify attack vectors. The engineer filters the results, steers the AI during implementation. The client sees finished improvements, not audit reports.
Engineer-initiated. While working on a feature, the engineer spots an adjacent problem. They document it as a proposal. The client decides.
No matter where a feature comes from, the client decides whether it ships. The source changes, the decision authority does not.
In traditional consulting, this would be unthinkable: a consultant building features without being asked. "Who pays for that?" But when build costs approach zero, the question flips: "Why should I describe a problem when my consultant has already solved it?"
The New PO Role
From Commissioner to Curator
| Before | After |
|---|---|
| Writes user stories | Evaluates finished features |
| Plans sprints | Decides: ship or not? |
| Defines acceptance criteria | Checks: does this fit the product? |
| Controls implementation | Sets direction |
The key capability is no longer "writing good requirements." It is "deciding quickly and confidently what belongs in the product."
More Control, Not Less
The obvious objection: "The client loses control."
The opposite. In the traditional model, the client controls the input (specification) and hopes the output is right. In the Propose & Curate model, they control the output directly. They see the finished feature. No interpretation, no gap between requirement and implementation. No surprise at the sprint review.
Presentation: 80/20
How does the engineer show a feature?
For 80%, screenshots and screencasts suffice. Before/after, different views, mobile and desktop. The client decides in minutes.
For the remaining 20% (new workflows, changed navigation), a short call with screen sharing is more effective than automated preview infrastructure.
Rethinking Contracts
The traditional model is based on: client specifies, consultant delivers, acceptance confirms fulfillment. Time & materials or fixed price, the specification is always the foundation.
Propose & Curate breaks this open. When 60% of features were not specified by the client, there is no specification to accept against. But the commissioning stays with the client. They decide what ships. Discarded features are their directional decision, not the consultant's risk.
What changes: the consultant brings a new capability. An engineer who develops with AI delivers the output of a small team. This requires continuous training, AI tooling, and infrastructure on the consultant side. The price per person is higher, the output per euro is massively higher.
Package pricing. The client defines a goal: "Web app with 4 roles, auth, cloud deployment." Fixed price for the package. What is built within the package is the added value. Traditionally the client gets 5 features in a week. With Guided AI Development they get 30. The package price stays the same, the result multiplies.
Curation retainer. Fixed amount per time period. Engineers continuously deliver features, the client curates what ships. Higher monthly price than traditional individual developers, because AI tooling, infrastructure, and specialized engineers require investment. In return: measurable output at team level instead of individual performance.
Hybrid. Package pricing for the core (defined product goal). Curation retainer for ongoing improvements afterward. The transition is fluid: after the core package, the engineer knows the domain, the AI knows the codebase. The retainer becomes more productive, not more expensive.
Prerequisites
This model does not work everywhere.
- Low build costs. When a discarded feature costs weeks, upfront specification pays off. When it costs hours, it does not.
- Experienced engineers. Guided AI Development does not work with juniors writing prompts. It requires people who understand architecture, domain, and client needs.
- Clear presentation. The client decides in minutes. This requires visual proposals, not technical documentation.
- Trust. The client trusts the consultant to make sensible proposals. The consultant trusts the client to decide quickly.
- A PO who can curate. Not every PO is suited for this. Some need the process of specification to understand their own requirements. Writing a user story is a thinking tool for them. In the Propose & Curate model, the thinking shifts: the PO must recognize whether what was built is what they want. This requires judgment, product intuition, and decisiveness.
- Engineers who can let go. Discarded features are not failures. They are the affordable price of fast learning.
Real-World Numbers
Full-stack web app, approximately 100 API endpoints, 4 user roles, cloud infrastructure. One week, one engineer with AI.
| Metric | Traditional | Propose & Curate |
|---|---|---|
| Features per week | 3-5 | 30+ |
| Idea to ship | 2-4 weeks | 30 min to 4 hours |
| Client time per feature | 4-8 hours | 10-30 minutes |
| Discarded features | Rare (too expensive) | Regular (affordable) |
| Feature sources | 90% client | 40% client, 40% audit, 20% engineer |
60% of features were not initiated by the client.
The client curated them, not ordered them.
For the client: they get more than they ordered.
For the consultant: visible added value beyond the engagement.
Scaling: Enterprise Platform
The same model works with larger teams and higher complexity. An enterprise SaaS platform (desktop OS with window manager, AI agent studio, marketplace, sandbox for code execution, 100,000+ lines of code) was built with 7 engineers using the same approach in 4 weeks. Each engineer works with their AI at the same pace. Coordination scales, speed per engineer remains constant.
| Aspect | Client Project | Enterprise Platform |
|---|---|---|
| Team | 1 engineer + AI | 7 engineers + AI |
| Timeline | 1 week | 4 weeks |
| Features | 30+ | 150+ |
| Codebase | ~20,000 LOC | ~100,000+ LOC |
| Scope | Domain web app, 4 roles | 10 epics, desktop OS, sandbox, marketplace |
Same tech stack, same organization, same model. Each engineer works in Propose & Curate mode with their AI. The PO curates the stream from 7 parallel feature sources instead of one.
Conclusion
Guided AI Development does not just change speed. It changes the relationship between consultant and client.
The PO does not become obsolete. Their decisions become more valuable because more options are on the table. Instead of prioritizing five features per sprint, they curate the best twenty from thirty proposals.
The engineer changes too. Their value no longer lies in implementation skill alone. It lies in the ability to propose the right things together with their AI.
The AI builds. The engineer navigates. The client decides what their product becomes.
This is not a loss of control. It is a shift of control to where it has the most impact: to the question "Do we want this?" instead of "What should this look like?"
