Skip to content
ONE3.ai

How it works · Flow F9

Customer feedback to shipped feature, with learning at the end

Feedback from support, surveys and chats is clustered into ideas, turned into PRDs, prioritised, planned into sprints, built, released behind flags and monitored.

What the Idea to release flow does

Idea to Release is the product and engineering flow.

Feedback from Service Desk, surveys and chats is clustered into ideas. An agent drafts a PRD. Ideas are prioritised with RICE. Epics and issues are created and a sprint planning agent proposes the sprint. Pull requests link to issues, CI runs, release notes are drafted, and features ship behind feature flags. Deployment is monitored. If an incident happens, it is handled and a post-mortem is written, and the learning goes into Knowledge.

Issues & Sprints and Product Management are W3 modules; DevHub, Ideas, Experimentation and Feature Flags are W4.

Every step on this page is an Action: a typed verb with a risk tier (R0 read-only to R4 irreversible or financial), a permission check and a reversibility class. Agents and humans call the same Actions, so the same approval rules apply whether a person clicks a button or a Digital Employee acts.

Idea to release, step by step

Thirteen steps from feedback to learning.

  1. 1

    1. Cluster feedback into ideas

    **Service Desk · Build · Survey · Office · Chats → Work · Ideas.** Feedback is clustered by theme.

  2. 2

    2. PRD draft

    **Product Manager agent (Engineering & Product).** Drafts a PRD for human review.

  3. 3

    3. Prioritise with RICE

    **Work · Product Management.** Reach, impact, confidence and effort scoring; humans decide.

  4. 4

    4. Epics and issues

    **Work · Issues & Sprints.** Work is broken down.

  5. 5

    5. Sprint planning

    **Sprint planning agent.** Proposes the sprint; the team accepts it.

  6. 6

    6. Linked PRs

    **IT & Security · DevHub.** Pull requests link to issues.

  7. 7

    7. CI

    **DevHub.** Tests and checks run.

  8. 8

    8. Release notes

    **Content agent.** Drafts release notes from merged work.

  9. 9

    9. Feature flags

    **Work · Feature Flags.** Features ship behind flags.

  10. 10

    10. Deployment

    **DevHub.** Release goes out.

  11. 11

    11. Monitoring

    **Platform · Observability.** Health and errors are watched.

  12. 12

    12. Incident and post-mortem

    **IT & Security · Service Desk.** Incidents are handled and a post-mortem written.

  13. 13

    13. Learning into Knowledge

    **Intelligence · Knowledge.** The post-mortem becomes reusable knowledge.

Wave

Issues & Sprints and Product Management are planned for W3; DevHub, Ideas, Experimentation and Feature Flags for W4.

Questions about this flow

Does an agent decide what to build?

No. Agents cluster feedback and draft PRDs and plans. Product owners decide priorities.

Can I link support tickets to issues?

Yes. Defects from Service Desk create linked issues and customers are told when the fix ships.

Are releases gated?

Features ship behind flags and are monitored; incidents feed post-mortems into Knowledge.

When is this flow planned?

Mostly W3–W4, in Years 2–3.

Can we keep using GitHub?

DevHub is planned to integrate with existing code hosts rather than replace them.

Build with us

Product teams who share how they plan and ship help us scope Work and DevHub.

Become a design partner