Three projects, starting with one real copy

The top box is her answer to "how will you know this worked?", and it is written in her words, not yours: the auditor stops asking, and Priya's Monday takes one hour instead of six. Two things she can see without opening anything you built. A pipeline is not on it, and neither is a warehouse, a single source of truth or a daily refresh, because she never said any of those was the point.

Test the top box by turning the tree over. If what sits at the top is "a pipeline" or "connect the systems", the tree is upside down: a solution is pretending to be an outcome, and every branch under it will be a feature of the pipeline, sources, schedules, tables, rather than a pain of hers. That is the tree that produced the vendor integration project two years ago, which stalled the week Kenneth went on leave and never restarted. An outcome box you can check a build against reads like a fact about her office in eight weeks: a letter that stopped coming, a Monday that got its afternoon back.

Keeping her words is not politeness. "The auditor stops asking" is the sentence her board and her auditor already understand, so a project that points at it is one she can defend upward without translating. The moment you rewrite it as "improve data consistency across systems", it is your project again, and she cannot tell whether it worked.

The second row is a transcript, not a brainstorm. Each box is a pain she voiced behind doors 1 to 4: finance and the POS differ by about two percent every month and the auditor has asked why in writing; at month-end finance books its own number and argues afterwards; Priya downloads 38 CSV files every Monday and a 2019 macro merges them, six hours; when a number is wrong Priya fixes it by hand and nobody is told; three versions of the stock spreadsheet are in circulation and the one Priya treats as real is on her laptop; product codes differ between the Singapore and Malaysia outlets. Six boxes, six things she said.

The discipline is to write nothing in this row she did not say. "No single source of truth" is your diagnosis; "three stock sheets, one on Priya's laptop" is her pain. The first is a solution wearing a problem's clothes, and it pulls a warehouse in behind it. Torres's rule, as reported, is that opportunities are framed from the customer's side, and the reason is practical: a pain in her words is one she recognises on the page and fights for, and a diagnosis in yours is one she nods at.

Which opportunity is strongest is the first real judgement on the page, and it is a judgement about her test, not about the data. The two percent gap earns the thick edge because half of her test, the auditor, is decided by whether anyone can say in writing why the two numbers differ. The 38 CSVs are the other half, and they come second in the tree for a reason Part 2 makes plain.

Solutions are the only layer you invent, and the rule is at least two per opportunity you take seriously. Under the two percent gap: a written bridge that names each timing gap, card settlements two days late, cash deposited weekly, refunds that exist only in the accounting system; a nightly pipeline that loads the POS and the ledger into one table; a reconciliation tool bought once the SGD 15,000 opens in Q1. Three shapes, from cheapest to dearest. Writing three stops the first one you thought of, for most engineers the pipeline, from becoming the plan because it was alone on the page.

Torres's fourth layer, assumption tests, is where the pipeline shows its problem. The assumption under "POS and ledger in one table" is that the two copies are measuring the same thing on the same day, and her own answer says they are not: the gap is mostly timing, with refunds that the POS never sees. The pipeline would faithfully deliver the two percent every morning instead of once a month. The assumption under the written bridge is that three named timing gaps account for most of the difference; the test is to write the bridge for four outlets from last month's export and see what is left over. The Product Thinking course teaches the tree as a discipline; here it is borrowed for one job, ordering what she already told you.

Pruning has one rule: one candidate under each of the three strongest opportunities, never three solutions to one. Three ways to reconcile the revenue is a menu, and a menu makes her choose a build. Three projects under three different pains is a portfolio, and a portfolio lets her choose a problem, which is the choice she is qualified to make.

An engineer's candidate is written in six lines, two more than most: what it is, in words from her tree; the first step, something that can start this week; who does it, a named person on her side and on yours; what it needs; which copy it declares real; and whose login it runs on. The fifth line is the one that stops a pipeline moving the disagreement faster. Candidate 1 declares one of the three stock sheets real, and it is her decision, not Priya's laptop's. Candidate 2 declares the POS export the copy the Monday report is built from, with every hand fix Priya makes written down beside it, because a silent fix is a second source of truth. Candidate 3 declares which revenue number is booked at month-end, which today is finance's, and writes down why the POS differs from it.

The sixth line is the fact that only comes out once she trusts you, a gate of 3 on session 3's bench. Kenneth is the only IT person, holds the only POS admin login, and leaves in January. So candidate 2 runs on Priya's own access, the way she downloads the 38 files today, and the vendor API waits until someone other than Kenneth can say yes to it. Whether the POS lets an ordinary login schedule its export is not on her sheet. It is the assumption the first step tests, and until it is tested, confidence on row 2 is a 5.

