Execution & The Technical PM

A spec is not a contract for engineering to silently implement. It is a structured argument that captures the user problem, the desired outcome, the bounded scope, the explicit non-goals, the key decisions, the open risks, and the launch measurement. The argument is the deliverable — engineering should be able to read the spec and disagree with the trade-offs intelligently. If the spec only contains the *what*, you've written a JIRA ticket.

• Page 1 anatomy: problem, user, current alternative, success metric, scope, non-goals.
• Page 2 anatomy: key flows, decisions made, decisions deferred, open risks.
• Page 3 anatomy: launch plan, measurement, rollback plan, sequencing dependencies.
• Anything past page 3 belongs in design files or eng RFCs, not the PRD.

A one-page PRD forces clarity. Use it for any item under 4 weeks of total effort. Use a longer doc only for cross-team initiatives, regulated work, or 'big bet' programs. Most teams over-produce documentation; the volume of words written has near-zero correlation with execution quality.

• Problem: who is suffering, how do we know, how often.
• Outcome: the metric movement we are buying.
• Constraints: budget, deadline, dependencies.
• Open questions: name them so they're addressed, not avoided.
• Sign-off: who said yes (DACI Approver), when, on what version.

There is no neutral roadmap format. Each one biases the team toward different conversations. Date-based Gantt biases toward commitments. Now/Next/Later biases toward sequencing. Theme-based biases toward strategic alignment. Outcome-based biases toward metric movement. Pick the format that creates the conversation you most need to have, and re-evaluate annually.

• Gantt: best for fixed-deadline regulated programs; worst for discovery-led products.
• Now / Next / Later: best for product-led growth; weak signal for finance and sales.
• Theme-based: best for portfolio thinking; risks losing tactical detail.
• Outcome-based: best when leadership trusts the team to choose the path; needs a strong NSM.
• Mix: many teams use Outcome themes externally, Now/Next/Later internally, dates only for hard deadlines.

Method choice is undertheorized. Scrum is tuned for predictable feature work in mature systems. Kanban is tuned for support-style flow. Shape Up is tuned for shaping bets in stable teams that trust each other. SAFe is tuned for big regulated organizations that need cross-team coordination. None of them is automatically right; each one's pathologies are well-documented.

• Scrum's risks: estimation theater, ceremony fatigue, sprint goal as wallpaper.
• Kanban's risks: WIP explosion, no clear prioritization horizon.
• Shape Up's risks: trust dependency, cycle-end debt, less visibility into in-cycle progress.
• SAFe's risks: meeting overhead crushing speed; ceremony as substitute for product judgment.
• Test the method against your team's actual pathology, not against blog-post enthusiasm.

APIs (Application Programming Interfaces) define how systems request data or actions from each other. Even non-technical PMs need a working model: REST, GraphQL, RPC, GraphQL subscriptions, and webhooks. The vocabulary differences shape what's easy and what's hard. PMs who understand the API surface make better trade-offs about what to expose, when to introduce versioning, and how to plan for partner integrations.

• REST: resource-oriented (GET /users/123). Most public APIs.
• GraphQL: client-defined queries; flexible, harder to cache, complex on the backend.
• RPC / gRPC: action-oriented (e.g. CreateInvoice); strong types; usually internal.
• Webhooks: server-to-server callbacks; the right tool for 'tell me when something happens'.
• Idempotency: an operation that can be safely retried without side effects — non-negotiable for billing and integrations.

Database choices shape what's cheap and what's expensive forever. Relational DBs (Postgres, MySQL) are cheap for joins, expensive for unbounded scale. Document stores (Mongo, Firestore) are cheap for flexible shapes, expensive for relational queries. Key-value stores (Redis) are cheap for cache and session, expensive for analytics. The PM who can read a basic ER diagram and ask 'is this query bounded?' will save the team six months across two years.

• Schema migrations are forever — each migration is a small Type-1 decision.
• Reads vs writes: scale them separately.
• Indexing: the most common cause of 'sudden' performance issues.
• Soft deletes vs hard deletes: regulatory and analytics implications.
• When in doubt: ask 'how does this query scale at 100x current data?'

