Problem first: start from the user, not the technology
Tuesday, 9:00. Partner support has 9,000 tickets a month and a 31-hour response time. Five of StayHub's biggest hotel groups say the fix is obvious: an AI assistant in the partner extranet. Three engineers, three months. Karim wants a yes by Friday.
Before you build anything, find out who is struggling and why. The best code for the wrong problem is still wasted.
- Problem
Five of StayHub's largest hotel groups ask for "an AI assistant in the partner extranet". Partner support gets ~9,000 tickets a month and first response takes 31 hours.
- Why the simple system fails
The team builds what was asked: three months, three engineers on an assistant. Ticket volume barely moves, because 38% of tickets are owners asking why they were paid less, and the extranet only shows one payout total that no assistant can break down.
- Engineering concept
Start from the user's problem and the evidence for it; describe the job the user is trying to get done; then choose the simplest solution that does that job, which may not involve the technology you were asked for.
- Technology
Support-ticket analysis, product analytics, user interviews, jobs-to-be-done statements, problem briefs and evidence-backed requirements.
- Trade-offs
Discovery takes days before code starts and may kill a feature someone senior wants. In exchange you avoid months of building the wrong thing.
The problem
2 min- Karim · CTOFive of our biggest hotel groups want an AI assistant in the partner extranet. 3 engineers, 3 months. Yes by Friday?
- You · Engineer at StayHubWe already have the agent runtime. It's mostly reuse.
- Lina · Senior engineer, your mentorWhat problem are we solving? Guess before we look.
The big idea
4 minStart from the user's problem and its evidence. Choose the technology last.
A patient says "I need antibiotics". A good doctor asks about the symptoms and runs a test first. Sometimes it is antibiotics; often it's rest and water.
How it works
5 min- 1Restate the request
Problem vs solution: the problem is what hurts the user; requests usually arrive as solutions. "An AI assistant" → "partners wait 31 h; what are they asking?"
- 2Size it from data
Evidence is what users really did. Rank ticket reasons by count × handling time over 90 days.
- 3Explain the numbers
Talk to 6–8 partners about the last time they contacted us (), never "would you use…?".
- 4Name the job
A names no solution: "When my payout changes, I want to see why in a minute, so I don't spend an evening in Excel."
- 5Write the brief
A problem brief, one page before code: problem, evidence, job, success metric, non-goals.
- 6Cheapest solution + metric
Pick what solves the job with the least effort, and agree how success is measured.
Watch a decision being made
4 minLina runs one week of discovery
Give Karim a decision by Friday that solves the real problem behind the request, with evidence.
- 1Size problems from tickets
Agent-hours per month over 90 days:
textreason_tag tickets avg_min agent_hours payout_question 3,420 12.0 684 availability_sync 1,350 9.0 203 howto_rates_photos 1,980 4.0 132Why: Count × time ranks by cost. By count alone, how-to questions would wrongly beat sync errors.
- 2Explain the numbers
8 owners, asked about the last time they wrote about a payout: 7 had rebuilt the month in a spreadsheet first.
Why: Tickets say what; interviews say why.
- 3Pick the cheapest solution and a metric
A payout breakdown page, 3 weeks. Metric: payout tickets −50% in 8 weeks.
Why: It solves the job directly, and it's the data an assistant would need later anyway.
- 4Say "not now" with a path
"Not the assistant now. Once the page is live we re-rank tickets; if how-to questions lead, the assistant is next."
Why: A bare "no" gets overruled. Evidence plus a condition becomes a decision people accept.
In real life
3 minAmazon: "working backwards"
- Publicly described writing the press release and FAQ before building
- Slower start; many ideas die on paper
Fits big, hard-to-reverse bets.
Early Facebook: "move fast and break things"
- Its famous early motto favoured shipping and learning from usage
- Many shipped things get rolled back
Fits cheap, reversible changes.
What goes wrong
3 min"Let's use AI" picks a solution before anyone knows the problem.
Problem and evidence first; technology last.
One big customer can dominate while most users suffer from something else.
Size with data (frequency × cost); interviews explain it.
Every launch looks like a success.
Agree before building how you'll know it worked, and remove what isn't used.
Trade-offs
3 min| Option | Fits when | Costs |
|---|---|---|
| Build what's requested | Small, reversible, or already evidenced | Risk of building the wrong thing |
| Discovery first | Large, expensive, a solution with an unclear problem | Days to weeks; can feel slow |
- Karim · CTOThese groups are 30% of partner revenue and asked for an assistant by name. A page will feel like we ignored them.
- Maya · Product managerThey asked because support is slow. Fewer tickets is what they actually want.
- Karim · CTORelationships run on being heard.
Your job as tech lead
4 minClaude Code can write the code for this. You still own the decisions, and you have to know what good looks like to accept or reject its work.
- Whether to build what was asked at all: the agent will happily build an assistant if you ask.
- Which evidence counts: ticket reasons over 90 days and what owners actually did, not survey answers.
- The job to be done and the success metric (payout tickets −50% in 8 weeks), agreed before building.
Before we build anything for partner support, help me size the problem. Don't write product code. Read `data/partner-tickets-90d.csv` and write `scripts/ticket-reasons.ts` grouping tickets by reason tag with agent-hours from handling time. Show the top five reasons with counts, average minutes, agent-hours per month and five sample tickets each. Summarise what `src/extranet/payouts/` shows today, in plain words. Then stop: I'll decide.
- Top line by hand: ~3,420 × 12 minutes ≈ 684 agent-hours a month.
- Sample tickets really say what their tags say.
- Claude only read and summarised; nothing was built.
- Scaffolding a chatbot or picking an LLM before the numbers exist.
- Counting tickets but ignoring handling time.
- "82% would use it" cited as evidence of demand.
Check yourself
2 minNext episode: the payout page has three weeks. Karim asks what we're going to cut, and Omar asks what we're going to owe.
Mark it complete to update your skill map.
Go deeper (optional)You don't need this to understand the lesson. Open it when a project needs the details: Technical deep dive, Visual diagram, Analogy, Check your understanding, Practice ladder, Explain it yourself.
Technical deep dive
Lina runs one week of discovery
Five hotel groups ask for an AI assistant (3 engineers, 3 months). Give Karim a decision by Friday that solves the real problem behind the request, with evidence.
- 1Restate the request as a problem
"Partners wait 31 hours for support answers, and 9,000 tickets a month overwhelm the team." The assistant is one possible solution.
Why: As long as the goal is "build an assistant", every finding gets bent to fit it.
- 2Size problems from tickets
Run the agent-hours query over 90 days. Result per month: payouts ~684 h, availability sync ~203 h, how-to questions ~132 h.
textreason_tag tickets avg_min agent_hours payout_question 3,420 12.0 684 availability_sync 1,350 9.0 203 howto_rates_photos 1,980 4.0 132Why: Count × time ranks problems by what they cost, not by who's loudest.
- 3Explain the numbers
Interview 8 owners about the last time they asked us about a payout. 7 of 8 had rebuilt the month in a spreadsheet first.
Why: Tickets say what; interviews say why. Past events give facts; hypotheticals give optimism.
- 4Write the job and the brief
Job: "When my payout changes, I want to see why in a minute, so I can trust StayHub and not spend an evening in Excel." Brief: problem, evidence, job, metric, non-goals.
Why: The job describes success without naming a solution, so cheaper options can compete.
- 5Pick the cheapest solution and a metric
A payout breakdown page (3 weeks): every booking, commission, cancellation and chargeback behind the total. Metric: payout tickets per 1,000 bookings −50% in 8 weeks.
Why: It solves the job directly, and it's also the data an assistant would need later.
- 6Say "not now" with a path
To Karim: "Not the assistant now: payouts are 38% of tickets and a breakdown page takes 3 weeks. Once it's live we re-rank the tickets; if how-to questions (~132 agent-hours a month today) lead what's left, the assistant is next."
Why: A bare "no" gets overruled. Evidence, a cheaper option, and what would change your mind make it a decision people can accept.
| Evidence source | Tells you | Watch out for |
|---|---|---|
| Support tickets | Frequency and cost of problems | Only users who bother to contact you |
| Product analytics | What users actually do, where they drop off | Shows what, rarely why |
| Interviews (5–10) | Motivations, workarounds, context | Small sample; ask about past events, not hypotheticals |
| Sales / account notes | What blocks deals | Loudest customer ≠ typical customer |
| Search logs, failed queries | Unmet needs in users' own words | Noisy; needs clustering |
Visual diagram
From a solution-shaped request to an evidence-backed decision.
Analogy
- At the doctor's"I need antibiotics"Building software"We need an AI assistant"
- At the doctor'sSymptoms and test resultsBuilding softwareTickets, usage data, interviews
- At the doctor'sThe diagnosisBuilding softwareThe job to be done
- At the doctor'sRest and fluids, the simple cureBuilding softwareA plain payout breakdown page
Where the analogy breaks: a doctor sees one patient at a time. You're diagnosing thousands of users at once, so you need data across many of them, not just the loudest voice in the room.
Check your understanding
Practice ladder
Rank the guest-support problems
Estimation Warm-upThe query over 90 days of guest support tickets returns (per month):
| reason_tag | tickets | avg_min |
|---|---|---|
| change_dates | 4,800 | 8 |
| where_is_my_refund | 1,500 | 14 |
| checkin_questions | 2,200 | 3 |
| wifi_parking_faq | 2,600 | 2 |
| invoice_request | 900 | 6 |
Compute agent-hours per month for each, rank them, and say which problem you'd look at first and why the ranking differs from ranking by ticket count.
Finish the payout brief
Design PracticeLina's brief has three gaps. Fill them in.
problem: Partners can't see why their monthly payout changed. who: Hotel owners and finance staff of StayHub partner hotels. evidence: - 38% of partner tickets (~3,420/month), avg 12 min each (~684 agent-hours) - 7 of 8 interviewed owners rebuilt last month's payout in a spreadsheet first job_to_be_done: ___ success_metrics: primary: ___ guardrails: ___ not_doing_now: - AI assistant in the extranet (revisit after launch)
"We need an AI trip planner"
Scenario PracticeMarketing: "Competitors launched AI trip planners. We need one by summer." StayHub's guest app already has search, the concierge, and bookings.
Plan one week of discovery: what you'd look at, who you'd talk to and what you'd ask, and what result would make you say yes, no, or "something else".
The biggest customer wants a custom report
Decision StretchA hotel group with 120 properties (8% of partner revenue) asks for a custom monthly Excel report "exactly like our old provider's": 40 columns, their own formulas. Estimate: 4 weeks for one engineer, plus maintenance whenever their format changes.
Facts from discovery: - Their finance team uses 9 of the 40 columns, and 7 of those 9 are on the new payout breakdown page. - Three other large groups asked for "better exports" in the last quarter.
Write a short decision: "We chose X over Y because…, accepting the risk of…".
Explain it yourself
Explain to a new engineer why you didn't just build the extranet AI assistant the big hotel groups asked for, and how you decided what to build instead.