Technical Product Management Questions

Direct answer
The CAP theorem states that a distributed system experiencing a network partition must choose between staying available (continuing to serve, possibly stale, reads and writes) or staying fully consistent (only serving guaranteed-correct data, at the cost of some requests failing during the partition), and this abstract trade-off shapes very concrete, visible product decisions.

Structured elaboration
In plain terms: when parts of a distributed system can't communicate with each other (a network partition, however brief), the system has to decide what to do. It can keep answering every request (availability), accepting that some answers might be based on slightly outdated information (a stale read, or in rare cases a write that later needs to be reconciled), or it can refuse to answer requests it can't guarantee are fully correct and current (consistency), accepting that some users will see an error or a wait instead.

Two concrete product decisions shaped by this trade-off:

1. An inventory count on a product page during a flash sale: choosing availability means the displayed stock count might occasionally be slightly stale, risking a rare oversell that needs to be handled gracefully after the fact (a cancellation and apology, or automatic backorder); choosing consistency means the page might occasionally show an error or delay rather than risk showing wrong stock, which protects against overselling but can frustrate users during exactly the high-traffic moment the business cares most about converting.
2. A social media "like" count or view count: choosing availability here is almost always the right call, since a slightly stale count (off by a small amount momentarily) has essentially no real cost to the user or business, and refusing to show the count during a partition (choosing consistency) would be a poor trade for a feature this low-stakes.

Worked example: for a banking balance check, the product decision correctly favors consistency: a customer seeing an incorrect account balance (even briefly, due to a stale read) can lead to a customer overdrawing based on wrong information, a real financial harm that vastly outweighs the inconvenience of an occasional "unable to retrieve balance right now, please retry" message during a rare partition event.

Trade-offs and pitfalls
The most common mistake is treating this as a purely technical decision made once for the whole system, when in practice different FEATURES within the same product legitimately warrant different choices (a banking app might correctly choose consistency for balance display and availability for a customer-support chat history view). The second common mistake is assuming network partitions are rare enough not to matter in practice; they happen more often than intuition suggests, even if briefly, which is why this isn't a hypothetical concern but a design decision every distributed system's features actually face.

Direct answer
A traceability matrix exists to make sure every technical requirement can be traced back to a real business reason, and every business objective has concrete, owned work behind it, so nothing gets built without a purpose and nothing important gets silently dropped.

Structured elaboration
The matrix works because each row forces the same discipline: a business objective that can't be mapped to a measurable technical requirement is too vague to build against, and a technical requirement with no objective behind it is a candidate for removal.

Worked example
For the "enable ad-hoc queries" row, the acceptance criterion is deliberately specific (90% success rate, one-month measurement window) rather than "analysts can query the data," because the vague version can't distinguish a genuinely successful rollout from one where analysts are still routing most requests through engineering, which is the actual failure mode this objective exists to prevent.

Trade-offs and pitfalls
The most common failure is building the matrix once at project kickoff and never revisiting it, so it becomes a stale artifact that doesn't reflect what was actually built by the time of a later incident or audit. The second common failure is making the metric column vague ("improved query performance") instead of a specific, measured number with a defined measurement window, which makes the row impossible to verify as done or not done.

Direct answer
A technical roadmap is the sequenced plan for building and evolving a developer-facing product or platform over time, distinct from a release plan in that it communicates DIRECTION and MAJOR BETS across quarters and years, not a list of what ships next sprint.

Structured elaboration
Common planning horizons and what belongs in each:

• Next quarter (0-3 months): concrete epics with defined scope, largely de-risked, close to a release plan in specificity.
• 6-18 months: platform initiatives and capability milestones stated as outcomes ("support multi-region deployment") rather than implementation detail, since specifics here will likely change.
• Multi-year: directional bets (a major architecture shift, a new platform capability class) stated as themes, not committed dates, because certainty this far out is honest to claim.

The roadmap differs from a tactical release plan in three ways: it operates at the level of capabilities and outcomes rather than tickets; it's meant to communicate WHY a sequence was chosen (dependencies, risk reduction, business alignment) rather than just WHAT is next; and it's built to be revisited on a regular cadence rather than executed against without question.

When to update it: on a fixed cadence (commonly quarterly for the near-term horizon), and additionally whenever a triggering event invalidates a major assumption underneath it, such as a significant scope discovery from a spike, a shift in business priority, or a platform dependency slipping. Updating "whenever something changes" without a floor cadence leads to a roadmap nobody trusts because it's constantly in flux; updating only on the fixed cadence without allowing for trigger-based updates leads to a roadmap that's visibly wrong for weeks before anyone corrects it.

Worked example
A platform team's roadmap might show, at the next-quarter horizon, "ship read replicas for the reporting API" as a scoped epic with a target date; at the 6-18 month horizon, "support multi-region write availability" as a capability milestone without a committed date; and at the multi-year horizon, "evolve toward an event-driven architecture for the core service" as a directional theme. As the next-quarter epic completes and reveals the multi-region work is more tractable than expected, the 6-18 month horizon gets pulled forward at the next quarterly update.

