Tell me what data a company I name should be collecting today and is probably not.

The job-completion screen is four taps long, and almost nobody lingers on the fifth. Here's the company I'm naming: Bramford Home Services, a marketplace where homeowners post repair jobs and licensed contractors bid on them. Loredana Fitch is Head of Product, and the question on the table is what Bramford should be collecting today that it almost certainly isn't.

How to answer this, stage by stage

Nobody is scoring whether you can name an interesting data source. They're scoring whether the data you name would actually change what the company does next.

Let's learn

Here is what happens when a marketplace knows exactly what a job cost and has no idea whether that price ever actually held.

Before Bramford, a homeowner needing a repair called two or three contractors, compared verbal quotes, and picked one mostly on gut feeling, roughly ninety minutes of phone calls for a single job. With Bramford, three to five bids come back in an app within an hour, and the homeowner picks one and books it directly. Today, Bramford tracks the job request, the bids, the accepted amount, and a binary "complete" flag. Two weeks later, an optional star-rating notification goes out. About 8 percent of homeowners ever tap it.

This is the habit the whole anchor is designed to replace: a homeowner doing their own verification by hand.

Here's the turn: Bramford's dashboard shows every accepted bid as a success the instant a job is marked complete. It has no way to tell a bid that held from a bid that ballooned 40 percent in change orders after the homeowner had already committed. The gap between "accepted" and "actually went as promised" is invisible on every report Loredana's team looks at.

This is the one screen the whole answer turns on: four short fields, none of which exist in the product today.

At its worst, a marketplace can look flawless in its own numbers, bids accepted, jobs completed, for years, while a meaningful share of homeowners are quietly eating price increases they had no way to see coming, and Bramford has no systematic way to even notice it's happening.

What I would leave alone: I wouldn't touch the bid-submission flow itself. Contractors bidding quickly and homeowners comparing bids side by side is the part of Bramford that already works, and adding friction there for the sake of "more data" would cost more than it's worth.

The lesson: knowing what a system did is not the same as knowing what happened because of it.

Now here is the same thing as a story

The short version above is what you'd say scoping this live in an interview. Read this one for how a near miss turned an $80 credit into the whole product decision.

Curtis Yaeger has fixed water heaters and garbage disposals for eleven years. He's one of Bramford's most-booked contractors in his metro, mostly because his bids come in fast and his jobs get accepted often.

For his first year on Bramford, Curtis bid the way he always had: a fair, honest number based on what he could see from the homeowner's photos and description. Sometimes a job turned out harder than expected once he was inside the wall, and the final price ran higher. That was just the job. Nobody tracked it, so it never cost him anything either way.

Then, near the end of his first year, a different contractor's job on the platform almost went badly: a homeowner accepted a suspiciously low bid, and only a Bramford support rep, following up on an unrelated question, happened to notice the final invoice had come in 60 percent over the accepted price. The homeowner had nearly signed off on the difference without ever flagging it. It was luck, not process, that caught it.

The same two-question survey. One version only hears from the edges. The other actually hears from everyone.

That near miss is what put the outcome-check project on Loredana's roadmap. Once word got around among contractors that price accuracy might start getting tracked, some, including Curtis, began quietly changing how they bid, not the honest number anymore, but a number designed to look accurate later: padding the initial estimate a little, or splitting anything that might run over into a separate "approved change order" that wouldn't count against the tracked price at all.

Two of these three branches are exactly the kind of expensive, camera-in-the-home build that would have delayed shipping the one thing that actually mattered.

Nobody at Bramford decided to let contractors learn the tracked metric's shape and bid around it. It happened because the first design of the outcome check counted "final price" as whatever number the contractor typed into a field they controlled, with no independent confirmation from the homeowner at all.

Rerun the same year with the anchor built from the start, homeowner-confirmed price plus a rehire question, incentivized broadly: Curtis's padding strategy stops working, since it's the homeowner's number that counts, not his own. The near miss never has room to happen twice, because a suspicious price gap on any job shows up in the data long before it reaches a support rep by accident.

What I'd tell myself, hearing how close that near miss came to a real loss: the survey wasn't wrong to be lightweight and optional at first. It was wrong to stay that way once contractors and price accuracy were both riding on a number that only the loudest customers ever bothered to confirm.

SPARK, the design that survives its own riskNot a data wishlist. SPARK is what turns "we should collect more" into one specific, defensible screen.

The recap, one line per letter: situation is homeowners hand-verifying prices by calling around, payoff is getting them to stop and trust the match instead, anchor is a homeowner-confirmed, incentivized outcome check at 48 hours, risk is a biased sample and gamed self-reporting, and keep out is skipping photo and computer-vision verification until the simple check proves itself first.

And if you want to be sure it really works, try it somewhere elseSame five letters, a waste-collection fleet instead of a home-services marketplace. Different flip family entirely, the same missing confirmation loop.

Ridgeline Waste Services runs an onboard camera system that flags bins as likely full so a route can be adjusted the same morning. Mapped onto SPARK: situation is drivers today eyeballing every bin themselves with no model input at all on some routes. Payoff is drivers trusting a flagged bin enough to skip the manual double-check on routes where the model runs. Anchor is a single driver-confirmed tap, "was it actually full," logged against the same photo the model scored, closing a loop the current system never had at all. Risk is drivers getting lazy and tapping "yes" without really looking once the model earns some trust, quietly reinforcing whatever mistakes it already makes. Keep out is a second onboard weight-sensor system, too expensive for the marginal lift over a simple confirm tap. The flip here is a verification one, the familiar family, but worth naming since the anchor itself is what's designed to prevent it: cross-checking a random 5 percent of "confirmed full" taps against dispatch review is the guardrail that catches drivers sliding into rubber-stamping the model instead of actually checking.

The driver-confirmed tap sits exactly where a good anchor should: cheap to collect, and doing real work.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "find the manual check people already do to protect themselves, and turn that exact check into the missing data point," and stop.
Cost: no engineering time to build the incentive mechanism this quarter. Say so honestly, and ship the unincentivized version first while flagging in the doc that the sample will skew until a reward exists.
The company already collects this, for real: if Bramford turns out to already log homeowner-confirmed pricing somewhere support tickets live, the honest move is to say the gap is smaller than it looks and focus the anchor on surfacing that data instead of collecting it twice.

Where people run it wrong.
They ask for more data in general, instead of naming the one specific field that's missing and why it matters.
They collect an outcome signal with no incentive, and mistake a biased trickle of extreme opinions for real coverage.
They let the person being measured also be the one reporting the number, with nothing independent to check it against.

How to use it live. The moment someone names a company and asks what it should be collecting, ask yourself: what does a user of this product currently do by hand to protect themselves from being wrong, and how would I turn that exact behavior into a data field? That's almost always the missing anchor.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0