Most teams do not lose the most time in Development. They lose it before Development begins.
A promising idea enters the system. Product frames the problem one way. Design sees a different user journey. Engineering is asked to estimate a solution that is still moving. Leadership wants a date. Then AI enters the workflow and helps everyone produce more material, faster.
Output accelerates. Clarity does not.
At LTK, I co-designed an AI-enhanced product development process to solve that operating problem. We built it around six stages: Ideation, Discovery, Design, Development, Launch, and Learn. The goal was not to add ceremony. It was to improve decision quality, preserve context, and reduce the rework created when teams move quickly with different assumptions.
For initiatives that did not require new customer research, the process reduced the time from Ideation to Development start from eight weeks to four. That is an important boundary. It was not a claim that every initiative shipped twice as fast. The gain came from making the early decisions, ownership, and handoffs clearer.
The process worked because AI was not the operating model. Shared ownership was.
Start with a small leadership group
Each initiative had shared ownership across Product, Design, Technical Leadership, and Engineering Management. Product owned the problem, target behavior, business outcome, and priorities. Design owned the experience and research plan. Technical Leadership owned feasibility, architecture, and system quality. Engineering Management owned delivery health, resourcing, and sustainable execution.
The group made tradeoffs together. Material decisions, changed assumptions, and scope changes were recorded where the people building the product—and the agents supporting them—could find them.
This sounds simple. It is not. Many teams say they are cross-functional while still passing work from one function to the next. Shared ownership means the difficult conversations happen before a handoff turns a disagreement into rework.
Make the working agreement explicit
We used an approach called ACE: Artifacts, Ceremonies, and Expectations.
Artifacts were the minimum living sources of truth: the product brief, decision log, designs, technical plan, backlog, measurement plan, and launch evidence. Ceremonies were only the working sessions needed to make a decision, review quality, or remove a blocker. Expectations covered decision rights, response times, stakeholder cadence, quality bars, scope-change rules, and human approval points.
ACE was not a universal checklist. A small, reversible change should not carry the same process as a cross-system or hard-to-reverse bet. The stages stayed stable; the depth changed with the risk.
Ideation: decide whether the problem deserves attention
Ideation should answer a hard question early: Is this problem important enough to investigate now?
The minimum useful evidence included the problem, target user, behavior we wanted to create, strategic fit, initial evidence, alternatives, and a relative sense of size. The exit was a real decision. A named leader funded Discovery, or the team stopped the bet.
AI was useful here for synthesizing source material, mapping assumptions, and showing where evidence was missing. It did not get to invent the strategy or approve the work.
Discovery: choose the simplest effective approach
Discovery tested value, usability, feasibility, and viability before the team became attached to a solution. We compared options, named dependencies and non-goals, and used low-confidence estimates appropriate to the stage.
This is where premature precision causes damage. An exact date attached to a half-defined idea is not rigor. It is uncertainty wearing a calendar.
AI could cluster customer feedback, compare alternatives, model scenarios, and surface contradictions. The cross-functional leaders still chose the direction and had to explain why the expected value justified the complexity.
Design: make the direction build-ready and measurable
By Design, confidence needed to rise. The team translated the selected direction into a validated flow, technical approach, explicit scope, and an instrumentation and evaluation plan. Estimates became more precise because the experience and technical decisions had exposed real dependencies.
AI could draft stories, acceptance criteria, test cases, and traceability checks. That work only helped when the source requirements, decisions, designs, and system boundaries were current. Otherwise, the agent produced a polished version of yesterday’s assumption.
Development: build with context, not just tickets
We localized requirements and decisions in GitHub so Cursor and coding agents could work from the same context as the team. For smaller, bounded tasks, agents could draft tickets and begin pull requests. Humans remained accountable for product judgment, architecture, code review, QA, and release decisions.
An agent-ready backlog item needed more than a short description. It needed the problem, user, requirements, non-goals, relevant decisions, interface boundaries, acceptance criteria, tests, permissions, observability, rollout expectations, and a named human owner.
Agents should not infer missing authority from an implementation task. That is true for a person joining the work midway through, too.
Launch: release safely enough to learn
Launch was a decision gate, not a date on a roadmap. The team needed go/no-go evidence, a rollout and rollback plan, monitoring, customer and support readiness, and clear ownership when something went wrong.
For AI products, I would add three explicit quality levels: the floor below which we do not ship, the target needed to create sustained value, and the delight level that feels meaningfully better than the prior workflow. Silent failures, human review paths, cost, latency, privacy, and tool permissions also needed to be visible before release.
The accountable humans approved the launch. AI could run readiness checks, summarize preflight results, and help monitor signals. It did not get the final vote.
Learn: close the loop
A development process that ends at Launch rewards output. A process that ends at Learn can reward outcomes.
The team compared results with the original hypothesis and threshold, reviewed qualitative feedback, segmented the data, examined incidents and quality costs, and made a recommendation: iterate, invest, scale, pause, or stop.
If every result leads to the same roadmap, it is not a learning plan. It is a launch plan wearing glasses.
The broader leadership lesson
I do not think the durable advantage is moving every idea faster. It is moving the right ideas through clearer decisions, stopping weak bets earlier, and giving teams enough shared context to build without repeatedly rediscovering what was meant.
AI can materially improve that system. It can shorten synthesis, expose gaps, draft bounded work, run checks, and help teams see changes sooner. But it multiplies the quality of the context and operating model around it. When ownership is vague and decisions are scattered, AI helps confusion move faster.
The goal is not more output. It is faster learning with clearer accountability from Ideation through Launch and back into the next decision.
