Doug

Atono is the product engineering platform that keeps product context connected to the work.

Product Plan Icon

Product Plan Icon White

Box Build icon

Product Build Icon

Product Deploy Run Icon

Product Deploy Run Icon White

Measure Linegraph Icon Blue

Measure Linegraph Icon White

Story Assistant

AI Product Development   It's an Authoring Problem, Not a Review Problem

Atono Logo

Check your email to get started. Don&rsquo;t see it? Be sure to check your spam folder.

LinkedIn Social Icon

LinkedIn Social Icon Blue 500

YouTube Social Icon

YouTube Social Icon Blue 500

Substack Social Icon

Substack Social Icon Blue 500

Your AI is downstream. The fix is upstream.

You ask Cursor to refactor part of your billing system. It reads the surrounding code, makes the changes, runs the tests, and everything passes.A week later, support flags a problem. Nothing is technically broken, but the behavior is wrong for your product. The issue isn’t that the AI failed to understand the codebase. It’s that “billing” means something specific inside your company, and that context didn’t exist in the story the AI was working from. The workflows, assumptions, constraints, and edge cases behind the feature simply weren’t there.That missing layer is <a href="/learning/what-is-product-knowledge">product context</a>: the terminology, decisions, rules, and relationships that explain how your product actually works.That's a hard category of failure, because it doesn't announce itself. Obviously broken output gets caught. <a href="/blog/ai-governance-shared-product-context">Almost-right output gets shipped,</a> and surfaces a week later when someone uses it.

Most attempts to close the context gap focus on the coding session itself. Teams add repo instructions, maintain cursor.md or <a href="/blog/why-claude-md-doesnt-scale-for-teams">CLAUDE.md files</a>, wire internal docs into the Model Context Protocol (MCP), build prompt templates, or expand retrieval so the model has more context available while it&rsquo;s coding. And in many cases it isn&rsquo;t even addressed by the team - each engineer creates their own solution to the problem resulting in further drift and duplicate effort.
Those approaches help, but over time we started noticing the same pattern: By the time an engineer or AI coding assistant is working from a story, the important product framing has already happened.
If the story itself doesn&rsquo;t carry enough product understanding, the implementation layer ends up reconstructing context after the fact. That changed how we started thinking about AI tooling for product teams.

Inside Atono, the AI workflow starts during <a class="decorated-link" href="/solutions/plan" rel="noopener" data-start="3409" data-end="3456">planning and story authoring</a>, not just implementation. A PM, tech lead, or product owner works with Story assistant to draft stories, clarify the problem being solved, and refine acceptance criteria before implementation starts.
For <a class="decorated-link" href="/solutions/product-managers" rel="noopener" data-start="3669" data-end="3716">product managers</a>, that means the first draft starts from shared product understanding rather than a blank prompt.
Story Assistant draws from the workspace <a href="/product-glossary">product Glossary</a>, a structured collection of the product&rsquo;s key concepts: feature names, workflows, screens, roles, and domain language. Each concept includes a plain-English description, related concepts, and alternate terminology the team already uses internally. The Glossary gets built from existing documentation and evolves alongside the product over time.
That matters because a lot of product understanding never gets written down cleanly. Teams know what certain terms mean internally, which workflows connect, which assumptions are safe, where edge cases tend to appear. But those details rarely survive the trip from someone&rsquo;s head into a story.
As stories get refined, Design Decisions get captured alongside the work itself: what got scoped out, which assumptions were safe, the workflows that mattered, the deferred edge cases.
When we ran our Glossary on Atono&rsquo;s own work, around 60% of AI-generated stories needed meaningful corrections. That reinforced something we were already starting to suspect &ndash; without the upstream loop, AI authoring drifts quickly, and structuring context during authoring is what catches that drift before the story reaches engineering.
When the story reaches engineering, the product context is attached &ndash; terminology correct, decisions captured, edge cases noted. Which leaves one question: how does that story get from the Atono product to the AI tool the engineer is actually using?&nbsp;&nbsp;

If you&rsquo;ve been heads down for the last year, MCP is the open standard that allows AI tools to interact with external systems and structured context. Anthropic open-sourced it in late 2024, it moved to the Linux Foundation in 2025, and at this point most major IDEs and AI tools support it in some form. Cursor, Claude Code, Copilot, Windsurf, Zed, JetBrains, Gemini, ChatGPT.
MCP matters because it gives AI tools a consistent way to access context without relying on copy-paste workflows or one-off integrations. It is the wire, not the answer. What matters is what flows through it: the context your AI is actually receiving when it starts work on a story.
<a class="decorated-link" href="/blog/introducing-atonos-mcp-server" rel="noopener" data-start="6025" data-end="6082">Atono&rsquo;s MCP server</a> uses that connection to bring the story and its surrounding product context into the development tools engineers already use.

