Lesson 51 — Understanding the business

Stack: Soft skills · Project: TicketFlow Status: Published — closing the soft-skills module Prerequisite: Lesson 50 — Code review

Objectives

1. Explain TicketFlow's business model: who pays, for which value, and which metric every technical decision moves.
2. Translate between business and tech in both directions: the requirement → the real problem, and the technical limitation → the product decision.
3. Prioritize with the business: the value/effort/risk that decides the backlog and the technical "no" that protects the business from itself.

1. TicketFlow's business model (the map the tech serves)

TicketFlow does not sell "a reservations API": it sells the SALE of tickets. The money map: organizers pay a commission per sale (08's ledger — that is why it is append-only: it is the INVOICING); buyers pay for tickets (32's gateway); the inventory (10's seats) is the ASSET that corrupts if the tech fails (a seat sold twice = refund + reputation + lost commission). Every technical piece of the course serves ONE line of the model:

The map's test: if you don't know which business line your piece protects, the piece is suspect of over-engineering (43: K8s without trigger) — or it is common infrastructure that deserves to be boring. Both answers are legitimate; the UNCONSCIOUS one is not.

2. Translating: the requirement and the real problem

Translation direction 1: the requirement ("we want push notifications") → the real problem (does the organizer want to know the sales? does the buyer their ticket? does marketing their campaign?). The method: 5 whys with the stakeholder ("why push? → because the organizer doesn't see sales → when do you need them? → at day's close → 31's daily email solves it, no mobile app") — the requirement asks for push; the problem asks for visibility; the cheapest solution is a different one. The tech is responsible for asking: the "yes" to the misunderstood requirement is the feature nobody uses (and that you paid for).

Direction 2: the technical limitation → the product decision: "the inventory does not admit 10k simultaneous reservations on the same event" → the product chooses: presale shifts (23/36: free), partitioning (55: 2 weeks), or rejecting peaks (the waiting room). The rule: the tech does NOT decide the trade-off (49: you present options with cost), but MUST explain the consequences IN BUSINESS LANGUAGE: "without shifts, 40% of the peak's buyers will see errors" — the conversion %, not the p95.

3. The metrics the business reads (and the tech moves)

The business's dashboard (different from 46's technical one): sales/day, checkout conversion (visits→purchase), abandonment at the payment step, NPS/complaints, invoiced commission. The tech moves each one: the checkout p95 (46) moves conversion (every extra 100 ms: measurable abandonment); the failed email (29) moves complaints; the seat sold twice (10) moves NPS and refunds. The habit of the backend that understands the business: every technical project carries its impact line ("36's turnstile: protects Saturday's presale peak, the sale that pays the quarter") — work without an impact line is suspect of TIC (Technical Impression Competition).

And the metric the tech PROTECTS without being asked: 46's error budget is the business's RELIABILITY allowance: the business demanding "zero errors AND three features this week" is spending a budget it doesn't have — the tech explains it with the number (46's burn), the business decides (features or reliability this sprint?).

4. Prioritizing with the business: the backlog that's worth it

The business's prioritization: value (what does it move: revenue, retention, risk?), effort (49), risk (what if it fails? — 22/32). The matrix the real backlog uses: effort ROI: the peak's turnstile (2 weeks of effort, protects the year's sale) beats the mobile app (2 months, an unvalidated retention hypothesis). The tech contributes: the honest cost (49: with its uncertainty) and the cost of NOT doing it (the risk). The tech-prioritizer's mistake: prioritizing by TECHNICAL INTEREST ("I want to migrate to K8s", 43) without a business line — 43's ADR exists because the real trigger arrived: the decision is fired by the business, executed by the tech.

And the technical "no" that protects: "the business" sometimes asks for what breaks the business (the real-time report over the 2M-row ledger for every admin request: 09 kills it in the p95; 38's cached view or 31's batch solves it). The no-with-alternative is service; the dry no is obstruction; the mute yes is the 500 in prod.

5. The complete craft: why this module closes the course

The senior backend is not the one knowing more frameworks: it is the one converting the business's problem into the simplest system solving it — and defending that simplicity. The course built TicketFlow whole (inventory, money, events, observability) and this module explained FOR WHAT: every lock (10) protects the sale; every outbox (25) protects the trust; every ADR (48) protects the memory; every SLO (46) protects the conversion. The craft's final question — the one 57 (the capstone) examines: "can you explain the system without technobabble to the business owner, and the business without jargon to the tech team?" — the bidirectional translation IS the senior skill.

Self-assessment

1. Which business-model line does each technical piece of the course protect (the lock, the outbox, the ledger, the SLO)?
2. The requirement's 5 whys: when was "push notifications" "a daily email", and which method reveals it?
3. Which business metrics does the tech move, and how is the p95 explained to the ones invoicing?
4. What does the tech contribute to prioritization, and when is prioritizing by technical interest legitimate?
5. Which bidirectional translation defines the senior, and which exam (57) tests it?

Continue with the exercises. The solutions only after trying it yourself.