When systems talk to systems, the network is unreliable. Queues (RabbitMQ, SQS, Kafka) absorb load spikes; retries handle transient failures; idempotency keys prevent double-charges and duplicate sends. PMs who promise 'instant' or 'real-time' user experiences without understanding queue lag will commit the team to architectures that can't be delivered. Always ask: is this synchronous or queued?

• Synchronous: user waits, system responds in <1s; only works for short, deterministic operations.
• Asynchronous: user gets confirmation, work happens in background; required for anything touching external systems.
• At-least-once vs exactly-once delivery: drives idempotency requirements.
• Dead-letter queues: where messages go to die; should be monitored, not ignored.

Median latency lies. The user experience is dominated by the tail — p95, p99, and p99.9 latencies. A site that responds in 200ms median but 4s at p99 will feel broken to 1% of users — and that 1% will be the loudest. PMs who care about UX care about the tail.

• Median (p50): half the users see less; tells you almost nothing about user experience.
• p95: 5% of requests are slower; the boundary of 'acceptable'.
• p99: 1% of requests; in B2B with hundreds of users per account, this hits every account every day.
• p99.9: 1 in 1000; matters for high-volume products and APIs.

A feature flag is a runtime switch that lets you ship code to production without exposing it to users. Combined with cohort targeting, it enables progressive delivery: ship to 1%, then 5%, then 25%, then 100%, watching metrics at each stage. Treat every meaningful change as a flag-gated rollout. The cost is minor; the optionality is enormous.

• Always ship behind a flag for any user-visible change.
• Always have a kill switch — the ability to revert without redeploying.
• Always set a flag-cleanup schedule; old flags become invisible technical debt.
• Pair flags with a metric watch — automated rollback on regression.

The launch is not 'when engineering merges'. It includes comms, sales enablement, support readiness, telemetry, success criteria, and rollback. Most launch incidents are not engineering failures — they are checklist failures. The launch checklist is one of the highest-leverage artifacts a PM owns.

• Pre-launch: telemetry verified, success criteria documented, rollback plan tested, comms drafted, support trained, sales enablement ready, beta cohort feedback incorporated.
• Launch: phased rollout with metrics gate, on-call rotation aware, status page ready.
• Post-launch (T+24h, T+7d, T+30d): metric review, qualitative feedback synthesis, retro on launch process.
• Don't launch on Fridays or before holidays unless you want a chaotic weekend.

Replace status meetings with a one-page weekly note. It compresses signals into a format stakeholders can read in 90 seconds, surfaces risks early, and creates a public record of what was promised vs delivered. Done well, it eliminates 80% of synchronous status conversations.

• Top: NSM and headline metrics this week.
• Middle: in-flight bets, status, confidence, blockers.
• Bottom: decisions needed this week (named approver, deadline).
• Tone: concrete and bounded. No marketing language. No emoji storms.
• Distribute on a fixed cadence (Friday 4pm). Predictability builds trust.

PMs spend more time in disagreement than agreement. The skill isn't to avoid conflict — it's to surface conflict early, structure it productively, and resolve it with a named decider. Most product 'culture problems' are decision-rights problems wearing a costume.

• Surface disagreement in writing before the meeting; reduces emotional escalation.
• Use steel-manning: state the opposing view stronger than the opponent before disagreeing.
• Escalate by writing, not by ambushing in meetings; named approver decides.
• After the decision, disagree-and-commit; relitigation is corrosive.

The trust between PM and engineering is the single most undervalued asset in product. Trusted PMs get scope flexibility, technical advocacy, and faster delivery. Untrusted PMs get protective estimates, scope rigidity, and mysterious delays. Trust is built through the boring habits: showing up to standups occasionally, knowing the codebase well enough to read PRs, advocating for tech debt with stakeholders, and never, ever, blaming engineering in public.

• Spend a half-day shadowing on-call rotation each quarter.
• Read the post-mortems of incidents you weren't involved in.
• Publicly advocate for tech-debt and reliability investments — don't make eng do it alone.
• When something slips, own it externally. The engineering team will reciprocate internally.