When Cursor or Claude Code connects to the Atono MCP server and fetches a story, it&rsquo;s not just pulling a ticket title and some acceptance criteria.
The AI gets the working context around the story: the story itself, its workflow state, its attachments, and <a href="/learning/what-is-ai-context">its AI Context</a> &ndash; three sections, automatically read when the AI fetches the item:
<ul>
<li dir="ltr" aria-level="1">
Design Decisions &ndash; product and scope decisions made when the story was authored. Tradeoffs considered, acceptance criteria framing, scope boundaries, what got explicitly deferred.
</li>
<li dir="ltr" aria-level="1">
Technical Investigation &ndash; research findings, implementation constraints, prior discoveries, architectural considerations, and open questions related to the work.
</li>
<li dir="ltr" aria-level="1">
Technical Changes &ndash; the running record of implementation changes already made on this story.
</li>
</ul>
The story carries its own history forward instead of forcing engineers to reconstruct it from Slack threads, docs, and memory. By capturing Design Decisions during scoping and utilizing the Glossary throughout the process, the authoring loop ensures that the story reaching the developer tool is deeply informed by product context, rather than just being an isolated record of its own history.
This lets teams <a class="decorated-link" href="/solutions/build" rel="noopener" data-start="7687" data-end="7738">build from shared understanding</a> instead of reconstructing intent after implementation has already started.
Product context enters once, where it's cheapest to get right. It travels with the work.
<blockquote>
Couldn't I just stay on Jira and bolt this onto Cursor?
</blockquote>
Two honest answers, depending on what you're asking.
If the question is your product terminology &ndash; the Glossary is portable. <a href="/lp/get-your-glossary-built">Build it from your product docs, export it as a TSV file,</a> and drop it into your AI tool's project context as a rules file, project memory, or however your tool consumes structured context. Your AI tools get shared product concepts that otherwise live only in people's heads, regardless of where your tickets live. Any team, any stack, today.
If the question is bigger, you&rsquo;ve got a team that wants the full loop but <a class="decorated-link" href="/blog/why-modern-teams-are-moving-beyond-jira" rel="noopener" data-start="8685" data-end="8775">the organization isn&rsquo;t migrating off Jira</a>, that&rsquo;s a common situation.
For <a class="decorated-link" href="/solutions/engineering-leaders" rel="noopener" data-start="8816" data-end="8869">engineering leaders</a>, this is where the vanguard motion fits. One team adopts <a class="decorated-link" href="/product" rel="noopener" data-start="8931" data-end="8977">Atono&rsquo;s connected product workflow</a> for the work they&rsquo;re doing: Story Assistant authoring, Design Decisions captured on the story, and AI Context flowing to development tools through MCP. Overall planning, the cross-team roadmap, and the squads that aren&rsquo;t piloting stay in Jira.
The vanguard team proves the loop on real work without disrupting the rest of the organization. Teams can <a href="https://docs.atono.io/docs/import-from-linear?utm_source=chatgpt.com" target="_blank" rel="noopener">import work from Linear</a> or <a href="https://docs.atono.io/docs/import-from-jira" target="_blank" rel="noopener">import work from Jira</a>, with existing work brought into Atono rather than recreated manually.
Most teams that go this route do it in sequence: Glossary first, a vanguard team on the full loop second, broader decisions later.

If you’re trying to make Cursor or Claude Code understand your product right now, your product context is probably scattered. Some of it is in repo instructions. Some is in prompt templates or rules files. Some is in a markdown document someone wrote several months ago. Most of it isn’t written down at all.Every written copy drifts on its own, and there’s no single version because nobody owns one. That is the difference between <a rel="noopener" class="decorated-link" data-start="10425" data-end="10508" href="/learning/product-knowledge-vs-documentation">documentation and Product Knowledge</a>: documentation records pieces of the product, while Product Knowledge keeps its terminology, decisions, and relationships usable in the flow of work.Rules files and prompt templates don’t go away with Atono. They still handle code style, conventions, output format, and tool preferences. That isn’t product context, and Atono doesn’t replace it.What changes is the product-context part specifically: terminology, decisions, and the concepts behind the work. The Glossary holds the terminology in one place, with defined owners and permissions. <a rel="noopener" class="decorated-link" data-start="11067" data-end="11135" href="/blog/living-stories-in-action">Living Stories carry the specifics</a>, including scope, decisions, and edge cases, as AI Context. Product context stops being something every engineer keeps a private, drifting copy of.When the Glossary lives in Atono, whether you’re consuming it as a TSV today or through stories and MCP on the full loop, product terminology gets managed in one place, used during story authoring, and carried forward into implementation. Everyone and every AI tool reads from the same version.Two things improve when product context is structured this way: the day-to-day experience of working with AI tools, with less scaffolding to maintain and less context to reconstruct, and the quality of what they produce, with fewer almost-right stories reaching engineering and fewer problems surfacing a week after shipping.

To see the upstream loop end to end, from Story Assistant authoring to the MCP handoff in Cursor, <a class="decorated-link" href="/demo" rel="noopener" data-start="12330" data-end="12371">book a walkthrough with our team</a>.
To start with the Glossary, <a class="decorated-link" href="/lp/get-your-glossary-built" rel="noopener" data-start="12409" data-end="12490">build one from your existing product documentation</a> and export it as a TSV. It works with any AI tool on any stack, making it the lowest-friction way to see whether structured product context changes your AI output.
You can also review the <a href="https://docs.atono.io/docs/mcp-server-for-atono" target="_blank" rel="noopener">Atono MCP server documentation</a> for setup instructions. Teams of 25 or fewer can start free, with <a class="decorated-link" href="/pricing" rel="noopener" data-start="12839" data-end="12868">plans and pricing</a> available as your workspace grows.