Trade-offs and pitfalls
The most common mistake is treating the whole roadmap with release-plan precision, committing hard dates 18 months out that inevitably slip and erode trust in the roadmap as a communication tool. The opposite mistake is keeping everything so vague that engineers can't actually plan their next quarter around it. The right calibration is precision that decreases the further out the horizon goes.

Direct answer
A rate-limiting policy for an API with both free and paid tiers needs to protect the platform from abuse and overload while making the free tier genuinely useful and the paid tier's higher limits a real, felt benefit, not just a number on a pricing page.

Structured elaboration

• Algorithm choice: a token bucket (allowing short bursts up to a cap while enforcing a steady average rate) fits most API use cases better than a strict leaky bucket (which smooths output to a constant rate), because real client usage is naturally bursty (a batch of requests fired at once) and token bucket accommodates that without penalizing normal usage patterns.
• Granularity: enforce limits per API key as the primary unit (ties directly to the customer's plan), with an additional, more generous per-IP limit as a secondary defense against a compromised or leaked key being used at abusive scale from a single source, and per-endpoint limits for especially expensive operations (a bulk-export endpoint should have a tighter limit than a simple lookup, regardless of the caller's overall plan).
• Burst handling: allow a bucket capacity meaningfully above the steady-state rate (e.g., a burst allowance of a few multiples of the per-second average) so a legitimate batch operation doesn't get throttled after its first few requests, while still bounding the maximum burst to protect backend capacity.
• Enforcement and fallback behaviors: return a clear, standard 429 status with a Retry-After header indicating exactly when the client can safely retry, rather than a generic error, so well-behaved client libraries can back off automatically instead of retrying immediately and compounding the problem.
• Client communication strategy: expose current rate-limit status via response headers on every request (remaining quota, reset time), not just at the moment of being throttled, so developers can build their own client-side backoff logic proactively rather than discovering limits only by hitting them.
• Metrics for fairness and business impact: rate of 429 responses by tier (a healthy free tier should see some throttling, since its purpose partly includes nudging genuine high-volume users toward the paid tier; a near-zero free-tier throttle rate suggests limits are set too generously to differentiate the paid tier's value), and conversion rate from free to paid tier correlated with proximity to the free-tier limit, which tells you whether the limit is actually functioning as an upgrade incentive or just as an invisible ceiling nobody notices.

Worked example
If free-tier customers who repeatedly hit their rate limit convert to the paid tier at a meaningfully higher rate than those who never approach it, that's a concrete signal the rate limit is doing its intended job as both a protection mechanism and a monetization lever; if throttled customers instead show high churn without converting, that suggests the free-tier limit may be set low enough to frustrate rather than convert, and it should be revisited.

Trade-offs and pitfalls
The most common mistake is setting rate limits based purely on backend capacity protection without considering their effect on the free-to-paid conversion funnel, missing an opportunity (or actively causing harm) at the intersection of a technical control and a business lever. The second common mistake is enforcing limits with an opaque error and no proactive quota visibility, which pushes developers toward naive retry loops that make the very overload problem the rate limit exists to prevent worse, not better.

Direct answer
A prescriptive requirement locks in a specific implementation the engineer might have good reasons to change; the fix is separating the actual constraint (a real safety, performance, or compliance need) from the implementation detail that was really just a guess at how to satisfy it.

Structured elaboration
The rewrite process:

1. Ask why the specific technology was named. Usually it's because the requirement author had a mental model of the solution and wrote it down as if it were the requirement, when the real requirement is the outcome that mental model was trying to achieve.
2. State the outcome the choice was meant to guarantee. If a specific database was named because of a durability need, the real requirement is the durability guarantee, not that database.
3. Preserve genuinely essential constraints as explicit constraints, not as an implementation choice. If there's a real reason a specific technology is required (an existing integration, a compliance certification only that vendor has), state that reason explicitly as a constraint rather than leaving it implicit in a prescriptive line.

Worked example
Original prescriptive text: "Store transaction records in PostgreSQL with synchronous replication to a secondary in the same region, using a Kafka topic for downstream event distribution."

Rewritten, outcome-focused: "Transaction records must survive a single-node failure with zero data loss (durability requirement), be queryable with strong consistency for the primary write path, and be available as a stream of events to downstream consumers within 5 seconds of the write (event distribution requirement)." This preserves the real safety requirement (zero data loss on node failure) and the real performance requirement (5-second event propagation) while giving engineering the freedom to choose the specific database and messaging technology, potentially discovering a better-fitting option than the one originally assumed.

Trade-offs and pitfalls
The main risk in over-correcting toward "never name a technology" is that some prescriptive constraints ARE genuinely essential (an existing system only integrates with a specific technology, or a compliance requirement is certified against a specific vendor), and stripping those out in the name of flexibility creates rework when engineering picks an incompatible alternative. The discipline is not "never name a technology," but "never name a technology without stating the real reason, so engineering can tell whether the constraint is negotiable."