5:10 PM — The Moment Specs Usually Die
It’s the end of the day.
I have:
- three stakeholder conversations in my notes
- one internal escalation thread
- a vague request: “Can we improve shipment visibility during export documentation process?”
Two days from now, I need to walk into a product review with something concrete.
This is where most product work slows down:
- too much ambiguity
- too many interpretations
- not enough structure
And honestly — this is where PRDs go to die.
Not because PMs are bad.
But because turning messy real-world problems into executable systems is hard.
What Changed for Me
I stopped thinking of AI as a writing tool.
I started treating it as part of a system I built for myself:
A pipeline that goes from
raw input → structured thinking → decisions → specs → user stories → code-ready outputs
Not perfectly.
But consistently.
Step 1 — Raw Input → Structured Signals
Everything starts messy:
- customer complaints
- ops edge cases
- internal assumptions
I don’t clean it first.
I feed it in raw.
Cluster this into problem themes. Identify root problems, affected users, evidence, and contradictions.
This gives me structure — fast.
But here’s the important part:
I don’t trust it.
I challenge it:
- Is this actually the root problem?
- Are we overfitting to loud customers?
- What’s missing?
AI accelerates the thinking.
It does not replace it.
Step 2 — Decision Layer (Where Most PMs Skip)
Before writing anything, I expand the solution space:
Generate multiple solution directions with tradeoffs, risks, and assumptions.
Why this matters in logistics:
- one decision affects multiple systems
- compliance and operations can conflict with UX
- scalability is never free
This is where I behave less like a PM,
and more like a system designer.
Because I’m not choosing features.
I’m choosing how the system should behave under constraints.
Step 3 — PRD → System Blueprint (Not a Document)
Most PRDs describe features.
Mine describe systems.
Structure includes:
- problem (with real evidence)
- scope boundaries
- user roles (mapped to real-world actors)
- flows (not just screens)
- system logic (rules, data dependencies)
- edge cases (mandatory in shipping)
Prompt:
Generate a PRD focused on system logic, constraints, and execution. Avoid generic descriptions.
Then I rewrite.
Because AI doesn’t know:
- how booking systems interact with documentation
- how shipment visibility depends on multiple data sources
- how edge cases explode at scale
This is where domain expertise dominates.
Step 4 — Pre-Engineering Review (Before Engineers See It)
I simulate a review:
Act as a senior engineer. Identify ambiguity, missing logic, and implementation blockers.
This surfaces:
- missing data flows
- unclear ownership of logic
- undefined edge cases
It’s not real validation.
But it reduces friction later.
Which is what actually slows teams down.
Step 5 — Structured Decomposition (PRD → Execution Units)
Now I break it down:
- user stories
- acceptance criteria
- system logic per story
I enforce structure:
- UI elements
- UI behavior
- system logic
- constraints
AI generates the draft.
I refine:
- remove duplication
- fix sequencing
- map dependencies
Because execution fails when:
- stories are unclear
- dependencies are hidden
- logic is incomplete
Step 6 — This Is Where I’m Different: I Build the System
I don’t stop at documentation.
I start building.
Frontend
- Next.js-based prototypes
- component-driven UI (design-system thinking)
- flows that match real usage
Logic
- basic data structures
- rule-based logic (especially for compliance-heavy flows)
- simulation of real scenarios
Output
- working demos
- not just clickable mockups
AI helps me:
- scaffold UI
- generate components
- accelerate iteration
But I decide:
- structure
- logic
- flow
Step 7 — Connecting It Back to a System
Over time, I realized this is not just a workflow.
It’s a system:
- Framework → how I structure product thinking
- Skills → repeatable units (PRD generation, story decomposition, etc.)
- Execution layer → design tools, code, prototypes
This is how I move from:
- idea → structured thinking
- thinking → executable artifacts
- artifacts → something engineers can actually build on
Where This Still Breaks
Let’s not pretend this is perfect.
1. AI Doesn’t Understand Reality
It doesn’t know:
- regulatory constraints
- carrier-specific rules
- operational exceptions
Without context → wrong outputs.
2. It Doesn’t Own Tradeoffs
It cannot decide:
- speed vs scalability
- UX vs compliance
- short-term vs long-term
That’s still human judgment.
3. It Doesn’t Think in Systems Naturally
It defaults to:
- feature-level thinking
- isolated solutions
You have to force system thinking into it.
What This Actually Enables
Not “saving time”.
That’s the shallow benefit.
The real shift:
- I move from idea → structured system faster
- I reduce ambiguity before engineering starts
- I produce artifacts that are closer to implementation
- I can operate with less dependency on large teams
What I’m Pushing Toward Next
This is still evolving.
And honestly, this is where it gets interesting.
1. Production-Level MVPs
Not demos.
I’m working toward:
- apps engineers can directly extend
- clean structure, not throwaway code
- near-production quality
2. Design That Holds Up
Not wireframes.
I’m improving:
- pixel-level precision in Figma
- design system thinking
- UX flows that reflect real behavior
Because clarity in design reduces ambiguity in build.
3. Strategy-Level Thinking
Not just product intuition.
I’m building:
- structured market analysis
- trade lane and domain research
- decision frameworks similar to consulting firms
Because building fast is useless if you build the wrong thing.
Final Thought
AI didn’t turn me into a better PM.
It forced me to become a more complete one.
Because now, the gap is obvious:
- If you can’t structure problems → AI exposes it
- If you don’t understand systems → AI amplifies mistakes
- If you can’t make decisions → AI can’t save you
But if you can:
You’re no longer just a PM.
You’re someone who can design, structure, and ship systems end-to-end.
And that’s a very different role.