Sean Ellis and Morgan Brown's ICE score, reported here from Hacking Growth, rates each candidate on impact, confidence and ease, each from 1 to 10. How the three are combined is contested: some teams multiply, some average, and the summaries that quote the book describe it differently. So the honest move is not to pick the right rule. It is to write down which one you used, above the grid, before you fill in a digit.

The grid above shows why. Multiplied, the three rows score 288, 315 and 504. Averaged, they score 7.0, 7.0 and 8.0. The winner is the same, but the order below it is not: averaging ties the stock sheet with the export, and multiplying puts the export ahead, because its one weak leg, a confidence of 5, is outweighed by an impact of 9 that speaks straight to Priya's six hours. Multiplying punishes a weak leg harder than averaging does; averaging forgives it. Neither is wrong. An unwritten rule is.

The digits are yours, and that is the point rather than a weakness. "Why is impact only 4 on the stock sheet?" is a conversation about her office, and the honest answer is that stock is not in her test; she did not mention it when asked how she would know this worked. A grid with the rule above it is a page she can argue with. A ranking with no rule and no digits is a verdict, and a verdict she did not make is one she will not defend to the auditor.

Google's machine learning problem-framing course, read at source, gives one line that belongs on every engineer's prioritisation grid: verify that the current non-ML solution is optimized before you build anything cleverer. The course is about models, and the line is about pipelines too. At Harbourline the clever thing is an integration through the vendor API, which nobody has ever used. The current solution is Priya's 38 downloads and a 2019 macro, and it is not optimized; it is a person doing by hand what one scheduled export could do. Fix the current way first and the API becomes a second step with a known baseline. Start with the API and you are building on a login that leaves in January.

The same logic puts the written bridge first. Card settlements landing two days late, cash deposited weekly and refunds that live only in accounting are not a data problem any tool will fix; they are three sentences that belong on a page before any job runs. The Decision Intelligence course owns the wider discipline of choosing between options under uncertainty; the grid here is a single page of it.

A pilot is the winning candidate with four things pinned to it: a scope, a partner, a test and a date. All four came out of doors 5 and 6, so none of them is yours to invent. Scope: four outlets, because she said she would run a pilot in four first, never all 38. Partner: Priya, two hours a week. Test: the auditor's written answer, due in eight weeks, and a Monday that takes one hour. Budget: nothing before Q1.

The pilot runs the winner first and the runner-up's first step second, because the order is the argument. The bridge comes first: for four outlets, from last month's export, the three timing gaps written as sentences, card settlements two days behind the till, cash banked weekly, refunds that only the accounting system sees, and whatever is left over written as "not yet explained". Only when finance and the POS agree on why they differ does anything get automated, and the first thing automated is small: Priya's own export for the same four outlets, on her own login, with every hand fix written down. A pipeline built before the bridge moves the disagreement faster; a pipeline built after it carries a number both sides have already agreed to disagree about, in writing.

Four outlets beat 38 for a reason she can feel and you can measure. In four outlets the bridge is a page Priya can check line by line against the till receipts; across 38 it is a report nobody reads to the bottom. And her test beats a pipeline metric because the pipeline metric measures the build: a job that ran every night for eight weeks and an auditor who is still asking is a failed project with a green dashboard.

Run session 3's bench on the order tuned for an engineer and read the log to the end, not just the total. The data-state door opened widest gets her test and her four-outlet scope from "How will you know this worked?", and it gets Kenneth's login, the monthly export limit and the three stock sheets. Then it runs out of minutes on the limits question, before "When is the next date you have to show something upward?" and "Who on your side could spend two hours a week with me?" are ever asked. So the tuned 45 minutes never hear the board in six weeks, the auditor's answer due in eight, or Priya's two hours.

The printed door order has the mirror-image gap: it hears the dates and Priya's two hours, and misses her test, the four outlets and Kenneth. Neither order hears everything, which is the honest state of any 45-minute meeting. The pilot above uses facts from both, and the ones your own meeting did not reach are not facts yet. On your page they are marked as guesses to confirm, and session 6 puts them in the covering note as the two questions you did not get to.

She told you Kenneth is leaving in January, and she told you she has not told the team. That fact decides the plan without being written into it. Every step in the eight weeks runs on access someone other than Kenneth holds: the bookkeeper's monthly export, Priya's own downloads, a page. Nothing waits for the admin login, and nothing needs it after January. The vendor API goes on the Q1 list with one line beside it, "needs an admin login we can keep", which is true whoever holds it.

The discipline is to use a confidence without spending it. Priya is your partner and will read the brief; a line that names Kenneth's departure is a line Adeline did not agree to publish. Design around the fact, keep it in your own notes, and let the brief say only what the plan needs: no step depends on one person's login.