# How to plan an AI product development workflow

An AI product development workflow connects the customer problem, approved requirements, design decisions, implementation, and verification. Begin with one feature and a shared record of decisions. Assign people to approve scope, behavior, and release while AI assists with bounded tasks.

By The Design Project. Updated 2026-10-21.

## What you will make

One feature brief with owners, review points, and evidence for each acceptance criterion.

## Before you start

- A real customer problem or observed usability issue
- A shared issue tracker or project document
- Product, design, and engineering owners

## What an AI product workflow needs to connect
An AI product workflow connects customer evidence, approved requirements, design decisions, implementation, and verification. AI can help produce and inspect artifacts along that path, but the team still needs clear ownership and an agreed definition of success. Faster generation does not resolve unclear scope.

TDP’s [product-workflow article](https://designproject.io/blog/ai-product-development-workflow/) describes a shared product brain, a connected ticket, and separate code and functional QA tracks. The demonstration combines and anonymizes customer workflows; it is a process example rather than a measured result for a named client.

The walkthrough below uses a teammate-invitation feature as an illustrative exercise. Keep the example small enough to trace one requirement from the initial problem through the released behavior. Once that path is clear, apply it to more complex roadmap work.

## Step 1. Define the problem before the solution
Choose one task a customer needs to complete. Write down the current behavior, the evidence that it is a problem, and the desired outcome. For example: an account owner needs to invite a teammate without accidentally granting administrator access. Keep requests and verified observations separate so a repeated opinion does not become a fabricated user finding.

## Step 2. Turn the problem into a feature brief
Describe the happy path and the states that could change the result. For the invitation example, include an invalid address, an existing member, insufficient permissions, a request failure, and a successful invitation. Give unresolved questions an owner. AI can help draft this list, but the team must decide which rules apply.

| Brief field | Example specification |
| --- | --- |
| Actor | Account owner |
| Goal | Invite a teammate with a deliberate role choice |
| Default | Lowest approved access level |
| Failure | Preserve entered email and explain the next action |
| Acceptance | A user without permission cannot send an invitation |
| Evidence | A recorded test of permitted and prohibited actions |

## Step 3. Assign the decision points
Name who approves the requirement, who reviews the interface, and who verifies behavior. These can be the same person on a small team, but the responsibilities should remain explicit. Make design and engineering references visible in the same ticket. A prototype link should include which version was approved and what changed during review.

For example, keep the approved brief in a Linear issue, link the reviewed Figma prototype, and connect the GitHub pull request to that same issue. These are optional tools: the requirement is a traceable path from the decision to the design and implementation.

## Step 4. Build and check two tracks
Check implementation quality through the project’s normal automated checks and code review. Separately, exercise the complete user journey in the running product. A passing build cannot show whether a permission error leaves someone stranded. Ask AI to map each finding back to a specific acceptance criterion rather than producing a general “looks good” report.

## Step 5. Record what shipped
Before release, resolve blocking findings and record any consciously deferred scope. After release, update the feature document with actual behavior and links to the implementation. Preserve rejected alternatives as history, clearly separated from active rules. The next feature should start with a reliable record of what the product does today.

## Worked example: define the invitation feature before prompting
Suppose the initial request is “let account owners invite teammates.” That leaves several decisions open: who counts as an owner, which roles can be assigned, whether an invitation expires, what happens if the email already belongs to a member, and how the sender learns that delivery failed. An attractive form will not answer these questions.

Turn the request into a bounded feature brief. Separate confirmed rules from questions. For each acceptance criterion, name an observable outcome. “Works well” is not testable; “a user without invitation permission cannot submit the request” is specific enough to review in both the interface and the implementation.

| Scenario | Expected behavior to decide | Evidence to capture |
| --- | --- | --- |
| Valid new teammate | Invitation is created with the approved role | Confirmation and resulting record |
| Existing member | Explain the existing relationship | Message and no duplicate membership |
| Invalid address | Explain the format problem near the field | Entered value remains available |
| Request failure | Offer an appropriate next action | Failure state and retry behavior |
| Missing permission | Prevent the operation | UI behavior and server-side enforcement |

These rows are a starting exercise, not universal requirements. Your product may have a different role model or invitation mechanism. Ask the team to resolve those differences before an agent implements them.

## Make the ticket carry decisions across disciplines
A shared ticket should point to the problem evidence, approved brief, current design, implementation change, and QA findings. It does not need to contain every conversation. It needs to make the current decision easy to find and the supporting history easy to inspect.

When design changes an interaction during review, update the behavior description as well as the mockup. When engineering discovers a constraint, record the agreed response instead of leaving the answer in chat. The goal is that a reviewer joining tomorrow can understand the same feature without reconstructing yesterday’s conversation.

TDP’s workflow uses Linear, but the underlying requirement is traceability. Use your existing tracker if it supports the team’s working habits. A new tool will not compensate for decisions that never leave a private thread.

## Keep code review and functional QA distinct
Code review examines implementation and technical checks. Functional QA examines whether a person can complete the intended task and whether the right behavior appears in each scenario. Both matter, and neither proves the other.

A build can pass while an error message disappears before someone reads it. A beautiful prototype can show the correct permission state while the server accepts an unauthorized request. Record what each review actually covers, including any limitations of the environment or test data.

```text
Review record
Feature and version:
Acceptance criterion:
Environment and test data:
Steps performed:
Expected result:
Observed result:
Evidence:
Owner and next action:
```

Use this structure for failures as well as successes. “QA passed” without a named flow or criterion leaves the next person guessing. An agent can help collect evidence, but the accountable reviewer should resolve ambiguity and decide whether remaining issues block release.

## Scope a weekly cycle without promising a one-week feature
The TDP article describes a weekly planning and delivery rhythm, with design preparing approved work and engineering shipping scoped changes. That does not mean every feature goes from discovery to production within a week. Complex work can span cycles while individual tasks remain small and reviewable.

Break the invitation feature into outcomes the team can inspect: approved behavior, reviewed component composition, implemented flow, and verified states. Avoid splitting only by discipline if it leaves each person waiting for a complete handoff. Share enough context early for constraints to surface before the design is considered final.

## After release, close the knowledge loop
Record what shipped, what changed from the original plan, and what remains deferred. Link the final implementation and any follow-up issues. This prevents an old prototype from becoming the next agent’s source of truth.

The [product-context guide](https://designproject.io/resources/guides/set-up-product-context/) explains how to maintain those records. The [design-to-code guide](https://designproject.io/resources/guides/design-to-code-workflow/) takes the approved brief into component selection, implementation, and review.

## Completion checklist
- The problem has evidence and an accountable owner.
- Permissions, loading, empty, error, and success states are specified where relevant.
- Design and engineering use the same approved brief.
- Each acceptance criterion has a verification result.
- Shipped behavior is reflected in current documentation.

## Common questions
### Do we need Linear to use this workflow?
No. Use a tracker your team already maintains. The useful property is a traceable connection between decisions, work, and verification.
### Can AI approve the release?
Use AI to gather evidence and identify mismatches. Assign release accountability to a person with the authority and context to accept the result.

## Sources and TDP resources
- [TDP’s product development workflow](https://designproject.io/blog/ai-product-development-workflow/) describes the process and its anonymized demonstration.
- [Create PRD skill](https://github.com/thedesignproject/agent-skills/tree/main/skills/create-prd) provides a starting point for structuring a feature request.


## How We Run a Product Team with AI Agents

See the TDP team’s product workflow with AI agents. Use it alongside the guide when deciding how context, ownership, and review fit together.

[Watch the TDP walkthrough](https://www.youtube.com/watch?v=0JXV6J357VE)

## Related guides

- [How to set up product context for AI tools](https://designproject.io/resources/guides/set-up-product-context/)

- [A design-to-code workflow: from requirements to review](https://designproject.io/resources/guides/design-to-code-workflow/)

- [How to build an AI-ready design system](https://designproject.io/resources/guides/build-ai-ready-design-system/)

[Product design glossary](https://designproject.io/resources/glossary/)

Canonical: https://designproject.io/resources/guides/plan-ai-product-workflow/

## Keep learning

- [How to set up product context for AI tools](https://designproject.io/resources/guides/set-up-product-context/)
- [Claude Code vs Codex: Same prompt, same repo, very different results](https://designproject.io/blog/claude-code-vs-codex/)
- [Use the Figma MCP](https://designproject.io/resources/skills/figma-use/)