Decision→Ticket
A decision had to be rewritten as work.
PMs reread scope documents, split the work, and rewrote the same context.
INTERNAL PRODUCT · 2026
Flowgen
I designed the space between tasks.
PRODUCT DEFINITIONFlowgen turns scope into reviewable ticket candidates, then connects assignment, execution, PM review, and completion through visible states and Slack handoffs.
14teammates
17weeks
8sprints
869tickets
01Plan
02Ticket
03Owner
04Build
05Review
06QA
07Ship
Each state starts the next action.
01Context
Every tool worked. The workflow didn’t.
Notion held decisions, the task board held execution, and Slack held communication. The invisible work of translating, handing off, and checking still depended on people.
01Scope decided↓
02Rewrite action items↓
03Create tickets↓
04Tell each owner↓
05Check progress↓
06Request review↓
07Reconfirm revisions↓
08Close or carry over
02Observation · Reframing
The invisible work lived between states.
Each task looked small. Repeated across every sprint, the translation, delivery, and confirmation between tasks became the team's coordination cost.
Ticket→Owner
Assignment did not explain the context.
A created ticket still needed a separate Slack message before work could start.
Build→Review
Completion did not start the review.
Someone had to notice the change and ask the next person to act.
Review→Revision
Feedback was split across two places.
The team repeatedly checked which feedback was still open.
Sprint→Next sprint
Carry-over work lost its reason.
The next sprint inherited the task, but not always the decision behind it.
BEFOREHow can we create tickets faster?
↓REFRAMEDHow might each decision become a visible next action?
03Design Strategy
Every output becomes the next input.
The goal was not to automate the most tasks. It was to keep work moving without removing judgment from the people responsible for it.
Continuity over automation
Optimize the handoff, not the feature count.
Human judgment at critical moments
Scope, priority, ownership, and approval stay human.
Visibility without asking
Show the owner, current state, and next action.
Turn context into candidates
- Read scope documents
- Break work into units
- Draft titles and descriptions
- Generate ticket candidates
Keep responsibility with people
- Confirm scope and priority
- Edit or remove candidates
- Assign the owner
- Approve publishing and completion
04Core Experience
From scope to action—without losing control.
Two experiences carry the product: turning scope into reviewable work, and turning each state change into the next person's action.
From scope to executable work
AI prepares the candidates. A PM edits, removes, assigns, and publishes only what the team should actually execute.
VERIFIED WORKFLOW MODELNot a product screenshot
A decision already made by the team
→Work units, titles, and descriptions
→Remove duplicates, set priority and owner
→Only approved tickets are published
62
ticket candidates from one scope document
26.5 minfrom document to reviewable candidates—not total planning time
From status changes to shared accountability
The state model makes the owner and next action explicit. Slack carries only the transitions the team needs to act on.
STATE → OWNER → NEXT ACTIONProduction behavior
- Owner
- Owner
- Trigger
- Slack DM + channel
- Owner
- Assignee
- Trigger
- Start becomes visible
- Owner
- PM
- Trigger
- Review notification
- Owner
- Assignee
- Trigger
- Return with context
- Owner
- Team
- Trigger
- Close and retain history
10:10A weekday digest surfaces work in progress and items waiting for review.≈65 digests observed
05Product Decisions
Automation should not remove control.
I chose three constraints that made the workflow trustworthy: review before publishing, Slack as the delivery layer, and PM Check as a visible state.
Review before publishing
- Evidence
- A wrong ticket would become part of the whole team's execution plan.
- Alternatives
- Publish every AI output immediately, or let a PM review candidates first.
- Decision
- Separate generation from publication and require human approval.
- Trade-off
- The workflow kept one review step instead of maximizing speed.
- Changed experience
- AI removed blank-page work without taking ownership of scope.
Bring the workflow to Slack
- Evidence
- The team already coordinated daily work in Slack.
- Alternatives
- Build a new Flowgen inbox, or deliver only actionable state changes to Slack.
- Decision
- Send assignment, PM Check, comments, and bug events to the existing workspace.
- Trade-off
- Slack stays part of the experience, so notification rules must remain selective.
- Changed experience
- The team did not have to keep Flowgen open to notice the next action.
Make PM Check a visible state
- Evidence
- Review began only after someone remembered to ask for it.
- Alternatives
- Use periodic reminders, or make review an explicit transition with an owner.
- Decision
- Add PM Check between work and completion, with revision returning to active work.
- Trade-off
- One more status adds structure, but it also makes review latency measurable.
- Changed experience
- Review became a shared queue instead of a private follow-up.
06Failure · Recovery
Faster automation can create faster failures.
A false failure response in Sprint 33 exposed what the first workflow could not show: whether automation had already changed the real board.
One request looked like one result
The interface could not verify whether a failed response had already created tickets.
A retry created ten duplicate pairs
The API returned 500, while the first request had already been processed.
Generation and publishing became two steps
Candidates are compared with existing tickets and reviewed before they reach the sprint.
Automation without observability creates faster failures.
07Evidence of Use
A working system, not a concept.
The strongest evidence is continued use. The secondary metrics describe workflow quality and current operating baselines—not causal improvement.
tickets with AI involvement
261 of 869 tickets
remained after review
106 of 109 Claude-batch tickets · edits were allowed before generation
assignment → start, median
Post-adoption baseline · n=103
PM Check → done, median
Post-adoption baseline · n=46
SPRINT 35 SNAPSHOT170 / 203 · 83.7%Completed among tickets counted as completed or carried over. This is one sprint's result, not a causal Flowgen lift.
08Truth · Measurement
Measure what the data can actually defend.
Pre-adoption data was not preserved with the same definitions. So I separated adoption evidence, post-adoption baselines, and the measurement needed next.
- Used by 14 teammates for 17 weeks
- 869 tickets managed across 8 sprints
- 261 tickets involved AI-assisted generation
- Current handoff and review baselines measured
- Productivity improvement percentage
- Reduced handoff time versus the old workflow
- Flowgen caused the 83.7% sprint result
- Percentage of manual communication removed
Measure where coordination stalls—not only whether a ticket closes.
Sprint closing snapshotsBlocked-state durationNotification aggregationAssignment event separationReview timestamps by stateTeam-reported coordination time
Source: Flowgen production database and activity logs. Because equivalent pre-adoption Jira and Notion data was not preserved, these are adoption and post-adoption operating observations—not a controlled before/after study.
09Reflection
The next action mattered more than the automated task.
I started with ticket generation. Operating the product showed me that the larger opportunity was designing how decisions move between people.
The best automation didn’t replace a person.
It helped the right person know what to do next.What this experience opened next
Next project · 01 / 04OshizRelationship retention · Japan LiveOps · 2026From shipping work to sustaining relationships
Flowgen makes team dependencies visible. Oshiz applies the same systems thinking to a consumer challenge: making memory, world, and relationship continuity visible to users.