Keep shared product context connected wherever AI works.

9 Illustration   Blog (1)

In my experience, working with mockups and prototypes early in the ideation process is a key behavior of <a href="/solutions/product-managers">successful product managers.</a> It's easy to jot down "add new feature here," but that rarely captures the real impact of a change. Once you start examining the actual UI, its behaviors, and transitions between states, you uncover nuances, edge cases, and missing logic that words alone don't reveal.
Over the years I&rsquo;ve used Balsamiq for this. The way it resembles a scribble on the back of a napkin clearly indicates it&rsquo;s not meant to be the specification and invites collaboration. But recently, AI has become my new go-to for early thinking. It can generate sample data, apply large-scale changes, and offers enough UX guidance to keep PMs from drifting too far off track.
Before we go further, this process is meant to refine ideas, not replace UX. I've led product and UX teams for 15 years, and the point of this "feature riffing" is to walk into conversations better prepared, not more prescriptive. Great UX partners need the freedom to explore. This is simply the work I do to organize my thinking before bringing them in.
With that clarified, let's dive in!

One area in Atono I want to improve is splitting stories. We believe strongly in <a href="/blog/building-above-and-below-the-story">smaller, well-scoped stories</a> and aim to decompose everything down to size medium or less. Although we have a &lsquo;Duplicate story&rsquo; feature, it doesn't quite support true splitting.
So I drafted an initial story&mdash;nothing fancy yet, but enough to get started:
<img src="https://atono-test.directus.app/assets/90514881-fc89-4f46-8b95-d9cfffbcff55.png?width=1920&amp;height=897" alt="Split Stories">
With the basics down, I wanted to see how the flow would actually feel&mdash;what the user would click, how the dialog would behave, and where friction points might appear.
Next, I grabbed a screenshot of our current story editing UI, started a new chat in Claude Desktop, uploaded the screenshot, and prompted:
I would like to create a few mockups for STORY-648. Attached is the current UI with the action menu open. Can you mock up the story page with the revised menu and the split-story UI described in AC#2?&nbsp;
Claude recognized I was referring to a story and automatically pulled the details from Atono via our <a href="/blog/introducing-atonos-mcp-server">MCP server</a>&mdash;a tool that lets Claude (or other AI tools) directly access story content, acceptance criteria, and context without me needing to copy and paste.
<img src="https://atono-test.directus.app/assets/0259b2c5-6be8-4f2e-8e56-980bcfb0d9b9.png?width=1484&amp;height=1327" alt="Feature Riffing Img 02">

Claude's first mockup added icons to each menu option&mdash;not what we use today, but easy enough to correct. I asked it to remove the icons, and it complied.
<img src="https://atono-test.directus.app/assets/810f65bc-afe9-454f-81cb-b85d25347acf.png?width=675&amp;height=529" alt="Feature Riffing Img 03">
From there I opened the new "Split story" option, and Claude built out a dialog for defining the split. After testing it for a few minutes, a hole in my original story became obvious.

I had specified that acceptance criteria (ACs) should be selectable, but I hadn&rsquo;t considered that ACs are hierarchical and that brings some other considerations to the table.
Claude revealed a scenario like this:
<img src="https://atono-test.directus.app/assets/bdbbe4bc-5a45-4ba2-b91d-7988dcc16b4d.png?width=1513&amp;height=794" alt="Feature Riffing Img 04">
Selecting a child AC without the parent raises questions:
<ul>
<li dir="ltr" aria-level="1">
Should the parent come along for context?
</li>
<li dir="ltr" aria-level="1">
If only some children are selected, should the parent be copied or moved?
</li>
<li dir="ltr" aria-level="1">
Should child ACs automatically inherit the parent's selection state?
</li>
</ul>
This is where AI becomes most valuable: the interaction exposes the blind spots you didn&rsquo;t know to look for.
To tighten the logic, I gave Claude a prompt:
Acceptance criteria are hierarchical. When a child is selected, all parents should be selected. If a parent is selected, all children should initially be selected but can be unselected. If a parent is unselected, all children should be unselected.
Claude updated the mockup to reflect this logic.
This forced me to refine the acceptance criteria in my story&mdash;and to specify that if a parent is selected without all children selected, it should be copied, not moved, to the new story to avoid losing context.

The sample ACs in the mockup weren't deep enough to really test the interactions with the user interface, so I asked Claude:
Can you add more second-level acceptance criteria so the hierarchical behavior is clearer?
This is one of AI's quiet superpowers: generating sample data. I find you get far better insights into UI behavior when the data feels real, and isn&rsquo;t Lorem Ipsum.

At this point the main flow was working, but I was curious whether there were better patterns. So I asked:
Do you have any other UI patterns you would recommend to solve the problem?
Claude suggested eight alternatives, including a split view for seeing the original and new story at the same time, and a drag-and-drop interface. I tried a few ("Let's see the Side-by-Side Split"), but ultimately felt the original dialog best demonstrated what matters most to the persona (which conveniently in this case, was me).

