Collab Flow
From meeting room to sprint board
An AI-powered workflow that turns every enterprise meeting into summaries, tasks, specs, and Jira tickets — in under 30 minutes.
- AI Product Management
- Enterprise SaaS
- Microsoft Teams Integration
- Cortx
ROLE
Product Manager
Associate
Associate
PRODUCT
Cortx — AI Control Plane
for Enterprises
for Enterprises
Timeline
One Quarter
(13 Sprints)
(13 Sprints)
Tools
Enterprises in Production
0
Faster Product Development
0
%
Reduction in Dev Costs
0
%
THE PROBLEM
The gap no one had named yet
| What happened in the meeting | What made it to the backlog |
|---|---|
| Clear decisions were made | Nobody wrote them down consistently |
| Action items were assigned verbally | They lived in someone's head or a chat message |
| Requirements were discussed in detail | Engineers got them stripped of context and rationale |
| Sprint planning was on the calendar | It got delayed because the tickets didn't exist yet |
The gap between ‘we discussed it’ and ‘it’s in the backlog’ was where momentum went to die.
The journey from meeting end to engineer starting work took 5 to 10 working days on average nearly half a 2-week sprint, consumed before a single line of code was written. This wasn’t a people problem. It was a systems problem with five distinct failure points:
Manual transcription overhead
30–60 minutes after every meeting, manually transcribed into inconsistent, incomplete notes. Hundreds of hours lost per quarter.
Context lost in translation
By the time verbal discussion became a spec, the “why” behind every “what” had been filtered out. Engineers received requirements without rationale.
No single source of truth
Requirements in SharePoint. Notes in ADO. Action items in email. Alignment meetings scheduled just to align about alignment.
Ticket creation bottleneck
Sprint planning delayed not because teams didn’t know what to build — but because nobody had made the tickets yet.
The invisible handoff tax
Every transition from communication to execution required a human to carry information across systems — manually, imperfectly, at the cost of hours they didn’t have.
THE SOLUTION FLOW
Defining the end-to-end architecture
I defined every step of Collab Flow — from the moment a Teams meeting ends to tickets appearing in the backlog.
Microsoft Teams meeting ends
Teams API integration triggers automatically — no manual action required from the user.
Transcript pulled into Cortx in real time
Full meeting transcript flows directly into the Cortx platform via the Teams API integration.
Navi reads and processes the conversation
Cortx's native AI agent analyses the entire transcript — identifying intent, decisions, and action items.
Summary + action items generated
Crisp bullet-point summary and auto-assigned tasks based on meeting participants and context.
Human review & approval
User reviews, edits, and confirms all AI-generated output before anything is pushed downstream. The AI proposes — the human decides.
BRD + Technical Specification generated
From approved summary and action items — complete business requirement document and tech spec in minutes.
Sprint tickets pushed to Jira or Azure DevOps
Fully-formed sprint-level tickets created in whichever PM tool the enterprise uses — via a unified internal data model that translates to both.
⏱ Total time: under 30 minutes from meeting end to tickets in backlog
DISCOVERY & RESEARCH
Finding where time was actually being lost
I started with structured stakeholder conversations — not surveys, not assumptions — direct conversations with enterprise teams experiencing this pain. I mapped the journey from “meeting starts” to “engineer begins work” and timed each step.
“In a typical enterprise, the journey from meeting end to engineer starting work took 5–10 working days. For a team shipping 2-week sprints, that meant nearly half a sprint was consumed before a single line of code was written.”
— Key discovery finding
MY PROCESS
The BRD Template — A Multi-Stakeholder Alignment Challenge
One of the most underestimated parts of this project was defining what the AI-generated BRD should actually look like. It had to satisfy two fundamentally different audiences simultaneously.
I ran a structured review process — separate sessions with business and tech stakeholders — before locking the template. Getting this right before development started saved weeks of rework.
- Presented to business stakeholders first — iterated on context and objective sections
- Presented to tech leads — iterated on functional requirements and constraints
- Consolidated into a unified template with sign-off from both sides
- Locked as the source of truth before engineering built the generation logic
Briefing Design — The AI Handoff Moment
The hardest design brief I gave the team: how do you show the user that AI is working without making it feel like a black box?
I defined the review screen as the centrepiece — where users see, edit, and approve every AI output before it moves downstream.
- The AI working states — progress without overwhelming technical detail
- The review screen — every output visible and editable before push
- Error states — what happens when a transcript is incomplete or Navi’s confidence is low
- Design principle: the AI should feel like a capable colleague, not a black box
Engineering Coordination
Microsoft Teams API Integration
Defined transcript completeness thresholds, fallback states for failed or partial syncs, and real-time vs. delayed processing logic with engineering.
Navi’s Summarisation Accuracy
Tested across diverse real meeting scenarios (technical, unstructured, long-form) and iterated on prompts to achieve consistently reliable outputs.
Jira vs ADO — Unified Logic
Designed a unified internal data model, enabling a single AI output to seamlessly translate into both Jira and Azure DevOps formats.
Testing an AI-powered flow is fundamentally different from testing a deterministic system. I built a comprehensive edge case matrix across 6 categories before engineering started — so QA had a clear definition of expected behaviour for every scenario.
GTM & Documentation
• Wrote all help documentation — covering setup, the Teams integration, how to read Navi’s outputs, and how to edit before pushing to Jira/ADO
• Created the feature demo video — a Loom walkthrough showing the full flow end-to-end, used for client onboarding and sales
• Aligned GTM messaging around a single, clear value proposition: ‘What used to take your team weeks now takes 30 minutes’
STAKEHOLDER MAP
Who I worked with — and how
Collab Flow required alignment across 7 distinct stakeholder groups. Here’s how I worked with each.
| Stakeholder | Discovery | Definition | Design | Build | QA | Ship & GTM | |
|---|---|---|---|---|---|---|---|
| Internal | |||||||
| Manas (PM Associate) | You | R | R | R | R | R | R |
| Product owners & PM | Internal | A | A | I | I | I | A |
| Engineering team | Internal | I | C | C | R | C | I |
| Design team | Internal | I | C | R | I | I | I |
| QA team | Internal | I | C | I | C | R | I |
| GTM & content | Internal | I | I | I | I | I | R |
| External | |||||||
| Enterprise biz users | Client | C | C | C | I | I | C |
| Enterprise tech teams | Client | I | C | I | I | I | I |
R
Responsible — does the work
A
Accountable — final decision maker
C
Consulted — input required before action
I
Informed — kept in the loop
KEY DESIGN DECISIONS
The calls that shaped the product
01 — AI autonomy
How much should Navi decide on its own?
✓ What I chose
A mandatory human review step at every stage. The AI proposes, the human confirms. No output is pushed downstream without explicit user approval.
✗ What I didn't choose
Full AI autonomy — Navi processes and pushes everything automatically without a review step.
Why: Trust is a product feature. Enterprises don’t adopt AI tools that take control away from them. The review screen wasn’t a compromise — it was the product.
02 — PM tool integration
Two systems, one output logic
✓ What I chose
A unified internal data model — one language Navi outputs to, which translates to Jira or ADO depending on the enterprise.
✗ What I didn't choose
Two separate output systems — one for Jira, one for ADO — doubling engineering complexity and maintenance burden.
Why: The user should never have to think about which PM tool they’re on. The unified model also means adding a third tool later is a translation layer, not a rebuild.
03 — Confidence thresholds
When does the AI act, and when does it stop?
✓ What I chose
Three-tier framework: high confidence → AI proceeds. Medium → proposes and flags. Low → stops and hands control to user.
✗ What I didn't choose
A binary act/don’t-act system with no nuance for the vast middle ground of ambiguous scenarios.
Why: Ambiguity isn’t an edge case in AI products — it’s the default. The three-tier framework gave us a principled way to handle every scenario, not just the clean ones.
THE IMPACT
What changed?
90%
Faster product development
Tracked by enterprise clients across sprint velocity and time-to-ship after adoption.
65%
Reduction in development costs
Hours saved on documentation, spec writing, and ticket creation reported by enterprise teams.
The outcome I’m most proud of: we didn’t just save time. We eliminated an entire category of coordination overhead that no one had named the invisible tax between deciding and doing. Three enterprise teams are now shipping faster not because they work harder, but because the system works for them.
HOW I MEASURED SUCCESS
The signals that told, it was working
The impact numbers emerged after shipping — not from pre-defined targets. Here’s what we tracked and what they told us.
🟢
Time from meeting to in backlog
The core metric. If this number went down, the product was working. We tracked it across all 3 enterprise clients through their feedback and session data.
Before: 5–10 working days → After: under 30 minutes
🔵
Product development speed
Measured by enterprise clients tracking their own sprint velocity and time-to-ship after adopting Collab Flow across their teams.
90% faster product development reported across 3 enterprises
🟠
Development cost reduction
Reduction in hours spent on manual documentation, spec writing, and ticket creation — translated to cost savings by the enterprise clients themselves.
65% reduction in development costs reported by enterprise teams
Honest note on measurement: These numbers emerged from enterprise client feedback post-ship — not from pre-defined success metrics set upfront. In retrospect, a more structured measurement framework from day one would have given us cleaner data. That’s one thing I’d do differently.
PROJECT TIMELINE
One quarter. Discovery to ship.
Collab Flow went from first stakeholder conversation to production in one quarter across 4 phases.
DISCOVERY
Stakeholder interviews
Journey mapping
Problem definition
DEFINITION
Flow architecture
BRD template reviews
Design briefing
Edge case matrix
BUILD
Engineering coordination
Teams API integration
Navi prompt iteration
QA testing
SHIP & ITERATE
Enterprise rollout
GTM & docs
Feedback loop
v2 iterations
Week 1–2
Discovery & Problem Mapping
Stakeholder conversations with enterprise teams. Journey mapped from meeting end to engineer starting work. Pain points documented in SharePoint. FigJam current-state map completed.
Week 3–4
Flow Architecture & BRD Template Alignment
End-to-end Collab Flow architecture defined. BRD template review sessions run separately with business and tech stakeholders. Template locked and signed off by both sides.
Week 5–6
Design Briefing & Edge Case Matrix
Design team briefed on all flows, states, and edge cases. 22-row edge case matrix built with QA before engineering started. Confidence threshold framework defined with engineering.
Week 7–10
Build — Engineering Coordination
Teams API integration, Navi summarisation tuning, unified Jira/ADO data model built. Prompt iteration sessions run using real meeting transcripts. QA testing against edge case matrix.
Week 11–13
Ship, GTM & Documentation
Feature demo video created. Help documentation written. GTM messaging aligned. Enterprise rollout across 3 clients. Feedback loop established for AI output quality.
CHALLENGES & HOW I NAVIGATED THEM
How do you get enterprises to trust AI-generated specs?
The biggest adoption barrier wasn’t technical — it was psychological. I didn’t ask them to trust the AI blindly. Instead I designed a mandatory human review step where every output is visible and editable before anything is pushed downstream. The framing that unlocked adoption: “The AI is your first draft, not your final decision.”
How do you align business and tech teams on what "good output" looks like?
They had completely different definitions. I ran separate review sessions with each group — treating their feedback as distinct inputs rather than trying to satisfy everyone in one room. I found the union: the sections both agreed were essential became non-negotiable. Everything else became optional configuration.
When does the AI act, and when does it stop and ask the human?
Getting this wrong in either direction breaks the experience. I defined a three-tier confidence framework with engineering: high confidence → AI proceeds autonomously. Medium → AI proposes, user confirms. Low → AI flags, user takes over. This wasn’t just a UX decision — it was a product philosophy about where human judgement is irreplaceable.
How do you test an AI system where "correct" is sometimes subjective?
I built the edge case matrix before engineering started — so QA had a clear definition of expected behaviour for every scenario. I also established a structured feedback loop: a way for enterprise users to flag outputs they felt were wrong, which fed back into prompt iteration.
LEARNINGS
What I'd carry forward
01
The most important PM work happens before the product is defined.
Getting business and tech stakeholders to agree on what “good” looks like — before a line of code is written — was the hardest and most valuable thing I did on this project.
02
Trust is a product feature.
The mandatory review screen wasn’t a compromise forced by stakeholder anxiety. It was the right product decision.
03
In AI products, edge cases are the default
Building the matrix before dev started changed the quality of everything downstream. Define expected behaviour upfront or you’ll define it under pressure.
04
Define success metrics before you ship.
The numbers came from post-launch feedback — not a framework I set upfront. Cleaner data, tighter feedback loop, stronger story. I’d do this differently.