systems notebook[ product operations ]

september 2026 · workspace design

building a product operations workspace:
reliable specs & prototypes with ai workflows.

one prompt in. a reviewed brd, flowchart and prototype out, with human review and quality checks at every step.

krishna · product manager

[ ai note ] this deck was written by ai and might be wrong. check anything important and double check it with the blog owner before you rely on it.

(01)the thesis[ product operations ]

generic prompts write buzzwords. structure writes specs.

asking a generic ai chatbot to write product requirements usually produces vague summaries full of buzzwords, missing api details and unclear scope. the workspace turns one prompt into a brd, system flowchart and interactive prototype through structured clarification, human review and automated quality checks.

brd preparation per initiative ≈ 1 week → ≤ 1 day with clarification, review and checks kept in the loop.
(02)the problem[ product operations ]

why simple prompts fail in real product work.

at a large retail e-commerce platform, a complete brd, flowchart and testable prototype took about a week per initiative by hand.

01 / the input

raw stakeholder input is fragmented.

a quick chat message, rough meeting notes, or an unprioritized wishlist with contradictory goals.

02 / the draft

chatbots produce superficial summaries.

feed that brief to a chatbot and you get a generic document full of consultant filler.

03 / the handoff

engineers still lack actionable details.

the schema, the timeout behavior and the billing edge cases are still unanswered.

(03)the symptom[ product operations ]

it reads fine. it answers nothing.

brd: generic chatbot draftillustrative

  1. vision: an intuitive, scalable, ai-driven experience.

    ✕ consultant filler. nothing to build.

  2. api: integrates seamlessly with services.

    ✕ what is the exact json request and response schema?

  3. reliability: robust error handling.

    ✕ what happens when a transaction times out after 3,000 ms?

  4. billing: supports vouchers and points.

    ✕ how are discount vouchers stacked with loyalty points reconciled?

sample lines written for this slide. the red notes are the questions engineers asked.

(04)two approaches[ product operations ]

quick ideas vs. structured workflows with clear rules.

✕ generic chatbot promptsunstructured drafting

  1. unclear request
  2. generic ai prompt
  3. vague 10-page document
  4. engineering rejection
  5. weeks of clarification

✓ structured workspacesingle prompt, human review

  1. raw brief
  2. intake screening & scope audit
  3. api contract modeling
  4. brd, flowchart & prototype
  5. human review & checks
  6. approved in ≤ 1 day
(05)the architecture[ product operations ]

clarify, generate, verify, then hand to a human.

product operating system user action diagramsystems architecture
product operations workspace serpentine state machine diagram blueprint two-row serpentine state machine: row one moves left-to-right from raw brief submission through the intake gatekeeper and screener (with a screening flag loop back to clarify and resolve audit) to the strict scope manifest; the flow drops down on the right into row two and moves right-to-left through the soft api contract generator and typed contract schemas into the docx packaging engine, compiled brd draft, and verification decision diamond before exiting to the approved specification. 1. submit raw brief slack or meeting notes intake gate intake gatekeeper screen pii & moscow scope 2. clarify & resolve edge cases & timeouts scope manifest p0 vs out-of-scope typed schemas api contract generator json & db state specs provisional spec compiled brd draft docx packaging engine passes audit? schema · logic · pii approved specification ready for eng & uat handoff [screening flag] [remediation loop] [pass] lines flow dependency verified outcome failure or risk path shapes start / end input action decision control gate data source document
(06)four tiers[ product operations ]

four tiers between a brief and an approved spec.

01

boundary audit & intake gatekeeper

  • screenpii and private credentials redacted at intake.
  • scopemoscow: must, should, and won't-have.
  • probecan a voucher exceed cart value? stack with tier points?
02

specs, flowcharts & prototypes

  • brdjourneys, edge cases, soft api contracts, state machines.
  • flowcharttransitions, retry loops, integration points.
  • prototyperesponsive html/css on real viewports.
03

acceptance governance & uat packaging

  • bactest matrices and staging uat sign-off documents.
  • docsmarkdown compiled to styled word files, synced to shared drives.
04

multi-stage verification & sanitization

  • contractsbusiness logic cross-checked against api models.
  • leaksevery document checked for personal data and credentials.
  • loopfailures quarantined and returned to the operator.
(07)the stack[ product operations ]

ordinary tools, strict wiring.

  • agentic orchestrationgoogle antigravity (agy) sdk and a custom multi-agent skill system in .agents/skills/.
  • specification layermarkdown-as-code versioned in git: pull request reviews, diffs and audit trails for product specs.
  • document generationpython python-docx engine with xml style injection.
  • sanitization & lintingcustom python regex analyzers that verify privacy compliance.
  • interactive prototypingresponsive html, css and svg mobile prototypes for pre-sprint alignment.
the takeaway[ product operations ]

constrain before you generate.

don't use ai as a chatbot for generic prose. give it strict scope, enforce edge-case audits, embed domain standards in the tools, and verify every output against engineering constraints.

← notes
[ speaker notes ]