Before finishing, I asked:
Are there any acceptance criteria I should add to my story?
Claude caught a good one: what happens if someone tries to split without selecting any ACs to move or copy? (Side note: should I tell Claude "You are absolutely right"?)
<img src="https://atono-test.directus.app/assets/cdcb773a-0f44-4020-9eea-d4f7bbadb9b4.png?width=1422&amp;height=819" alt="Feature Riffing Img 05">
Our current <a href="/how-we-built-an-mcp-server-from-scratch">MCP server implementation</a> can create stories but not update them (I already have my first enhancement request from&hellip; myself!), so I pasted the AC in manually, had Claude update the mockup to match, and attached the HTML prototype to the story in Atono.
At this point, I felt the story was groomed and ready to pull in my UX partner and the engineering team lead to walk them through what I had and get their feedback. My UX partner can then figure out how to make the real deal in Figma so we can submit this story to the engineering team for sizing.
Here are some screenshots of the interactive mockup in action starting with the menu:
<img src="https://atono-test.directus.app/assets/8c37dfc3-7bfd-4be0-947c-bf02abecdc22.png?width=2400&amp;height=719" alt="Feature Riffing Img 06">
And the dialog for performing the split:
<img src="https://atono-test.directus.app/assets/bd83b648-9b7b-4b37-b1f2-053d52e063c6.png?width=1289&amp;height=1033" alt="Feature Riffing Img 07">

I don't own any Anthropic stock, so this is unbiased, but at the time of this article I've found the mockup interaction to work much better with Claude (Sonnet 4.5) than ChatGPT (GPT-5). Claude does a better job analyzing the screenshots I hand it and representing our user interface in the mockups it builds. It generated cleaner, higher-contrast mockups, accurately modeled hierarchical ACs, and retained the full story context from screenshots.
The same operations in ChatGPT required a lot more tuning. The first mockup was nearly invisible because of the lack of contrast, the sample acceptance criteria weren't hierarchical, and it only showed part of the story. I tuned it up a bit, but it still just didn't get to the same place as Claude.
<img src="https://atono-test.directus.app/assets/a82cc05b-60f7-487b-9c25-13f4e9a347b1.png?width=1250&amp;height=1182" alt="Feature Riffing Img 08">
With that said, even imperfect mockups are useful if you call out the gaps during collaboration. Sometimes articulating what doesn't work is as helpful as articulating what does!

Feature riffing with AI doesn't replace product discovery, UX, or engineering collaboration&mdash;it helps me show up better prepared.
A few things I&rsquo;ve learned from doing this regularly:
<ul>
<li dir="ltr" aria-level="1">
Start with the real UI, not a blank canvas.&nbsp;Screenshotting our actual story editing interface gave Claude the context it needed to generate something immediately useful.
</li>
<li dir="ltr" aria-level="1">
Use realistic data. Generic placeholders hide complexity. Real acceptance criteria with actual nesting showed me how selection logic would actually work.
</li>
<li dir="ltr" aria-level="1">
Actually click through everything. That's how I discovered the hierarchical AC problem&mdash;by trying to select a child without its parent.
</li>
<li dir="ltr" aria-level="1">
Ask what else could go wrong. Claude caught the "what if nothing is selected?" edge case I'd completely missed.
</li>
<li dir="ltr" aria-level="1">
Time-box it to 20-30 minutes. This whole session took about 20 minutes. If you're polishing pixels, you've gone too far.
</li>
</ul>
By the time I bring a story to UX and engineering, the team isn't starting from a blank slate. They're reacting, improving, and evolving the idea&mdash;not trying to decode it.
In this case, a 20-minute jam session turned a vague "make ACs selectable" into a well-defined interaction model with clear edge case handling. That's the kind of thinking that used to happen in the third refinement meeting&mdash;now it happens before the first one.
This is where AI shines: not in producing the final design, but in sharpening your understanding of what the design needs to solve.

Feature riffing works well for ideation. The harder part is turning that idea into a spec your team can actually build from.AI doesn't know your product. It knows generic SaaS patterns. Draft a story for "guest access," and the model invents acceptance criteria for a product it made up: permission groups you don’t have, a roles model that doesn’t match yours, edge cases that don’t apply. The story looks right. It isn't right. <a href="/learning/why-ai-generates-almost-right-requirements">Almost right is worse than wrong</a> – wrong gets caught in review. <a href="/blog/ai-governance-shared-product-context">Almost right ships, and engineering finds it three sprints later.</a>That’s why we built <a href="/product-glossary">Product Glossary</a>. It captures how your product actually works – the roles, workflows, permissions, and integrations that define it. In Atono, <a href="/solutions/plan">the Story Assistant uses it when PMs draft stories.</a> Outside of Atono, a TSV export drops it into Cursor, Claude Code, Copilot, or whatever your team uses. Your ticket system stays where it is.When we ran it against our own AI-generated stories, 60% needed changes before they could go to engineering. Not because the AI was bad, but because it didn't know our product.Give <a href="/learning/what-is-product-knowledge">product context</a> and it builds what you tell it to build. PMs, AI coding agents, and new hires all pull from the same shared understanding. Specs and stories that match your product don’t bounce back from engineering. That’s the quality and velocity difference. An AI that knows your product builds the right thing the first time.See it in action: Read <a href="/lp/context-gap-report">the Context Gap Report</a> – what 350 engineering teams told us about where AI breaks.

What 350 engineering teams reveal about planning, context, and AI in this report run with <a href="http://Refactoring.fm">Refactoring.fm</a> (March 2026)

