When building is cheap, deciding becomes the product.
AI PDLC — Product Development Lifecycle. Protum's proposed approach governs product value and accountability from discovery to retirement. The Operating Model supplies organisational capabilities; SDLC supplies software delivery disciplines. Faster implementation does not guarantee lower total cost. This is not a Google-endorsed framework.
Discover
AI can synthesise research, support tickets, calls and market data. Humans check the sources and choose which customer problem is worth owning. Evidence: Sourced research, frequency, severity and a named customer segment. G1 · Problem.
Frame
Define the outcome, value hypothesis, risk tier, behaviour boundaries and the things you will not build. Version this context and supply it to the people and agents doing the work. Evidence: Outcome metric, constraints, accountable owner and risk classification. G2 · Intent & risk.
Prototype & validate
Working prototypes can shorten the path to user feedback. Test competing approaches with real users and challenge the hypothesis before committing production investment. Evidence: User test results, limitations and a production investment recommendation. G3 · Production investment.
Specify & build
Specifications, acceptance tests and evaluations become the brief. Harden or rebuild based on risk; never promote a prototype without meeting production controls. Evidence: Versioned specifications, test suites, security controls and a controlled build. Prepare release evidence.
Assure & launch
Test behaviour against the risk tier. Independent assurance supplies the assessment; the named accountable release/risk owner approves release and residual risk before launch. Evidence: Assurance findings, resolved issues, tested escalation paths and recorded approval. G4 · Release approval.
Operate, learn, retire
Monitor outcomes, behaviour drift, incidents and run cost. Feed learning back into discovery. Change or retire products that no longer justify their cost and risk, including a plan for users, data and dependencies. Evidence: Outcome trends, cost per outcome, incident reviews and retirement decisions. G5 · Continue, change or retire.
Changing: The unit of product work
Artefacts can become executable context. Iteration can shorten, inference adds a variable cost, and the product includes behaviour as well as features.
Staying the same: The reasons products win
A real customer problem, a clear owner, hard trade-offs, earned trust and distribution still matter. Faster attempts do not decide the market's verdict.
Democratising: Who gets to build and test
Domain experts, designers, operators and product managers can prototype, analyse and experiment with less dependence on an engineering queue.
Getting harder: Knowing what is real
Teams need to distinguish evidence from a convincing demo, finish production engineering, retain coherence and demonstrate how controls work.
Requirements
Earlier emphasis: A document read by people and filed away. With AI: An executable specification: intent, constraints, acceptance tests and evaluations, versioned and supplied as context to relevant agents.
Prototyping
Earlier emphasis: Wireframes followed by a build before users can try the idea. With AI: Working prototypes can reach users sooner, allowing competing versions to be tested before production investment.
Prioritisation
Earlier emphasis: Ranking driven by estimated effort and value. With AI: Evidence strength and risk-adjusted value carry more weight. Engineering effort remains relevant, especially for integration and assurance.
Definition of done
Earlier emphasis: The feature works in a demo and passes functional QA. With AI: Risk-tier evaluations cover outputs, observable tool calls, decisions and recorded traces. They do not depend on access to hidden model reasoning.
What the product is
Earlier emphasis: Features and screens with largely deterministic behaviour. With AI: Features plus behaviour: explicit boundaries, refusal conditions, permitted actions and handoffs to a human.
Unit economics
Earlier emphasis: Costs concentrated in the team and hosting. With AI: Inference and tool usage introduce variable cost per use. Pricing and margin decisions need run-cost data at feature and outcome level.
Team shape
Earlier emphasis: A product, design and engineering triad with a delivery team. With AI: Focused pods can use agents alongside specialists. Engineers direct and review agent work; risk and domain expertise join earlier.
The leverage point
Earlier emphasis: Choosing tools and vendors. With AI: Owning the harness: rules, tools, permissions, guardrails and evaluations. These are product assets with named owners, alongside model and vendor choices.
Launch
Earlier emphasis: Release notes and a go-to-market plan. With AI: A governed deployment adds risk assessment, test results, escalation paths and a scoped evidence record to the launch plan.
After launch
Earlier emphasis: Usage dashboards and a bug backlog. With AI: Continuous assurance adds outcome metrics, behaviour drift, cost per outcome and incident review as operating disciplines.
Start from a real problem
A feature built in an afternoon still consumes customer attention, support capacity and maintenance effort. Problem validation remains the first gate.
One named, accountable owner
Agents can produce code and release notes. A person remains answerable to customers, the board, auditors and regulators, and signs the relevant decisions.
Trade-offs and the word “no”
When implementation becomes easier, scope needs more deliberate limits. Strategy still means deciding what the product will leave out.
Customer trust is earned slowly
Release frequency can increase while trust still depends on consistent behaviour over time. A single incident can require months of recovery.
Distribution and go-to-market
Reaching buyers, pricing, partnerships and procurement still take human work. A faster build does not remove those constraints.
Applicable obligations
Applicable laws, sector expectations and adopted standards still apply, regardless of how software is produced. Their scope depends on the organisation, jurisdiction and use case.
Taste and judgement
Someone must define what good looks like for this customer in this context. More generated output makes that judgement more important.
Different kinds of obligation
Singapore's PDPA is law. MAS FEAT principles relate to financial-sector use cases. IMDA frameworks provide governance guidance. ISO/IEC 42001 is an AI management-system standard an organisation may adopt. Applicability requires a jurisdiction- and use-case-specific assessment; this lifecycle does not promise compliance.
Democratising: Prototyping
Operators, designers and domain experts can build an idea and put it in front of users.
Democratising: Research synthesis
Interview transcripts, tickets, reviews and call notes can be summarised and clustered, with source checking.
Democratising: Data analysis
Plain-language exploration can broaden access to product data within approved permissions.
Democratising: Experimentation volume
More variants of copy, flows and onboarding can be built and tested in parallel.
Democratising: Internal tools
Teams can build small workflow tools when ownership, data access and controls are clear.
Democratising: Documentation and localisation
Help content, release notes and language variants can be produced alongside features, with review.
Democratising: Competitive and market scanning
Monitoring can bring changes in competitors, regulation and sentiment into discovery and framing.
Getting harder: Telling evidence from theatre
A polished prototype can persuade stakeholders without showing customer value. User evidence must carry the decision.
Getting harder: Finishing production engineering
Edge cases, security, reliability and integration still need engineering. A quick first version says little about the work left to run it responsibly.
Getting harder: Staying coherent
Cheap additions can create product sprawl. Experience, data model and brand need active ownership.
Getting harder: Staying different
Easily copied features shift advantage towards proprietary data, distribution, workflow depth and verifiable trust.
Getting harder: Defining “correct”
Variable behaviour requires task-specific rubrics, representative datasets and agreed evaluation thresholds.
Getting harder: Accountability when agents act
Decisions, delegations and transactions need recorded permissions, approvals and observable action traces.
Getting harder: Governing shadow builds
Citizen-built apps and agents need an inventory, named owners and risk tiers before they touch sensitive data or production systems.
Getting harder: Cost predictability
Usage-based inference changes feature costs with customer behaviour, complicating pricing and budgets.
Getting harder: Building the next generation
Review and diagnostic skills need deliberate practice. Junior colleagues need opportunities to develop the judgement required to assess generated work.
G1: Problem
After Discover. Is this a problem real customers have, often enough to matter? Evidence: Sourced research, frequency and severity, and a named customer segment. Who decides: Product owner.
G2: Intent & risk
After Frame. What outcome do we want, what must the system never do, and how risky is it? Evidence: Outcome metric, value hypothesis, risk tier, behaviour boundaries and the “no” list. Who decides: Product owner with risk.
G3: Production investment
After Prototype & validate. Has value been shown with users, and is production investment justified? Evidence: User tests against the hypothesis and a risk-based production plan. Harden or rebuild based on risk; never promote a prototype without meeting production controls. Who decides: Product owner with engineering.
G4: Release approval
During Assure & launch, before launch. Does the evidence support release within the agreed risk appetite? Evidence: Risk-tier evaluations, observable action traces, security review, red-team findings addressed, escalation tests and documented residual risk. Independent assurance supplies the assessment. Who decides: Named accountable release/risk owner approves release and residual risk.
G5: Continue, change or retire
During Operate. Does the product still justify its run cost and risk? Evidence: Outcome trends, drift, incidents, cost per outcome, customer feedback and a change or retirement plan where needed. Who decides: Portfolio owner.
Assessment and approval
Independent assurance supplies the G4 assessment. The named accountable release/risk owner approves release and residual risk. A Trust Record brings together scoped evidence, limitations and decisions for a defined system and review period. It is not a guarantee of safety, regulator certification or automatic approval.
Product Manager: Owner of intent and evidence
Maintains the specification, defines the evaluation bar with specialists and makes product decisions using evidence from users and operations.
UX / Product Designer: Behaviour designer
Designs flows, conversations, refusals and human handoffs. Prototypes directly and defines the qualities of a good interaction.
Engineer: Arbiter of quality
Owns the harness, orchestrates agents and judges correctness, security and maintainability across the system.
QA / Tester: Evaluation and assurance engineer
Builds datasets and rubrics, tests outputs and observable action traces, and conducts adversarial exercises. Independent assessment remains separate from build where required by risk.
Risk & Compliance: Embedded risk partner
Helps set the risk tier at Frame, supports G2 and the G4 review, and keeps evidence relevant to applicable obligations. Release authority remains explicitly assigned.
Domain expert: Builder and validator
Prototypes ideas within approved boundaries and supplies domain judgement for evaluating correctness and consequences.
Data Culture
Research, usage and behaviour data are trusted, shared appropriately and fit to support decisions at each gate and provide agent context.
Adaptive Structures
Teams form around outcomes, bring in domain and risk specialists early, and adapt as evidence changes the work.
Augmented Craft
Product managers develop specification and evaluation skills; designers shape behaviour; engineers build harness ownership and review skills at scale.
Responsible Intelligence
Risk tiers, behaviour boundaries, independent assessment at G4 and ongoing TrustOps connect delivery decisions to accountable governance.
Flow Based Interactions
Work crosses gates when evidence supports the decision. Human and agent handoffs are designed with clear permissions and escalation routes.
Impact Prioritisation
Portfolio choices reflect outcomes, evidence strength and risk-adjusted cost, including decisions to change or retire work that stops earning its upkeep.
Discover maps to Intake & risk tiering
Research and a proposed use case inform intake. G1 confirms the problem before deeper investment.
Frame maps to Intake & risk tiering
G2 records intent, accountable ownership, behaviour boundaries and the risk tier that sets control depth.
Prototype & validate maps to Intake & risk tiering → Build & configure
Controlled exploration supplies user evidence. G3 authorises production investment; prototypes do not bypass production controls.
Specify & build maps to Build & configure
Outcome, constraints and acceptance criteria become versioned specifications, rules, tests and build context.
Assure & launch maps to Independent testing → Deployment gate
Independent assessment informs G4. The accountable release/risk owner approves release and residual risk before deployment.
Operate, learn, retire maps to Monitor & recertify
Operational evidence informs G5, recertification and the next discovery cycle, including controlled retirement.
Intent becomes context
The framed outcome, behaviour boundaries and acceptance criteria become specifications and rules files for build agents. Important decisions remain recorded and versioned.
One evaluation suite, clear responsibilities
Product owns the value and behaviour criteria. Engineering owns how evaluations run. Assurance assesses the evidence independently; the accountable release/risk owner makes the approval decision.
Production teaches product
Drift, incidents, customer feedback and cost per outcome feed portfolio choices and the next round of Discover.
Addy Osmani: The New SDLC with Vibe Coding
A co-author's explanation of the paper by Osmani, Saboo and Kartakis. The discussion informs the exploration-to-engineering spectrum, context and model-plus-harness concepts. See the linked paper for its author details. Source: https://addyosmani.com/blog/new-sdlc-vibe-coding
The New SDLC with Vibe Coding: linked whitepaper
The paper linked from Osmani's article, hosted on Kaggle. External engineering guidance informs this page; the six-stage PDLC and five gates are Protum's proposed application to product governance. Source: https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding
Book a consultation