Your PM remembers why a feature changed. Your engineer knows the technical constraint behind it. Your designer is working from the version discussed two meetings ago. Everyone has useful context, and everyone is missing a piece.
This is what I want our AI product development workflow to solve. At The Design Project, we're connecting meeting decisions, requirements, design references, engineering work, and QA so the next person—or agent—can pick up the work without reconstructing the entire conversation.
We call that shared context a product brain. The exciting part is that each feature leaves the team with more usable knowledge for the next one. Here's how we organize that process in Linear, including what goes into a ticket, where people make the decisions, and how we scope the work into weekly sprints.
Table of contents
- What is an AI product development workflow?
- How a product brain keeps decisions connected
- How we move work through Linear
- What belongs in a shared product requirements document?
- Why AI-assisted QA needs two tracks
- How we run weekly product sprints
- Start with one feature
What is an AI product development workflow?
An AI product development workflow is a shared process where people and AI agents turn product decisions into defined requirements, designs, code, tested behavior, and updated documentation. In our approach, each stage uses the same product context, while people remain responsible for prioritization, design judgment, technical decisions, and release approval.
The work still starts with understanding the customer and choosing what deserves attention. AI helps carry that understanding through the process: gathering requirements from conversations, drafting tickets, supporting implementation, checking acceptance criteria, and recording what changed.
That only works when the inputs are clear. A beautifully generated prototype can still skip the state a real customer will hit on their second click. Someone has to identify that state, decide how it should behave, and make sure the answer reaches everyone building and reviewing the feature.
How a product brain keeps decisions connected
A product brain is the living record of what your team knows about the product: its business rules, decisions, requirements, design notes, engineering constraints, and shipped behavior. People and agents use that record to understand both what to build and why the team chose it.
Think about what happens after a stakeholder meeting. There might be a transcript, a few Slack messages, and a ticket with half the context. By the time design starts, someone is already asking, “Wait, why did we decide that?” (Usually the person who remembers is in another meeting.)
In our process, those conversations feed the feature definition. As design and engineering make decisions, the record grows. Once the feature ships, the relevant knowledge goes back into the documentation and repository so it can inform future work.
Linear tracks the work; prototypes, conversations, and the codebase provide supporting context. The important connection is a traceable path from the original decision to the implementation and its validation. Our guide to agentic design systems covers how we organize the design side of that repository context.
How we move work through Linear
I've been using Linear with PMs, designers, and engineers because it gives us a shared place to follow the work. The demo behind this process combines and anonymizes examples from our customer workflows; it represents how we work rather than a named client case study with measured results.
Three kinds of work enter the process:
- Roadmap features: Work shaped by customer needs, stakeholder discussions, and business priorities.
- UX improvements: Targeted changes where users struggle to understand or complete something.
- Bugs: Broken behavior that needs investigation and a fix.
All three need a clear definition, relevant edge cases, visual references when useful, and a path through QA. Their scope will differ, but they should be visible to the same team.
1. Turn conversations into candidate work
AI helps surface possible tickets from the conversations and decisions feeding the product brain. Those suggestions enter the backlog for review. People still decide whether the problem matters and where it belongs in the priorities.
This preserves the product discussion. A recurring request is useful evidence, but someone still has to weigh it against customer needs, dependencies, and the work already underway.
2. Define the ticket and assign ownership
Once we validate a piece of work, we define its scope and acceptance criteria. The technical PM decides whether it needs design involvement or can move directly to engineering; AI can suggest a route.
That distinction matters for small fixes. Every ticket needs enough context to act on, but every ticket doesn't need a new prototype.
3. Make design decisions visible
When I'm working on a design task, I move between prototypes, Figma, AI tools, and stakeholder feedback. The ticket needs to carry the outcome of that work: screenshots, prototype links, walkthroughs, and the decisions made during review.
A link to a design file is more useful when it comes with an explanation of what was approved. If feedback changes a flow or introduces an exception, that decision belongs with the work so engineering and QA can use it too.
4. Build, verify, and preserve what changed
Engineering picks up the approved work, and the feature moves through code checks and functional QA. Findings and fixes stay attached to the ticket. After the required checks and human review, the team can merge and release, then update the product brain with what actually shipped.
Linear supports agents that collaborate on issues, comments, and documents, with a human retaining issue ownership when work is delegated. The exact behavior depends on the installed integration and its permissions; the full process described here requires your team's setup. See Linear's AI agents documentation.
What belongs in a shared product requirements document?
A shared product requirements document should explain the problem, scope, acceptance criteria, happy path, relevant states, edge cases, design decisions, and supporting references. Write it so a designer, engineer, coding agent, and QA reviewer can each understand the same intended behavior without needing a separate explanation.
We've been refining this ticket structure across our work. I want enough detail for someone to make the next decision confidently, with the supporting context easy to find.
| Ticket field | What to capture |
|---|---|
| Definition | A short explanation of the change and why the ticket exists. |
| Scope and exclusions | What this ticket covers and what is explicitly outside it. |
| Acceptance criteria | Observable conditions that must be true for the work to be accepted. |
| Happy path | The expected sequence when everything works. |
| States | Relevant loading, empty, success, error, or other states. |
| Edge cases | Exceptions, failure conditions, and unresolved questions. |
| Product and design decisions | Behavior, UX, and UI choices the implementation must respect. |
| References | Related conversations, tickets, screenshots, prototypes, and documentation. |
Edge cases deserve particular attention. It's easy to get excited about a working AI prototype and forget to ask what happens when the user has no data, loses their session, or cannot complete an action. These are illustrative questions to test against your feature, not requirements to paste blindly into every ticket.
The same criteria should travel through design, implementation, and QA. When an approved decision changes, update the shared definition so the next reviewer checks the current version.
Why AI-assisted QA needs two tracks
We separate code checks from functional QA because they answer different questions. The code track examines the implementation and its technical checks. The functional track examines whether the product behaves as specified, including the user flow and visual result.
| Track | What we check | What the team needs to see |
|---|---|---|
| Code | Pull request review, test coverage changes, linting, static analysis, dependency scans, types, and builds. | Review findings and technical check results. |
| Functional | Browser flows, acceptance criteria, visual regressions, and bugs uncovered during testing. | Which behaviors were checked, what passed, and what needs fixing. |
Agents can help review, execute checks, and document findings, while people review the results and resolve issues. We keep the streams independently owned so each can surface problems the other misses. Passing a build doesn't tell the designer whether the right state appears when an action fails.
The record matters here too. “QA passed” leaves the next person guessing about what was tested. A useful review records the flow, the criteria, the findings, and the fixes. Both tracks need to be ready before the feature moves forward.
How we run weekly product sprints
Our weekly product sprints start with a shared priority review and end with visible delivery. Designers prepare approved work that engineering can pick up, engineers ship scoped changes, and the team records the decisions made along the way. The scope has to fit the week for that rhythm to work.
On Monday, stakeholders, PMs, designers, and engineers review the board together. We discuss priorities, surface urgent changes, and agree on what deserves attention. Designers and engineers then work with the PM and AI to break their tasks into pieces they can realistically complete.
During the week, questions and reviews happen asynchronously or in calls. Slack helps us coordinate, but decisions need to make it back into the ticket and shared documentation. Otherwise, we're right back to depending on whoever remembers the thread.
By the end of the week, engineering is shipping completed work and design is preparing approved work for the following cycle. That doesn't mean every idea moves from discovery to production in five days. It means we deliberately scope the tasks and keep progress visible across overlapping design and engineering work.
If you're setting this up in Linear, its cycles documentation explains how to organize recurring work periods. The weekly cadence described here is our operating choice, and it depends on choosing manageable work.
Start with one feature
Choose a real feature already on your roadmap and follow its context through the entire process. Where is the original decision? Can the designer and engineer find the same acceptance criteria? Does QA know which edge cases matter? After shipping, can the next person understand why the feature works that way?
Those questions will show you where to start. Build the shared ticket, connect the references, name the owners, and keep the decisions current as the work moves. The next feature should begin with more useful context than the last one did.
At TDP, we're using this approach to help B2B SaaS teams connect product thinking, design, and engineering. If your team is ready to apply it to real roadmap work, talk to The Design Project.
