Technical Product Management

Build vs. Buy Framework Core Method

Use when: the team is debating whether to build custom infrastructure or adopt an existing solution.

Evaluate along five dimensions:

• Differentiation — does building this create competitive advantage? If authentication isn't your product's differentiator, don't build an auth system.
• Total cost — compare the full cost of building (engineering time × loaded cost × opportunity cost) against buying (license fees + integration time + vendor management + migration risk).
• Control — does building give you control over something critical?
• Time — how fast do you need a solution? Building takes months; buying takes weeks.
• Maintenance — building means you own maintenance forever; buying means vendor dependency.

The default should be "buy" unless building creates meaningful differentiation. Most teams over-build because engineers enjoy building and under-weight the ongoing maintenance burden.

Build vs. Buy Scoring Matrix Tool

Use when: you need to present the decision to stakeholders in a structured way.

Score each option on a 1-5 scale across: differentiation potential, time to value, total 3-year cost, integration complexity, team capability match, and vendor risk. Weight criteria based on context (startup weights time-to-value; enterprise weights vendor risk). Present the weighted score alongside a qualitative narrative — the matrix structures the conversation, but the narrative captures nuance the numbers miss.

Tech Debt Quantification Core Method

Use when: engineering says "we need to pay down tech debt" but can't quantify the business impact.

Categorize debt by its effect:

• Velocity debt — slows feature development ("adding a new payment method takes 3 weeks instead of 3 days").
• Reliability debt — causes outages ("2 incidents per month from the legacy auth system").
• Scalability debt — limits growth ("we handle 10K concurrent users but break at 50K").
• Security debt — creates vulnerabilities ("deprecated encryption library").

For each category, quantify: velocity debt = extra days per feature × features per quarter × engineering cost per day. Reliability debt = incidents per month × average cost per incident. This transforms "we need to refactor" from an engineering wish into a business case with dollar amounts.

20% Time Allocation Framework

Use when: tech debt keeps growing because it loses every prioritization battle against features.

Reserve 15-20% of engineering capacity for tech debt and infrastructure. This capacity is non-negotiable — it doesn't compete with features. Engineering leads decide how to spend it, with TPM input on business impact. The benefit: debt gets addressed continuously instead of accumulating until it forces an emergency. Track what the 20% produces: reduced incident rate, faster feature delivery time, improved test coverage. If you can't show impact, the allocation will get questioned.

Architecture Decision Record (ADR) Core Method

Use when: the team makes a significant technical decision that future team members need to understand.

An ADR documents: the decision context (what problem we're solving), the decision itself (what we chose), alternatives considered (what we rejected and why), consequences (what trade-offs we accepted), and status (proposed, accepted, deprecated, superseded). The PM's role isn't writing ADRs — it's ensuring they get written, reviewed, and stored where people can find them. ADRs are the technical equivalent of product decision logs: without them, new team members re-litigate settled decisions.

Keep ADRs short (1-2 pages). Store them in the codebase alongside the code they describe, not in a wiki nobody checks. Number them sequentially. Never delete an ADR — mark deprecated ones as such with a pointer to the superseding ADR.

Dependency Risk Matrix Technique

Use when: evaluating the risk profile of your technical dependencies.

List every critical external dependency (databases, third-party APIs, libraries, cloud services). For each, assess: Substitutability (how hard is it to switch?), Vendor health (is the company/project stable?), Usage depth (surface-level or deeply embedded?), and Failure impact (what happens if it goes down?). Dependencies that score high on all four dimensions are existential risks that need mitigation plans: abstraction layers, fallback strategies, or contractual SLAs.

Migration Planning Template Core Method

Use when: moving from one system to another (database migration, platform rewrite, vendor switch).

Every migration plan needs:

• Scope — what's migrating and what stays.
• Dual-write period — how long both systems run in parallel.
• Rollback plan — how you revert if migration fails.
• Data validation — how you prove the new system produces identical results.
• Customer communication — what users need to know and when.
• Success criteria — how you know the migration is complete.

The biggest migration risk is the "big bang" approach: flip a switch and hope everything works. Instead, migrate incrementally: start with read traffic (shadow the new system against the old), then migrate write traffic for low-risk operations, then high-risk operations, then cut over remaining traffic. Each phase has its own rollback plan.

Engineering Partnership Model Framework

Use when: you want to build trust and effective working relationships with engineering leads.

The TPM-engineering relationship has three modes:

• Collaborate — decisions where PM and engineering have equal input (what to build, how to sequence work).
• Advise — engineering decisions where PM provides business context but engineering decides (architecture choices, technology selection, code quality standards).
• Inform — PM decisions where engineering needs to know the outcome but doesn't need to weigh in (pricing strategy, market positioning). Explicitly agree on which mode applies to which decisions. Most PM-engineering conflict comes from mode mismatch: PM trying to collaborate on architecture, or engineering trying to collaborate on product strategy.