MCP Server Blog

Model Context Protocol (MCP) is plumbing. What matters is what flows through it.
Doug wrote the post below in November to launch our MCP server. Six months later, I think the core idea still holds: <a href="/blog/why-ai-tools-create-coordination-chaos">AI-generated work creates a coordination problem as much as a coding problem.</a>
Most MCP servers pipe actions. Move this ticket. Create that story. Update the assignee. Useful &ndash; but automation alone doesn&rsquo;t solve the bigger issue: AI still doesn't understand your product.
Since launching the MCP server, we&rsquo;ve been expanding the context layer around those workflows. <a href="/learning/what-is-ai-context">AI Context</a> captures design decisions, investigation notes, and implementation summaries directly on backlog items as work happens, so future AI sessions &ndash; and future developers &ndash; don&rsquo;t start cold every time.
We&rsquo;ve also been working on Product Knowledge, starting with the <a href="/product-glossary">Product Glossary</a>. Teams can generate structured product context from their documentation and use it alongside AI tools and MCP workflows, instead of relying on models to infer terminology from scattered docs and ticket history.
The combination matters. MCP reduces workflow friction. AI Context preserves implementation continuity. Product Knowledge reduces context drift.
<a href="/blog/ai-governance-shared-product-context">Wrong gets caught. Almost right gets shipped.</a> An AI that generates a perfectly-formed story using the wrong definition of "subscription" will burn a sprint before the mistake surfaces in review. Plumbing without context is just faster bad work.
That&rsquo;s the developer experience problem we&rsquo;re focused on solving.
Want to see what flows through? <a href="/lp/get-your-glossary-built">We&rsquo;ll help you build your Glossary.</a>.
The original post follows. Read on for how the pipe got built.
&ndash; Daniel

Individual speed keeps improving, but team velocity hasn't caught up.
Developers fly through code with AI assistants like Claude, Cursor, Windsurf, and Copilot. But coordination still happens the old way &mdash; manual updates, browser tabs, copy-paste workflows.
The result? Your developers are fixing 10 bugs a day but spending 50 minutes just managing the coordination around those fixes.
That's not productive friction. That's just friction.
Until now, AI assistants and workflow tools spoke different languages. AI could write a fix, but it couldn't move the story, update the assignee, or document the change &mdash; because your workflow data lived somewhere else.
The <a href="/how-we-built-an-mcp-server-from-scratch">Atono MCP Server </a>bridges that gap.

The MCP Server runs locally using Docker and connects your AI tools to your Atono workspace through MCP &mdash; an emerging open standard for secure AI-to-system integration.
Think of it as an interpreter between your AI assistant and your workflow.
Once connected, your AI can:
<ul>
<li dir="ltr" aria-level="1">
Create stories from plain English descriptions
</li>
<li dir="ltr" aria-level="1">
Move work through workflow steps on <a href="/tutorials/advanced-set-up-and-customization/workflows">your team's board</a>
</li>
<li dir="ltr" aria-level="1">
Assign or reassign teammates without leaving your editor
</li>
<li dir="ltr" aria-level="1">
Document fixes automatically in natural language
</li>
<li dir="ltr" aria-level="1">
Retrieve team and workflow context so the AI understands your setup
</li>
</ul>
One conversational command. Multiple workflow actions. Zero context switching.

Let's say you're fixing a bug. You tell your AI assistant:
"I fixed the pagination issue in the API. Document it, assign to Marco, and move it to Testing."
Behind the scenes, the AI connects to your Atono MCP Server and chains three workflow-aware tools:
<ul>
<li dir="ltr" aria-level="1">
atono_document_bug_fix &rarr; adds a plain-English summary of what changed
</li>
<li dir="ltr" aria-level="1">
atono_update_bug_assignee &rarr; assigns Marco
</li>
<li dir="ltr" aria-level="1">
atono_update_bug_step &rarr; moves the bug to Testing
</li>
</ul>
The result: one command, handled safely through Atono. No browser tabs. No copy-paste. No forgetting to document what actually happened.

<div class="" data-turn-id-container="request-WEB:96ed5170-5cf1-4020-a7f7-3d80b46f1e47-21" data-is-intersecting="true">
<section class="text-token-text-primary w-full focus:outline-none has-data-writing-block:pointer-events-none [&amp;:has([data-writing-block])&gt;*]:pointer-events-auto R6Vx5W_threadScrollVars scroll-mb-[calc(var(--scroll-root-safe-area-inset-bottom,0px)+var(--thread-response-height))] scroll-mt-[calc(var(--header-height)+min(200px,max(70px,20svh)))]" dir="auto" data-turn-id="request-WEB:96ed5170-5cf1-4020-a7f7-3d80b46f1e47-21" data-turn-id-container="request-WEB:96ed5170-5cf1-4020-a7f7-3d80b46f1e47-21" data-testid="conversation-turn-44" data-turn="assistant">
<div class="text-base my-auto mx-auto pb-15 [--thread-content-margin:var(--thread-content-margin-xs,calc(var(--spacing)*4))] @w-sm/main:[--thread-content-margin:var(--thread-content-margin-sm,calc(var(--spacing)*6))] @w-lg/main:[--thread-content-margin:var(--thread-content-margin-lg,calc(var(--spacing)*16))] px-(--thread-content-margin)">
<div class="[--thread-content-max-width:40rem] @w-lg/main:[--thread-content-max-width:48rem] mx-auto max-w-(--thread-content-max-width) flex-1 group/turn-messages focus-visible:outline-hidden relative flex w-full min-w-0 flex-col agent-turn" data-conversation-screenshot-content="">
<div class="flex max-w-full flex-col gap-4 grow">
<div class="min-h-8 text-message relative flex w-full flex-col items-end gap-2 text-start break-words whitespace-normal outline-none keyboard-focused:focus-ring [.text-message+&amp;]:mt-1" dir="auto" tabindex="0" data-message-author-role="assistant" data-message-id="1944152b-7ebc-4295-a863-50d80f9628a4" data-turn-start-message="true" data-message-model-slug="gpt-5-6-thinking">
<div class="flex w-full flex-col gap-1 empty:hidden">
<div class="markdown prose dark:prose-invert wrap-break-word w-full light markdown-new-styling">
Watch our senior engineer Lex explain the decisions and challenges that shaped our approach.
</div>
</div>
</div>
</div>
</div>
</div>
</section>
</div>

