Data Product MVPs: Make Sure the Problem You're Solving Is Worth It

“I think we’re about ready to share this set of dashboards. The team has spent a few months getting them ready and made sure everything works really well.”

[2 months go by]

“It doesn’t make sense. The dashboards and metrics seemingly covered everything product would need, in addition to meeting a bunch of finance requests. Why is no one talking about it or using it?”

[another month goes by]

“This other team built a hacked together view of the data and suddenly it is all that finance can talk about. It keeps showing up in conversations and it doesn’t do much of anything other than the finance metrics.”

Pretty frustrating, right? If you work with data, you either have been or will be in this situation at some point in your career. It reminds me of a Twitter thread I read earlier this week (and cannot find right now) that talked about a startup that spent 18 months designing the perfect product with no customers. It flopped. In their next startup, they got one customer interested, put together an MVP over the weekend, and that customer helped them iterate into a hugely popular product.

That thread got me thinking - with highly skilled and thoughtful people working on hard data problems, we are prone to perfecting things before they go out the door. The dashboard, the metric, the model - they all need to be “great” before making their way to the public (or the company). That’s the story we tell ourselves. But its almost never true.

This week, I’ve talked to a few people who reminded me that some of the best ideas are those that are spun up over the weekend and then iterated on in the coming months and years. The key, as the best product managers I know always remind me of, is to know exactly what the problem is, and design as simple and basic of a solution as you can, adding to and improving on it over time based on user feedback.

So, as you think about launching that data product, here are 5 key things to consider (amongst a huge potential list):

1. What is the problem? For whom is it a problem? Let’s face it, with the variety of data solutions and products that could be created, we’d need 1000 data scientists and engineers to build them at each company. Instead, we need filters. The most important filter is “is this product I’m creating actually solving a problem?” Rather than having this discussion in your head or with others who think exactly like you, schedule conversations. Read about previous projects or outcomes. It is really important that you have people who are willing to “invest” in the problem that you see. It doesn’t mean everyone has to care about it, but you need a “problem champion” to say “yes, this is worth it.”

2. Move quickly, and hack it (to start). As you get moving into designing a data product, it is tempting to compare the data product you are building to really mature, highly-used data products across the organization (or likely even at other companies). In the experimentation space, it is common to hear comparisons to how other companies have solved the problem or how amazing their solution is. Yet that doesn’t solve the problem for us that exists in that moment. You aren’t building a mature product. You are building a first iteration of a solution. The term “MVP” gets tossed around a lot. It means get to the barebones solution that solves the problem at hand.

3. Subsequent iterations of the data product should have “investors”. Most of us are not building third party solutions that we are selling to enterprises or consumers, but that shouldn’t stop you from thinking about who is going to invest in your work. The upside is that you aren’t asking for a 100M dollar seed round (though somehow, those seem fairly common these days), but you are asking others to support and acknowledge why they believe your product is worth the time and impact. In some cases, this might be finance and product. In others, it could be fellow data scientists. But don’t be too proud to go find internal advocates and investors. Its good for your visibility and its good for a reality check.

4. Identify the point of diminishing returns on development and be willing to move to maintenance mode. Most data products could be better. They could be better designed, faster, more reliable and get more positive feedback from end users. But everyone has constrained resources. At some point, the effort to make something better will not provide the returns it once did. Two weeks focused on a data product early on could potentially be transformational. Two weeks focused on a data product a year into development might be tweaking a single, small feature without clear impact to anyone. While there’s not always a clear demarcation point, it is important to ask the question “is it still worth development?”

5. How do others find my product? One of the most frustrating experiences within a company is to have a good product that no one knows about. Have you ever stumbled across a dashboard that did exactly what you needed? Or a metric that measured user behavior with the nuances that a particular product team wanted? Its great, but also frustrating. No matter how you think about the 4 questions above, you need to think about how you market your product and make it discoverable to those whom it could benefit. This is probably the part of the job that I find data professionals hate the most. “I’m not a marketer, I don’t want to pander to people.” Building awareness of your product is not beneath any of us. If we are the builders, we also need to think about being the spokespeople for our work. This matters from MVP to fully mature data products.

---