I had an interesting conversation recently. It was something of a role reversal; the product person came at it from a data perspective, and I came at it from a product perspective. We were trying to figure out the roadmap – what features we could build, what features we should build, and their priority.

I produced a useful metaphor as part of this, but let's talk about the issue first. When you're developing a product or service, you should start at the front. What is the service? How will people interact with it? Why are people paying you for it¹? How does it fit in with your existing/future services? You need this in a little more detail than an elevator pitch, but not to the level of a specification for external developers.

Once you've got this planning done you can figure out how to build it. That's the point to start thinking about the data you'll need to execute your plans – not before.

My conversation partner approached this from the other direction. "We're going to need data from our users for whatever we build," he thought, "And data is going to drive the business. Let's start there. What data is easy to collect? What can we do with that?"

That's a valid starting point for brainstorming. It can help you think up enhancements and quick wins. But it's not a good way to design your core product². Chances are if it's easy, other people are already doing it. And even if it was really hard to collect or quantify certain data, if it's core to your business you'll have to figure out a way to capture it.

The data you collect & process is the crucial base for your product, but you don't start there. The metaphor:

If you're building a house, you'll need solid foundations. But you don't design the foundations first and then ask, "What can I build on top of this?"