Create structured stories from conversation:
"Create a story for OAuth GitHub integration. Users should be able to sign in with GitHub, we need to store tokens securely, and handle automatic token refresh. Add it to the Platform team backlog."
Your AI assistant creates a properly structured story with acceptance criteria and adds it to the backlog.
Update work as you complete it:
"I just finished the auth refactor in STORY-445. Move it to Code Review and assign to Taylor."
Your assistant handles the update while you move on to the next task.
Check story details without context-switching:
"Pull up STORY-423 and show me what acceptance criteria still need to be met."
Your assistant retrieves the story and shows you what's left to complete.
<a href="https://docs.atono.io/docs/mcp-server-for-atono#/available-tools" target="_blank" rel="noopener">See the full list of available tools in our documentation &rarr;</a>

Every context switch costs more than time &mdash; it costs momentum.
When your developers stop to manage the workflow, their focus breaks. When those updates don't make it back into your planning tool, your visibility breaks. And when coordination becomes a chore, it becomes optional &mdash; which means your system of record slowly stops reflecting reality.
The Atono MCP Server closes that loop. It gives AI assistants <a href="/solutions/build">a structured, secure way to participate in your workflow</a>, so coordination happens automatically &mdash; not as an afterthought.
<a href="/blog/5-ways-atono-helps-you-stay-in-flow-as-a-developer">Your developers stay in flow.</a> Your stories stay accurate. Your team moves together again.

When developers update workflows conversationally instead of context-switching:
<ul>
<li dir="ltr" aria-level="1">
Your product team sees reality: Stories reflect actual progress, not what someone remembered to update yesterday. No more &ldquo;wait, is this actually done?&rdquo; in standups.
</li>
<li dir="ltr" aria-level="1">
Your planning gets honest: When updating the board isn&rsquo;t a chore, your backlog reflects what&rsquo;s really happening. Velocity metrics become meaningful again.&nbsp;
</li>
<li dir="ltr" aria-level="1">
Your scaling doesn&rsquo;t break: At 20 people, manual updates are annoying. At 50, they&rsquo;re impossible. Automated coordination scales linearly while your team grows exponentially.
</li>
</ul>
The difference: Teams report shipping materially faster not because they code fast, but because coordination stops being the bottleneck.

We didn't build this as an experiment. We built it because we saw an opportunity.
Our team uses AI tools daily to write and review code. We noticed that while AI made the coding part seamless, updating the workflow still required stepping out of the editor &mdash; <a href="/blog/ai-speeding-up-the-wrong-part-of-software">even if just for a few seconds. It wasn't painful, but it was friction we didn't need.</a>
So we built MCP tools that let AI handle the coordination work in the same conversational flow where the code gets written.
Examples:
<ul>
<li dir="ltr" aria-level="1">
A document_bug_fix tool &mdash; because developers forget (or deprioritize) writing summaries after fixing things. Now the AI does it in plain English, automatically.
</li>
<li dir="ltr" aria-level="1">
Workflow updates scoped to teams &mdash; because not every team uses the same "In Progress" or "Testing" step. The tools understand your workflow, not a generic one.
</li>
<li dir="ltr" aria-level="1">
A single setup that works across AI clients &mdash; because your team uses Claude, Cursor, Windsurf, and Copilot. We didn't want to pick winners.
</li>
</ul>
We use this daily. Our developers update workflows conversationally instead of context-switching to the browser. It's not revolutionary &mdash; it's just smoother.

The MCP Server runs locally in Docker and enforces your workspace permissions at every interaction. If a developer can't see a story in Atono, they can't access it through AI tools either.
That means <a href="/tutorials/advanced-set-up-and-customization/team-backlog-owners">developers can't access private team backlogs unless they're members.</a> Can't update bugs they don't have permission to modify. Your permissions travel with your data because they're enforced at the API level, not just in the UI.
We use this daily on our own team. Every AI action respects who can do what&mdash;because shipping fast only matters if you can trust what gets shipped.

