Technical Product Manager Interview Preparation Guide - Lyft (Junior Level)

Direct answer

Before sketching anything, I separate three questions: who is this for and what must it do (functional scope), what quality bar does it have to hit (non-functional requirements like scale, latency, and compliance), and what am I explicitly choosing to leave out for this iteration. I get there by asking a short list of targeted questions, writing down the assumptions I have to make when answers aren't available yet, and drawing an explicit line between what ships now and what's deferred, instead of letting scope grow implicitly as the conversation continues.

Structured elaboration

A repeatable order of operations

1. Clarify the primary user and the one core job the service must do for them.
2. Ask about scale and growth (expected load today, expected growth rate, read-versus-write ratio), because these numbers, not taste, determine how much architecture is actually warranted.
3. Ask about non-negotiable constraints: compliance obligations, systems it must integrate with, budget, deadline.
4. Ask what's allowed to degrade: is a few seconds of staleness acceptable, is brief downtime during a deploy acceptable, does every read need to be exact.
5. State assumptions explicitly wherever a real answer isn't available yet, and mark them as assumptions to validate, not facts to build on silently.
6. Draw the scope line: list primary use cases that must ship, and secondary or deferred use cases that are explicitly out of scope for this iteration, written down so nobody discovers the gap later.

The judgment underneath the checklist
A senior candidate treats every "yes, and also" as a scope decision with a cost, not a free addition, and pushes back on a vague ask like "make it fast" by translating it into a testable target before designing a single component, which is the same move a strong answer makes when a client says a product must "feel fast" for users worldwide.

Worked example

Take the one-line prompt "design a URL shortener." Before sketching components, I'd ask: how many new links are created per day, and what's the read (redirect) to write (creation) ratio? Suppose the answer is 10,000 new links/day with a 100:1 read-to-write ratio, typical of a link-sharing product:

$\text{redirects/day} = 10{,}000 \times 100 = 1{,}000{,}000$

$\text{avg redirect RPS (requests per second)} = \frac{1{,}000{,}000}{86{,}400} \approx 11.6 \text{ req/s}$

That single clarifying question, the read-to-write ratio, turned a vague prompt into a concrete, low-single-digit-RPS system, which tells me this is a read-heavy, cache-friendly problem, not a write-scaling problem, before a single box has been drawn. If the interviewer instead says the product is a bulk-import tool with a roughly 1:1 read-to-write ratio, the answer to nearly every later design question changes, which is the point: the clarifying question, not the diagram, is where the real design decision happens.

Scope line for this example: in scope for a first version is create-and-redirect with a randomly generated short code. Explicitly out of scope for the first version, stated to the interviewer rather than silently dropped, are custom vanity aliases, click analytics, and link expiration, each a real feature with its own cost that can be added once the core path is validated.

Trade-offs & pitfalls

• Designing before scoping: sketching a box diagram before knowing the read-to-write ratio, scale, or constraints wastes limited interview time on a shape that may not fit the real problem.
• Silently assuming numbers instead of stating them, so a listener can't tell you're reasoning from an assumption rather than a fact.
• Treating scope-cutting as a failure rather than a design decision; a strong candidate narrates what they are choosing not to build and why, instead of trying to design everything at once.
• Requirements-gathering theater: asking a long, generic checklist of questions instead of the two or three that would actually change the design.

Clarifying questions for a useful first phase

• What business outcome must the first phase deliver (e.g., revenue, reduce churn, enable partners)?
• Which platforms are highest priority for users or revenue?
• Who are primary users and their critical workflows for launch?
• What is the minimum end-to-end path that proves value (API + UI + data)?
• What SLAs, compliance, and security constraints must the MVP meet?
• What existing systems can be reused vs. need integration work?
• What metrics will determine phase success and go/no-go?

Assumptions to document for later phases

