← Back to Lab

The Field of Dreams Fallacy


Kevin Costner was a hot actor in the 1990s: Waterworld, Robin Hood Prince of Thieves, The Bodyguard. You couldn’t turn your head in a video shop without bumping into a cardboard cutout of him.

Kevin has been making his return to our screens, from “hot actor” to “distinguished veteran” in the form of Yellowstone.

Yet it’s the misquoted film, The Field of Dreams (1989), that has left a lasting, and terrible, legacy on the data industry. To misquote the film: “build it and they will come.” I have uttered this misquote myself. I have heard many, many others utter this phrase. I’ve stopped uttering the misquote because I’m left with the questions: What am I building and who am I building it for?

For Kevin, the answer was easy: he’s building a baseball field in a corn field for the ghost of his father. The effort of building a baseball field almost cost Kevin everything - his farm, his mental health. It paid off for Kevin, because Hollywood loves a happy ending, and people came to pay top dollar to watch ghosts play baseball.

For many of us, we have built data platforms without clear customers and outcomes - with the blind faith of “build it and they will come” to find out that they don’t come and, depending on the amount of effort involved, have built a prototype or a hobby - mostly on the hobby scale.

There’s nothing wrong with hobbies. They are great ways to alleviate the stresses of life. I once built an open sourced story box for my children, because I didn’t want my children to be locked into a proprietary storage format. It cost far more than buying something like a Yoto, the wiring is fragile, but no vendor lock-in and I had fun building it. I don’t have customers for the story box, I have a captive audience (my children) who have no other choice but to use it. It was a hobby - no harm done.

But we (the data industry) have approached our capex and opex intensives platforms as if they are hobbies and have managed to fund them because it’s “for the business”.

The phrase “for the business” hides a multitude of sins because it cannot really be falsified: the business, by definition, is whoever happens to be in the building. If you find yourself using this phrase - stop. Go outside, find yourself a cornfield, and play baseball.

What “for the business” generally means is that there is no specific person, no specific decision, no specific outcome the platform has been built to serve. There is no customer.

Marty Cagan has written an inspiring book: Inspired, which goes into detail about what, why, and how of technical products. The first point is: identify your customer, identify their needs. Then you build a prototype (an MVP) to see if their needs are met, before progressing further. The described continuous discovery and delivery process articulates real value without burning through a pile of cash just by making sure that you have customers and you’re meeting a need - having a captive audience is not the same as having customers.

Can data platforms be products?

Absolutely, and the more we think about our platforms as products with customers (with varying needs, desires, expectations, and capabilities) the better able we are to build something that will be used, adopted, and supported.

The test that tends to clarify things, is whether anyone — internal or external — would meaningfully spend something to keep the platform running tomorrow. Cash is the obvious currency. Headcount is another. Time. Political capital. Attention. If the answer is that nobody would spend anything, then what one has is not really a product but an expensive hobby.

The data mesh and platform engineering literatures have made this point at length, and they are correct, even if the language has gone stale around the edges. A product treats its users as customers. It has personas. It has a roadmap that gets prioritised against something other than the team’s own curiosity.

There are three questions that help prove that a platform is a product:

  • Who is this for?
  • What would they pay to stop doing something themselves?
  • What happens to us if they stop using it?

These are commercial questions. If the answers are vague — “the business,” “various things,” “they would be inconvenienced” — what you have is a beautiful capability surface in search of a use case. He will not come. He was never going to come. He has, in fact, gone to a competing platform that took the trouble to ask him what he wanted.

The way forward is not glamorous. It is naming customers. It is asking what they would pay you to stop doing sdomething themselves. It is killing features that have no customer, even the ones you are proud of. It is replacing “we are building this for the business” with “we are building this so that [named human] can [specific outcome] without [specific friction].” If you hear “built it, they will come” ignore it - the voice in the cornfield was probably just the wind.

If you build it, they will not come. They will come if you find out where they are, ask them what they need, and build that — which is, admittedly, a much worse film but a far better product strategy.​​​​​​​​

Ust