The PM Job Is Just Pattern Recognition (Until You Name It)
August 24, 2026 · 6 min read
I spent the first six months as a PO thinking I was behind. Read Survival Guide, built spreadsheets mapping every decision. But the job kept feeling like chaos with structure bolted on.
Then I realized: I was treating PM like eleven separate jobs instead of one system.
Steven Haines nails it: product management is running a small business inside a bigger business. Not "owning the roadmap." Running a business—which means knowing yourself, navigating the org, understanding markets, building strategy, executing, launching, measuring, and growing.
The book gives you the why. Here's the how—concrete practices from a year building CTicket (7 engineers, 50+ epics, 93k tickets).
Phase 1: Know Yourself → Self-Assessment, Twice a Year
Haines opens with acumen: six attributes every PM needs. Don't score yourself once. Retake it every six months.
PMs live between two axes: acumen (skills) and domain expertise (market knowledge). I came in strong on research and storytelling, weak on estimation under pressure. Knowing that told me where to build leverage—weekly feedback loops with my Tech Lead instead of pretending I had it figured out.
┌─────────────────────────────────────────────────────┐
│ Your PM Competency Map │
├─────────────────────────────────────────────────────┤
│ │
│ HIGH ACUMEN │
│ + WEAK DOMAIN + STRONG DOMAIN │
│ → Learning market → Growth mode │
│ ↑ │
│ │ │
│ [MY START] │ │
│ ● │ │
│ │ DOMAIN EXPERTISE → │
│ │ │
│ LOW ACUMEN │
│ + WEAK DOMAIN + STRONG DOMAIN │
│ → Onboarding → Level up fast │
│ │
└─────────────────────────────────────────────────────┘
The move: Calendar reminder, same template twice a year. Watch yourself level up.
Phase 2: Know the Organization → Map Influence, Not the Org Chart
Your manager isn't the highest influencer. Legal blocks features. Design is slow. Your CEO mentioned something in passing and now everyone chases it.
The org chart is reporting structure. The influence diagram is who actually decides.
At Cake, I ship cross-functional features through Legal, Ops, Tech, and two engineering teams. If I treat influence as a side effect, I lose six weeks to misalignment. If I name it upfront—"Here's who needs to agree and in what order"—decisions happen 3× faster.
OFFICIAL REAL
Org Chart Influence
Boss Design ─╲
│ ├─ YOU
YOU Eng ────╱
│
Peer Legal ··· (silent blocker)
Finance · (weak signal)
The move: Map it once, keep it visible, update quarterly. Stop fighting the org. Start dancing with it.
Phase 3-4: Know Your Customer → Research Pattern, Not Quotes
Most PMs fail here. Survey confirms the hypothesis. Support call: customer is frustrated. Dashboards: what happened, not why.
Rule: observation beats survey. Confirmation bias is your default.
I built a research template that blocks the traps. Interview before you hypothesize. Log patterns, not quotes. "One user wants gift cards" = noise. "Three separate users mention buying for group travel" = signal.
Capture: (1) problem they volunteered, (2) context, (3) their workaround, (4) downstream effects. That last part links a tiny friction to real impact.
NOISE SIGNAL
(One user) (Three users)
"I want gift cards" Pattern: Group travel
mentioned once
User A: "Buy for team trip"
❌ Don't build User B: "Tickets for friends"
User C: "Conference delegation"
Too specific, could be
anyone, random request ✓ Worth exploring
Real pattern, repeated unbidden
The move: Interview before spec. Three users with the same itch > one random request.
Phase 5: Strategy → Five-Question Loop, Run Quarterly
Strategy isn't January planning you forget. It's a cycle: Baseline → Vision → Goals → Path → Evidence. Measure. Learn. Cycle.
Run quarterly. When an assumption breaks (regulation, competitor, user behavior), revisit. Usually one input changes, you reweight. Sometimes nothing changes—you're on track.
One-page template: five questions answered + "When did we last review this?" Done.
WHERE ARE WE NOW?
↓
WHERE DO WE WANT TO BE?
↓
WHAT NUMBERS UNLOCK IT?
↓
HOW DO WE GET THERE?
↓
HOW DO WE KNOW WE WON?
The move: Next quarterly review, revisit the strategy with one question changed. That's the pattern.
Phase 6: PRD → No Prescriptions, Just Expectations
Most teams fail here. PRD says "poll backend every 5 seconds." Engineering hates it—handcuffed before thinking. If assumptions change, the spec is garbage.
Better: describe the problem and outcome. Let engineering solve it.
My write-spec template:
- Problem — What's broken? Who feels it?
- Goals — What future state unlock?
- Non-Goals — What are we NOT solving?
- Approach — PO expectations + open questions for Tech Lead
- UI/Flows — What does user see?
- Business Rules — Constraints, edge cases
- Scope — What ships when?
Example: Instead of "poll every 5 seconds," I wrote: "PO expectation: user has real-time confidence seats are still available before payment. Open question for Tech Lead: Given 80k tickets and hold logic, what latency is achievable? Caching? Event feed?"
First locks in bad decision. Second invites a better one.
The move: Stop prescribing. Start expecting. The PRD is a contract, not an instruction manual.
Phase 7-8: Execution → Humility Earns Credibility
You're not the builder. You're managing risk and trade-offs.
In sprint planning, don't hand down a backlog. Ask: "Here's what matters. Given capacity, what breaks? Where's risk?" Then listen. If engineering catches a hidden dependency, retro why the spec missed it. Take notes.
The move: Every trade-off call is a trust investment. Respect implementation details and you earn the credibility to make hard calls.
Phase 9: Post-Launch → Read Multiple Curves
Don't compare this quarter to last. Compare revenue + margin + cash flow + engagement from launch day against the business case.
Did adopters match the persona? Is the feature used as designed? Are secondary effects (support, failures, churn) moving as modeled?
Usually one assumption breaks. That's data, not failure.
The move: 90-minute post-launch review. Business case assumptions → what happened → which variable surprised us first → next bets. Quarterly per feature.
Phase 10: Career → Recursive Self-Assessment
Retake acumen self-assessment every six months. Update personal SWOT. Rewrite resume even if not job-hunting—forces honest accounting. Log accomplishments continuously.
Don't let career happen to you. Treat it like product strategy: Baseline → Vision → Goals → Path → Evidence. Cycle it.
I started six months ago. Changed how I think about myself. Not "Am I doing well?" but "Where am I vs. where I want to be?"
The move: Same assessment, twice a year. Career is a product too.
The System
Here's what connected: Haines gives the why. These practices give the how.
Stop treating PM as a role. Treat it as a small business—discipline, feedback loops, continuous learning. You'll still ship things wrong. You'll still miss signals. But you'll know exactly why, and you'll have the system to fix it next time.
Start with acumen. Know yourself. Everything else follows.