The 0 to 1 data product playbook

Every company above a certain size eventually says some version of "we should do something with our data." What happens next usually follows one of two scripts.

Script one: hire a data platform team, spend eighteen months on infrastructure, ship a warehouse and a semantic layer and a dashboard suite, and watch adoption flatline because nothing anyone's job depends on actually changed.

Script two: find one decision that one team makes badly and often, ship something ugly that makes that decision better, and let demand pull the platform into existence behind it.

Script two wins nearly every time, and almost nobody follows it. After ten years of building data products inside companies from startups to Atlassian, here's the playbook I keep coming back to.

Start with a decision, not a dataset

The worst starting question is "what data do we have?" That question leads to inventory tours and use case brainstorms and a roadmap of things nobody asked for.

The right starting question is "what decision gets made badly, often, by people who feel the pain?" Weekly is better than quarterly. A decision made fifty times a week by twenty people is a product opportunity. A decision made once a year by an executive is a consulting engagement.

You're looking for three properties: the decision recurs, the current process is visibly bad, and the person making it would notice the improvement within a week.

Ship embarrassingly early

The first version of a data product should be almost embarrassing. A Slack message that fires when a threshold trips. A spreadsheet that updates itself. One screen with one number and one recommended action.

This isn't about scrappiness for its own sake. It's about what you're actually testing. At the 0 to 1 stage, the risk isn't technical. The risk is that nobody changes their behavior. You can test that with duct tape. If people won't act on the ugly version, they won't act on the beautiful one, and you just saved yourself a year.

Measure adoption by the decision, not the dashboard

Data teams love usage metrics: views, queries, weekly actives. All of it can be theater. A dashboard with a thousand views that changes zero decisions is a screensaver.

The metric that matters is decisions changed. Did the sales team actually reorder the queue based on the score? Did anyone kill the campaign the model flagged? Instrument the action, not the pageview. This is also where the moat starts, because a record of decisions and outcomes is the one dataset your competitors cannot go collect.

Resist the platform until it hurts

The platform instinct is strong: generalize early, build for the use cases that will come. Resist it. Every abstraction you build before the second use case exists is a guess, and most guesses are wrong.

The right time to build platform is when the second and third data products are being visibly slowed by the shortcuts in the first. Platform justified by pain is infrastructure. Platform justified by strategy decks is expensive fan fiction.

The role nobody staffs

The gap in most companies isn't engineers or analysts. It's ownership. Data products fail in the space between the data team, which knows what's possible, and the business team, which knows what's valuable. Someone has to live in that gap: pick the decision, define the wedge, say no to the platform, and be accountable for whether behavior changed.

Call it a data product manager if you want. Titles don't matter. What matters is that when you ask "who owns whether this changes a decision," exactly one person raises a hand.