<ol>
<li dir="ltr" aria-level="1">
Install Docker Desktop (v27+).
</li>
<li dir="ltr" aria-level="1">
Run:
</li>
</ol>
<code>docker pull atonoai/atono-mcp-server:VERSION-NUMBER</code>
<ol start="3">
<li dir="ltr" aria-level="1">
Add your Atono API key in your AI tool's MCP config.
</li>
<li dir="ltr" aria-level="1">
Restart your tool &mdash; you'll see Atono listed as a server.
</li>
<li dir="ltr" aria-level="1">
Try something simple:
</li>
<ul>
<li dir="ltr" aria-level="2">
"Create a story for adding OAuth support for GitHub."
</li>
<li dir="ltr" aria-level="2">
"Move BUG-312 to Testing and assign to Sarah."
</li>
</ul>
</ol>
That's it. You've just turned your AI into a member of your workflow.
<a href="https://docs.atono.io/docs/mcp-server-for-atono#/configuration" target="_blank" rel="noopener">Need the full setup for your specific tool? View step-by-step instructions &rarr;</a>

You don't need an enterprise contract to experiment. <a href="/pricing">Atono is free for up to 25 users,</a> with unlimited issues and all features included.
No demo wall. No sandbox limits. Test it on your real backlog, with your real team, in your real workflow. Not a sanitized demo environment.

This isn't about replacing your tools &mdash; it's about connecting them.
Your developers already use AI to code faster. Now, with Atono's MCP Server, your AI can help your team coordinate faster too.
To see how it could work with your existing stack, <a href="/demo">book a walkthrough with our team.</a>.
One bridge, built for how teams actually work.

Shared context from first decision to feature usage

Atono Blog Featured Img Pm

Product managers do more than prioritize and communicate. They shape what gets built. But most tools are built for tracking progress&mdash;not doing product work.
Atono is different. It gives you one place to define stories, clarify scope, prioritize bugs, and plan releases&mdash;so you&rsquo;re not jumping between tools or cleaning up after handoffs.
Here are seven ways Atono helps product managers build better products.

Atono gives you a dedicated <a href="https://docs.atono.io/docs/story-refinement#/" target="_blank" rel="noopener">Story refinement</a> space for shaping work before it&rsquo;s assigned. You can capture rough ideas, collaborate with design or engineering, and polish the story until it&rsquo;s ready to move forward.
Only stories that are clear and scoped get assigned to a team. That means the team backlog stays focused, and sprint planning becomes about prioritizing&mdash;not cleaning up vague tickets.
Learn how Story refinement helps you stay out of backlog chaos in <a href="https://atono.substack.com/p/how-product-managers-can-avoid-becoming" target="_blank" rel="noopener">How product managers can avoid becoming backlog managers</a>.
<img src="https://atono-test.directus.app/assets/3def1982-061a-40e5-8907-ff49fd6bf852.jpg?width=2214&amp;height=1400" alt="Story Refinement PM Article">

Each <a href="https://docs.atono.io/docs/stories#/" target="_blank" rel="noopener">story in Atono</a> includes a built-in template based on best practices. It starts with a user story statement&mdash;the user, goal, and rationale&mdash;so the story is focused, actionable, and user-centered from the start.
What sets Atono apart is how it handles acceptance criteria. They&rsquo;re not just text fields&mdash;they&rsquo;re first-class objects you can interact with. You can link directly to a specific AC, and those links stay intact even if criteria are added, removed, or reordered. Comments and attachments stay with the AC itself, making it easy to discuss requirements, clarify intent, or share files like mockups and test cases&mdash;without losing context or breaking references.
Together, structured stories with referenceable, commentable ACs give your team a clear, stable definition of done&mdash;so product, design, QA, and engineering stay on the same page from planning to release. And because Atono treats ACs as first-class objects, they&rsquo;re built not just for clarity today&mdash;but to unlock even more powerful ways to track, collaborate, and refine how work gets delivered.
<img src="https://atono-test.directus.app/assets/81c3e77f-24ce-4f4b-b9a1-8e7e17ed75bf.jpg?width=2144&amp;height=1684" alt="Story PM Article">

Here's our take on it &mdash; and whether it still holds up today.

In Atono, prioritization isn&rsquo;t just a concept&mdash;it&rsquo;s something you can do directly in the backlog. Drag to reorder stories and bugs side by side, so your team always knows what to focus on next.
Atono <a href="https://docs.atono.io/docs/estimated-completion-dates#/" target="_blank" rel="noopener">estimates completion dates</a> for both bugs and stories based on your team&rsquo;s historical cycle time data. That means you can see how shifting priorities&mdash;like addressing a high-risk bug or pushing a key feature&mdash;might affect your delivery timeline. For bugs, a <a href="https://docs.atono.io/docs/bug-triage#triage-a-bug" target="_blank" rel="noopener">risk rating</a>&mdash;based on probability and impact entered by the triage team&mdash;helps you weigh urgent issues against product work. If a critical bug is at risk of missing its SLA, you&rsquo;ll know right away and can adjust accordingly.
You don&rsquo;t need to rely on spreadsheets or gut instinct&mdash;just sort, assess, and adjust as priorities shift.
<img src="https://atono-test.directus.app/assets/07609ebe-79f5-4ca1-b8cc-619b49d3cf70.jpg?width=2244&amp;height=818" alt="Estimated Completion Dates">
If your organization needs more structure, Atono offers two optional roles: <a href="https://docs.atono.io/docs/roles-and-permissions#product-manager" target="_blank" rel="noopener">Product Managers</a>, who control product theme creation and usage across the workspace, and <a href="https://docs.atono.io/docs/roles-and-permissions#backlog-owner" target="_blank" rel="noopener">Backlog Owners</a>, who manage prioritization within specific team backlogs. Assigning these roles helps reinforce ownership&mdash;without giving unnecessary permissions to everyone.