• Target platforms priority (e.g., web first, then mobile, then partner APIs)
• Reuse of existing auth/data models and estimated integration effort
• Team capacity and dependency timelines (shared infra, SDKs)
• Non-functional requirements deferred (scale, multi-region, advanced observability)
• Timeline and budget envelopes for each subsequent phase

Communication plan across releases

• Weekly engineering sync + biweekly stakeholder demos of increments
• Quarterly roadmap review with decision points and contingency plans
• Shared living doc (roadmap + assumptions + risks) with versioning
• Success metric dashboard updated after each release
• Escalation path and change-control process for scope/priority shifts

This approach aligns technical constraints with business value, limits risk, and keeps stakeholders continuously informed.

Direct answer

I require a short, focused pre-read before the meeting (the problem, the options, the data behind them, not a pitch for one answer), invite the people who'll actually operate or approve the outcome rather than everyone remotely interested, and when two attendees disagree I redirect the conversation from stated positions to the underlying constraints each of them is protecting, then settle it against evidence rather than whoever argues longer.

Pre-reads I require

A two-page document, sent enough in advance that people arrive having actually read it: the problem and current metrics, the options actually being considered (not one option dressed up as several), rough cost and risk for each, and any prototype or benchmark data available. I explicitly ask people to bring disagreement in writing beforehand if they have it, so the meeting starts from known positions instead of surfacing them live for the first time, which burns the room's limited time on restating context instead of resolving disagreement.

Who I invite

The engineers who will build and the ones who will operate the result, since design-time convenience and runtime cost are often in tension and both need a voice. A reliability-focused reviewer if the change affects availability or incident risk. A security reviewer if the change touches data access or the trust boundary, since security is easy to leave out of an architecture conversation and expensive to add back in later. A product stakeholder if the change affects what's shippable or when. If a technical program manager is involved, they typically own getting the pre-read circulated and the room booked with the right people, not the technical recommendation itself, and keeping that distinction clear avoids the meeting drifting into project-status territory. I keep the list to the people who need to decide or will be materially affected, not everyone who might find it interesting; a design review that tries to include everyone stops being a decision-making meeting.

Handling genuine disagreement in the room

When two people show up with real, substantive disagreement rather than a misunderstanding, I don't try to referee it as a personality conflict. I ask each to state the specific constraint they're protecting in concrete terms (a latency floor, an operational complexity ceiling, a data-consistency guarantee) rather than their preferred solution, because two people arguing for different solutions are often actually protecting the same underlying concern and don't realize it. Then I score the options against those stated constraints using whatever data is on the table, prototype numbers if we have them, rather than letting the debate resolve on seniority or persistence. If the data genuinely doesn't settle it, I say so explicitly and either scope a short follow-up spike to get the missing data or make the call myself as the meeting owner and document why, rather than letting the meeting end without a decision.

Worked example

A notification service was missing its latency target under peak load, and I ran the design review to replace a single-worker batch processor with something that would scale. The pre-read covered current metrics, three real options (a streaming platform with partitioned consumers, a sharded worker pool, a managed publish-subscribe service), and prototype latency numbers I'd gathered beforehand. I invited backend engineers, an SRE, a product manager, and a security reviewer given the service touched user contact data. The SRE favored the managed option for lower operational burden; backend engineers favored the streaming platform for control over partitioning and failure isolation. I asked each to state the constraint they were protecting: the SRE's was on-call load, backend's was avoiding a hard ceiling on horizontal scaling. The prototype data showed the streaming option met the throughput target with acceptable, quantified operational overhead, which resolved it on evidence rather than preference. We agreed the meeting owner (me) would write up the decision and the operational commitments needed to satisfy the SRE's concern, closing the loop instead of leaving it as an unresolved parallel objection.

This same shape scales down and up: a narrower change, like an internal billing application programming interface, might only need a focused hour with the engineers, quality assurance, and one product stakeholder; a platform-wide move needs the fuller group and probably more than one session.

Trade-offs and pitfalls

