Lesson 51 — Understanding the business

Exercise 1 — The money map

1. The model (10 lines): "Organizers publish events and pay a 5% commission per ticket sold. Buyers pay for tickets with card/gift card. Revenue = commission (08's ledger); risk = selling the same seat twice (refund + reimbursement + reputation) and the presale peak (the year's sale in 2 h). The buyer's trust ('I paid and it arrives') is the cheapest asset to lose".
2. The table with lineless pieces: 12's leaderboard (INCR) found no line → decision: boring infrastructure for the internal dashboard (it stays, documented as such) or it dies (if nobody looks: 42's hunting). Both answers legitimate; the unconscious one is not.
3. The invoicing query: 08's ledger with SELECT org_id, SUM(amount) WHERE kind='comision' AND mes='2027-09' GROUP BY org_id — the only query the business asks of the ledger: if the schema doesn't answer it (does the kind exist? the month?), invoicing is a hand-made Excel: the exercise's finding is the model's gap.

Exercise 2 — The 5 whys

1. The three: (push) why? the organizer doesn't see sales → when? at close → 31's daily email (0.5 d vs 2 weeks of app); (Excel) why? finance crosses it with theirs → which fields? commission per org/month → the ledger's CSV with exercise 1's query (0.5 d); (30-min hold) why? the buyer "loses" seats while thinking → how long do they think? conversion drops at 10 min → 10 min with an explicit Retry-After (26) since the data says 10.
2. The dialogue: "What does the organizer need?" → "To see sales" → "For what?" → "To know if I promote" → "When do you decide?" → "At day's close" → "What serves you: live sales or the day's summary?" → "The summary, if it arrives before 9" → the real problem: the daily summary at 8; the solution: 31's job + email; the push (2 weeks) dies.
3. The savior: "who uses it and to decide WHAT?" — the "real-time dashboard" feature nobody opened: the question would have revealed the real use was monthly (finance's CSV).

Exercise 3 — The business translation

1. The translations: (a) "1.2 s" → "the checkout is slow enough that ~8% of buyers abandon: that's X €/month" (conversion); (b) "outbox 800 pending" → "confirmation emails are delayed up to 20 min: buyers call support" (complaints); (c) "saga UNKNOWN 1 h" → "there are payments we don't know went through: money in limbo; at the hour, someone reviews it by hand" (risk); (d) "budget 80%" → "we already spent 80% of the month's error margin: one more incident and we stop shipping features" (the features-vs-reliability decision).
2. The options with cost: (shifts: 0 €, the peak's conversion drops 5% but zero errors), (partitioning: 2 weeks ≈ 6k € of work, the peak gets absorbed fully), (reject: 0 €, 40% of the peak sees an error and ~10% never return). Recommendation: shifts now, partitioning if the ×2 peak confirms — it informs, it does not decide (the owner chooses the conversion they lose).
3. The budget explained: "The system admits ~6,500 slow requests/month as margin. The 3 proposed features consume ~4,000 in tests and risk. The proposal that fits: 2 features (4,000 margin left) or the 3 with explicit acceptance of taking the margin to 0 (if anything fails, the freeze is immediate)". The number decides the conversation.

Exercise 4 — The backlog with value

1. The matrix: 47's runbook (high value/mitigated high risk/low effort), the peak's turnstile (high/high/medium), the K8s migration (TIC: unproven value), the mobile app (hypothesis), the CSV export (high/low/0), partitioning (conditional on the trigger), the daily email (high/low), the real-time dashboard (low: the CSV suffices).
2. The ROI's top: (1) the ledger's CSV export (1 day: invoicing stops being Excel), (2) the runbook (47's MTTR), (3) the turnstile (the year's sale). The honest surprise: NOT ONE new product feature in the top 3: the business buys RELIABILITY and invoicing before features — the whole module's lesson.
3. The no-with-alternative: "The real-time per-request report over 2M rows kills the admin's p95 (09) and the public's (same DB). Alternatives: (a) the 15-min cached report (38) covers 95% of the questions; (b) if someone needs sub-minute, 30's stream feeds the dedicated dashboard WITHOUT touching the sales DB. I recommend (a) now and (b) when someone asks with data."

Exercise 5 — The bidirectional translation

1. The pitch without technobabble: "We sell the digital box office for concerts and theatre. The organizer publishes their event and we sell the tickets and hand them their money for a commission. The buyer picks their seat, pays and receives their ticket instantly. The hard part —the thing we do well— is that the same seat is NEVER sold twice, not even when 5,000 people buy at once. And if something breaks, we know what happened and fix it before anyone calls."
2. The inverse pitch: "We sell conversion: every checkout second is worth a % of abandoned carts. Revenue is the 5% commission on the sale invoiced in the ledger. The presale peak is the quarter's sale: protect the peak before adding features. And trust ('I paid and it arrives') is what prevents the organizer's churn."
3. 57's essay (10 sentences, excerpt): "Seats are never sold twice because the reservation is a transaction with a lock (10). Every confirmation emits a record that cannot be lost (25). The payment is a conversation with the gateway that knows what to do if it doesn't answer (32). If something breaks, an alert sounds and the runbook guides (46/47). Every important decision is written down and has a review date (48)."

Professor's summary

• Every technical piece protects a line of the money model; the piece without a line is over-engineering or boring infrastructure — never unconscious.
• The 5 whys turn requirements into problems; the business translation speaks of conversion and euros, not of p95.
• The backlog orders by value/effort/risk with 49's honest cost; the "no" with alternative is service. The bidirectional translation is the craft's exam.