Once work is scoped and prioritized, Atono helps you plan when it should happen and why it matters.
<a href="https://docs.atono.io/docs/timeboxes#/" target="_blank" rel="noopener">Timeboxes</a> let you group work by delivery windows, while <a href="https://docs.atono.io/docs/product-themes#/" target="_blank" rel="noopener">product themes</a> help you track effort across strategic areas&mdash;like 'Onboarding' or 'Internal Tools'.
Because time and scope are managed separately, you can adjust priorities without missing delivery targets. Move stories between timeboxes while still seeing how much effort is tied to each product theme.
You can also filter the <a href="https://docs.atono.io/docs/everything#/" target="_blank" rel="noopener">Everything</a> page by product theme and see story sizes at a glance&mdash;helpful for reviewing scope mix across strategic areas.
<img src="https://atono-test.directus.app/assets/816d2080-5bd5-41c9-a334-4bac069ab347.jpg?width=2280&amp;height=940" alt="Everythiing Filter Product Theme">

<a href="https://docs.atono.io/docs/timelines#/" target="_blank" rel="noopener">Timelines</a> in Atono are built by arranging timeboxes&mdash;defined periods like 'Q3 Sprint 2' or 'July Release'&mdash;on a visual schedule. These timeboxes organize your delivery schedule, and can include stories and bugs as you plan and adjust work. When something about those items changes&mdash;like the title, team, or workflow step&mdash;the timeline reflects it automatically.
That means what you&rsquo;re sharing isn&rsquo;t a static snapshot. It&rsquo;s a living plan, grounded in the work itself.
You can create different views for different audiences&mdash;like zoomed-out timelines for leadership, detailed ones for teams, or shared versions for customer updates. Filter by product theme or team to highlight what matters to each group.
<img src="https://atono-test.directus.app/assets/9d1bdd34-05a5-41d5-b7e1-36be8bf5ef7e.jpg?width=2326&amp;height=1310" alt="Timeline">

Atono tracks how long stories and bugs spend in each workflow step. The <a href="https://docs.atono.io/docs/cycle-time#cycle-time-report" target="_blank" rel="noopener">Cycle time report</a> breaks this down by step&mdash;and for stories, also by size&mdash;so you can spot bottlenecks, assess sizing and velocity, and catch where work stalls.
<img src="https://atono-test.directus.app/assets/e4733c1e-77ef-4856-b2bb-5fdb7c295606.jpg?width=1962&amp;height=1208" alt="Cycle Time Report (1)">
To highlight quietly stuck items, Atono flags any story or bug taking longer than your team&rsquo;s average in a step with a red <a href="https://docs.atono.io/docs/staleness-indicator#/" target="_blank" rel="noopener">staleness indicator</a>.
<img src="https://atono-test.directus.app/assets/173e8f22-d4e2-4f2d-877c-3f8997986ff5.jpg?width=1744&amp;height=566" alt="Staleness Indicator (1)">
If something runs long for a valid reason, you can <a href="https://docs.atono.io/docs/cycle-time#outliers" target="_blank" rel="noopener">mark it as an outlier</a> to exclude it from reports, averages, and staleness detection&mdash;keeping your data accurate.
Looking ahead, <a href="https://docs.atono.io/docs/estimated-completion-dates" target="_blank" rel="noopener">estimated completion dates</a> give you a forecast for each item based on delivery history. These update automatically as work progresses&mdash;so you get planning visibility without custom charts or spreadsheets.

Once work is built and ready, Atono helps you control how and when it launches. <a href="https://docs.atono.io/docs/feature-flags#/" target="_blank" rel="noopener">Feature flags</a> in Atono are linked directly to the stories they control. You decide when features go live&mdash;right from the story view&mdash;without needing to loop in developers or ops.
This puts launch decisions in your hands. Coordinate rollouts with marketing, handle staged releases, or unblock a customer demo&mdash;all without slowing down the team.
Want to know why we built it this way? Check out <a href="https://atono.substack.com/p/the-case-for-including-feature-flags-in-stories" target="_blank" rel="noopener">The Case for Including Feature Flags in Stories</a>.
<img src="https://atono-test.directus.app/assets/0f041907-878c-4ff7-b08e-8658baaddee3.jpg?width=1698&amp;height=916" alt="Feature Flag in Story">

We&rsquo;re continuing to expand what Atono can do to support product managers&mdash;from planning and prioritization to launch and iteration. <a href="/demo">Book some time with our team</a> and we&rsquo;ll walk you through how Atono supports the full product lifecycle.

Solutions

Resources

Doug

CPO

Articles by Doug

Your AI is downstream. The fix is upstream.

Feature riffing: Using AI to refine product ideas before design

Introducing Atono's MCP Server: your AI can streamline your workflow

7 ways Atono helps product managers build better products