• Skipping the pre-read and using the meeting itself to build shared context. That turns a decision meeting into a status meeting and wastes the room's actual purpose.
• Inviting too many people "to be safe." A design review with fifteen attendees rarely reaches a decision; it reaches a list of concerns.
• Treating disagreement as something to smooth over instead of resolve. Letting two people leave with different unstated assumptions about what was decided just moves the conflict to implementation time, where it's more expensive.
• Ending the meeting without an owner for follow-up. A design review that produces a direction but no named owner for the write-up and next steps tends to lose momentum within days.

Direct answer
Choosing between a first-party SDK and better documentation is really a question of where developers are actually getting stuck, and that's answerable with real usage data rather than a general preference for one investment over the other.

Structured elaboration

1. Data to gather before deciding: current time-to-first-successful-call and where in that funnel developers drop off (if most drop-off happens at initial authentication or environment setup, a better quickstart doc addresses it more directly than an SDK would); support ticket categories and their volume (are the most common tickets about "how do I call this endpoint" style questions that an SDK's ergonomics would eliminate, or about conceptual confusion that better docs and examples would resolve); and qualitative feedback from a sample of recent integrators about what specifically slowed them down.
2. Success metrics for each option: for an SDK, adoption rate among new integrations and time-to-first-successful-call specifically for SDK users versus raw-HTTP users; for documentation and code samples, documentation search success rate and a reduction in the specific ticket categories the improvement targeted.
3. Decision framework: an SDK pays off most when the API itself has meaningful complexity that a well-designed client library can hide (authentication token refresh, pagination, retries with backoff), where the SDK removes real repeated work every integrator would otherwise redo themselves; documentation improvements pay off most when the API is conceptually simple but poorly explained, where the actual barrier is understanding, not implementation friction.
4. Recommendation under constrained bandwidth: if the data shows drop-off concentrated at understanding "what to call and why," prioritize documentation and code samples first, since that's a smaller, faster investment with a clear reason to expect a specific fix; if the drop-off is concentrated at implementation friction that persists even among developers who clearly understood the docs (evidenced by a gap between "read the quickstart" and "successfully called the API"), prioritize the SDK first, since documentation alone won't fix an ergonomics problem.

Worked example
If support ticket analysis shows the top category is "how do I handle token refresh without my requests failing intermittently," that's an implementation-friction problem best solved by an SDK handling refresh transparently, not a documentation gap, since the concept is likely already explained; if instead the top category is "what does this specific field mean and when do I need it," that's a documentation and example gap an SDK wouldn't fix, since the SDK would still expose the same confusing field.

Trade-offs and pitfalls
The most common mistake is defaulting to "build an SDK" because it feels like the more substantial, prestigious investment, without first confirming the data actually points to implementation friction rather than conceptual confusion, which wastes the larger of the two investments on the wrong problem. The second common mistake is trying to do both simultaneously under genuinely constrained bandwidth, which often means neither is done well enough to move the metrics meaningfully; sequencing based on the stronger signal, then doing the second investment once bandwidth allows, usually beats splitting effort thin across both.

Direct answer

Do not referee the argument on either side's terms. Get the product manager and the sales leader to agree on the criteria a good decision should satisfy, such as impact, risk, cost, and strategic fit, before evaluating the two initiatives against them, make the actual trade-off explicit and visible to both, and if they still cannot converge, fall back to a pre-agreed neutral path, such as a specific owner or forum, rather than letting whoever argues harder win by default.

Structured elaboration

Separate positions from underlying interests

"We should build my initiative" is a position. The interest underneath it, such as protecting a committed relationship, capturing a strategic capability, or hitting a revenue target, is what actually needs to be satisfied, and there is sometimes more than one way to satisfy it.

Agree on decision criteria before ranking anything

If the criteria are picked after looking at the options, whoever's initiative fits best gets to claim the criteria were obviously the right ones. Agreeing on what matters, and roughly how much, before scoring anything removes that bias.

Make the trade-off explicit, not implied

State plainly what saying yes to one costs the other: displaced timeline, deferred capability, real opportunity cost. Vague trade-offs, such as trying to do both eventually, just relocate the disagreement to a later date.

Have a pre-agreed fallback for genuine ties

Sometimes both initiatives are legitimately close in value. Decide in advance who breaks the tie, such as a shared manager or a specific forum, and under what timeline, so a genuine tie does not become an open-ended standoff.

Worked example

A product manager wants to build a feature that improves activation for the broad user base. A sales leader wants a different feature that would help close several deals already in the pipeline. Both have real reasoning behind their case, but the reasoning is not answering the same question, so comparing the two head-on produces a false comparison, not a decision.

The facilitator, an engineering manager in this scenario, brings both together and gets agreement on criteria first: how many users or how much revenue does each option affect, how reversible is each choice if it turns out to be wrong, and how well does each align with the stated strategy for the quarter. Evaluated against the same criteria, it becomes clear the two initiatives are not actually mutually exclusive at full scope: a smaller version of the sales-driven feature can ship inside the existing capacity without displacing the activation work, while the full-scope version is deferred to the next quarter with an explicit commitment. Both leaders leave with a decision they can each explain to their own stakeholders, because they agreed on the criteria before either one saw how the evaluation would land.

Trade-offs and pitfalls

Forcing an artificial "both, just smaller" compromise when the initiatives are genuinely incompatible produces two half-built things instead of one well-built thing. The compromise only works when the criteria step reveals real headroom, not as a default peacekeeping move.

Over-structuring a call that both sides would have agreed on anyway wastes time and can read as bureaucratic theater. And skipping the criteria-first step under time pressure, going straight to picking one, reintroduces exactly the dynamic, whoever argues harder wins, that a structured process exists to avoid.

Direct answer

Yes, it changes, but not in what's true, in the framing and the sequencing. With a peer you can lead with the problem and work toward a decision together. With your manager, you're asking someone who has more authority over your role and resources to change course, so you lead with the stake (what's actually at risk), keep your own emotion out of the opening, and give them a real way to agree with you without it landing as a demand.

Structured elaboration

The move is to adjust for the power difference without softening the actual disagreement: frame it as a shared problem, not a complaint.

• With a peer: you can open with the observation itself ("I'm seeing X, here's the impact, can we figure out why") because the relationship absorbs directness well and there's no asymmetry to manage around.
• With a manager: open with the impact or stake, not the process, because they're weighing this against priorities you don't fully see, and a vague opening reads as noise. State your actual position plainly rather than just "I have some concerns," since managers are used to people softening bad news into invisibility. Bring at least one proposed path forward, not just the problem, since an unprepared complaint upward hands them the thinking you should have already started. Choose the setting deliberately (a 1:1, not a group meeting) so neither of you has to manage an audience while disagreeing.
• Timing and documentation differ too. A peer disagreement can often just get resolved and forgotten. A disagreement with your manager is worth a short written recap afterward (what was discussed, what was decided), because "who agreed to what" carries more weight when there's a reporting relationship attached to it.
• What doesn't change: the facts, your right to disagree, and the expectation that you'll say the true thing. The skill is packaging a real disagreement so it lands as useful input rather than a challenge to their authority, without pretending you don't actually disagree.

Worked example

Peer: a teammate keeps assigning your team last-minute work that blows up the sprint plan. You say directly, in the moment: "This is the third same-day ask this sprint that's bumped planned work, can we figure out a lead time we can both live with?" No manager involved, no escalation, it's between the two of you.

Manager: your manager wants a feature shipped in two weeks that you believe needs four, and cutting corners risks repeating a data-loss incident from a few months back. Instead of saying "I don't think that's realistic" in the stand-up, you ask for 15 minutes, open with the stake ("if we ship on the current scope in two weeks, I think we reintroduce the failure mode from the earlier incident, here's why"), bring two real options (cut scope to hit the date, or keep scope and slip two weeks), and end by asking which trade-off they want to make, since that's ultimately their call to weigh against things you don't see. You send a two-line recap afterward: what was decided, and why.

Trade-offs and pitfalls

• Silence is the common wrong turn: assuming "it's their call" means you shouldn't voice the disagreement at all. A manager who never hears real pushback from you can't factor it in, and you lose credibility if the thing you predicted happens and you said nothing.
• Overcorrecting the other way, treating your manager exactly like a peer, can read as tone-deaf if the org genuinely has stakes you don't see. It isn't about deference, it's about giving them what they need to make a call that's actually theirs.
• Escalating past your manager without giving them a first chance to respond burns trust fast. Save it for issues that stay blocked, unaddressed, or carry legal, safety, or compliance stakes, not for routing around a single "no" you didn't like.
• A written follow-up can read as building a paper trail against the person if the tone turns defensive instead of collaborative.

Objective (30 days)
Rapidly capture high-risk tacit knowledge from departing senior engineers so team can sustain roadmaps, on-call, and platform goals.

Prioritization (by ROI / risk)

• Highest ROI / Highest risk: Recorded architecture walkthroughs + golden-path runbooks (captures design intent, failure modes)
• High ROI / Medium risk: Pairing sessions on critical features and current sprint work
• Medium ROI / Low risk: Shadowing on-call and design reviews
• Low ROI: Broad Q&A town halls (useful but lower fidelity)

30-day timeline & owners
Week 1 (Owner: TPM + departing Eng): kickoff, identify top 8 knowledge items, schedule recordings/pairs.
Week 2 (Owner: departing Eng): 3 recorded architecture walkthroughs (30–60 min each); produce golden-path runbook drafts for 3 critical flows.
Week 3 (Owner: Eng leads): 10 pairing sessions (2–4 hours) covering current tickets and deployment steps; shadow 2 on-call incidents.
Week 4 (Owner: TPM + Docs owner): finalize runbooks, index recordings, handover meeting with engineering leads + SRE; sign-off checklist.

Owners & Roles

• Departing Senior Eng: record walkthroughs, lead pairing, review runbooks
• TPM: prioritize items, schedule, ensure business-critical context captured
• Engineering Leads/SRE: accept handover, validate runbooks, own gaps post-departure
• Docs owner/Tech writer: edit and publish artifacts

Handover checklist (must capture)

• Architecture diagrams + decisions and trade-offs
• Golden-path runbooks: deploy, rollback, common fixes, monitoring queries
• Current sprint context, key tickets, and unfinished design notes
• On-call playbooks and escalation contacts
• Relevant credentials, repo pointers, CI/CD steps, feature flags
• Known technical debt and mitigation suggestions

Focus on artifacts that reduce cognitive load (checklists, scripts) and ensure a 2-week post-departure shadow window for follow-ups.

Situation & framing
As a TPM evaluating developer-facing strategy, weigh engineering cost, time-to-market, performance, feature parity, support burden, and adoption velocity against business goals (reach, revenue, retention).

Trade-offs

• Engineering cost & time-to-market
  • REST API: lower initial engineering cost; one surface to build and maintain → faster launch.
  • Multi-language SDKs: high upfront and ongoing cost (implementations, CI, release coordination).
• Feature parity & consistency
  • REST: single canonical contract reduces drift.
  • SDKs: risk of lagging features unless automated generation and test matrix exist.
• Performance & ergonomics
  • REST: network-bound, more boilerplate for clients.
  • Native SDKs: can optimize retries, batching, streaming, and idiomatic UX → higher developer delight.
• Support burden & operational complexity
  • REST: simpler support surface but requires strong docs, examples, client patterns.
  • SDKs: more user-facing touchpoints, increased bug triage across languages.
• Adoption velocity
  • REST + strong docs + quickstart: broad reach quickly.
  • SDKs in key languages (JS, Python, Java): accelerate adoption in target segments.

Recommendation (TPM decision framework)

• Start with a well-designed REST API, OpenAPI spec, and excellent docs + quickstarts.
• Auto-generate SDKs from spec for low-effort languages; prioritize hand-crafted SDKs for 2–3 strategic ecosystems based on usage/ICP.
• Measure adoption, NPS, and friction; expand SDK investments when ROI (reduced integration time, support tickets, conversion) justifies cost.

Example metrics

• Time-to-first-success, integration time, support tickets per integration, retention uplift after SDK release.

Direct answer

The content doesn't change across audiences, it's the same system either way, what changes is which layer of consequence you lead with: business outcome for an executive, product and user impact for a product manager, and operational mechanics for a junior engineer. Below is the same web frontend, API gateway, microservices, database, and cache, presented three ways, plus what stays flexible if you had two or four audiences instead of three.

Deciding what changes per audience

• Ask "what does this person need to be able to DO after this conversation" for each audience, approve a budget, plan a feature, operate and debug the system, and let that answer set both the top points and the detail level, rather than applying a fixed template.
• Keep every audience's version factually consistent. That's the real skill being tested: three explanations of the same architecture must never contradict each other even though they emphasize different things, because these audiences do talk to each other afterward.
• Detail level isn't a dial from less to more, it's a different SET of details. An executive gets less of everything except cost and risk; a junior engineer gets less business framing and far more failure-mode and operational detail.
• The same three-tier split generalizes to other pairings: explaining latency versus throughput to a product manager and a CFO in the same meeting, choosing a different detail level for a C-level executive versus an eng-lead versus someone from procurement, choosing different terminology for a DBA versus a frontend engineer, presenting a model's result to executives versus a PM versus an ML engineer, describing a model's architecture to executives on one call and backend engineers on the next, or setting a different tone for an outage update with engineering peers than with product. The technique scales to 2, 3, or 4 audiences by repeating the same "what do they need to do with this" question for each one.

Worked example

Executive. Top points: what the system lets the business do (serve customers reliably at scale), the cost profile, and the biggest risk if something fails. Detail level: no component names beyond "our systems," outcomes stated in business terms only. Opening line: "This is how our product stays fast and available for customers, and where the main cost and risk sit."

Product manager. Top points: how a user's action flows through the system (a click hits the frontend, which asks a gateway, which asks the right service, which reads from cache or the database), where a feature change would need coordination across services, and what the cache means for how fresh data looks to users. Detail level: names the pieces and their roles, not their internals. Opening line: "Here's what actually happens between a user clicking a button and seeing a result, and where feature changes get expensive."

Junior engineer. Top points: each component's responsibility, the request path with protocols, what the cache invalidation policy is and what breaks if it's wrong, and where to look first when something fails. Detail level: full, including specific technologies and failure modes. Opening line: "Here's the request path end to end, and here's what you check first when something in it breaks."

Trade-offs and pitfalls

The biggest risk isn't detail level, it's drift: giving the product manager a slightly different causal story than the one given to engineering creates a credibility problem the moment they compare notes. Write down the one or two facts that must stay identical across all versions before tailoring anything else. The second pitfall is treating "executive" as a synonym for "shallow." An executive audience still needs the real trade-off, what the caching layer saves and what it risks, just stated in business units instead of technical ones, not a story with the substance removed.

Direct answer

With a fixed budget and a single top-line target, the right approach is not to guess a percentage split by intuition but to convert every lever (paid acquisition, supply-side incentives, trust and safety, pricing, tooling) into the same unit, the cost of one incremental booking, then fund the cheapest ones first until either the budget or the 5% target is hit. The pitch to a skeptical executive is not "here is my allocation," it is "here is the marginal cost curve for each lever, and here is where we stopped funding and why."

Structured elaboration

Convert every lever to one comparable unit

Different levers produce bookings through different mechanisms (a new customer, a saved existing customer, a faster or safer experience that reduces drop-off, a pricing change that shifts conversion), so the only fair comparison is dollars spent per incremental booking produced, holding everything else constant.

Rank by marginal, not average, return on investment (ROI)

The first dollar into a channel is rarely as productive as the last dollar already spent there. A channel that looks efficient on average spend can be a poor next-dollar bet if it is close to saturating its addressable audience; a channel that looks expensive on average can still be the best next dollar if its marginal cost per booking is still low. Ask what the next dollar buys, not what has already been bought.

Sequence for time-to-signal, not just cost

Cheap-per-booking levers with a long signal delay (large tooling investments, structural trust improvements) are hard to defend against fast levers (acquisition, pricing tests) that show results in weeks, even if the slow lever is ultimately more cost-effective. A credible plan funds a small amount into slow, high-uncertainty levers early (to start the clock on their signal) while putting the bulk of near-term budget into fast levers that can be proven or killed within the fiscal year.

Respect dependency, not just independence

Levers are not independent bets: pouring budget into acquisition without enough supply capacity (drivers, hosts, inventory, support staff) does not produce bookings, it produces failed matches and refunds. Trust and safety investment is often the one sponsors underweight because it has no clean bookings-per-dollar number. Its real return shows up as avoided churn and avoided platform-wide trust damage, which should be modeled as a downside-protection line, not zeroed out for lack of a clean upside number.

Defend the allocation with a stopping rule, not a story

The defensible version of "why did money go here and not there" is: money was ranked by cost per incremental booking under stated assumptions, funded from cheapest up, and stopped at the point where the next dollar's expected cost exceeded a set threshold or the budget ran out.

Worked example

Assume a baseline of 2,000,000 bookings a year (pinned assumption) and a target of +5%, meaning +100,000 incremental bookings needed. Assume a total budget of $10,000,000 (pinned).

Estimate cost per incremental booking for two levers using stated, illustrative assumptions.

Acquisition: customer acquisition cost (CAC), the average cost to acquire one new paying customer through marketing spend, is assumed at $50, and each newly acquired customer is assumed to make 1.2 bookings in the measurement window.

$\text{Cost per incremental booking (acquisition)} = \frac{CAC}{\text{bookings per acquired customer}} = \frac{50}{1.2} \approx \$41.67$

Supply incentives: assume $10,000 spent onboarding new supply capacity in a specific undersupplied zone, and that this capacity removes a matching bottleneck that was capping 25,000 bookings a year in that zone.

$\text{Cost per incremental booking (supply)} = \frac{10{,}000}{25{,}000} = \$0.40$

Under these stated assumptions the supply lever is far cheaper per booking than the acquisition lever, but its addressable ceiling is smaller (it only unlocks the bookings that were being blocked by that specific bottleneck, roughly 25,000 here), while acquisition can in principle keep scaling until the market is saturated. The defensible allocation funds the supply fix first (bounded, cheap, but capped), then fills the remaining gap to 100,000 with acquisition spend at roughly $41.67 per incremental booking:

$75{,}000 \times \$41.67 \approx \$3{,}125{,}000$

That leaves the rest of the $10,000,000 for pricing tests, trust and safety, and tooling, funded in that order based on their own marginal cost-per-booking estimates once measured.

Trade-offs and pitfalls

• A single blended CAC or blended ROI number hides diminishing returns; presenting one allocation "because it worked last quarter" invites the skeptical exec's best question: what is the marginal cost of the next dollar, not the average cost of the dollars already spent.
• Trust and safety and tooling investments are the easiest to under-fund because they don't produce a clean bookings-per-dollar number on their own; a defensible plan states their return as risk avoided (fraud losses, cancellations, incident-driven churn) rather than dropping them from the ranking entirely.
• Over-funding acquisition without checking supply capacity is a common wrong turn: it produces demand the marketplace cannot fulfill, which shows up as cancellations and refunds, not bookings.
• A plan with no stopping rule and no pre-committed kill criteria is not a defense, it's an opinion; the credible version names the threshold at which a lever would have been defunded.