Why data products fail

It is difficult to quantify how often data products fail, according to some popular figures, this ratio is between 80 and 90 percent. In this article, “Why data products fail," I have summarized some of the leading reasons why most industrial scale data or insights products fall short of expectations. Avoid these mistakes, and there is a good chance that the next product your team builds will be a hit.

Let’s first understand what a product is:

What is a product?

Google says, “an article or substance that is manufactured or refined for sale, i.e., food, agricultural, or software products." Unlike a project, which is a unique exercise, a product is something that can be repeatedly produced in the exact same way by applying tried and tested processes and best practices. In the world of data, this can be an API or a set of market insights, a self-serving reporting engine, transformation libraries or tools, predictive or forecasting models, machine learning algorithms, and AI wizardry. To keep the scope limited and focused, I will only talk about those that are built using data and not the products that enable this process, although it’s important that the key difference between a one-off piece of code or artifact and a product is well understood.

1. Solving the wrong problem

Top of my list is “solving the wrong problem” or an instance where the problem statement is not fully understood by the product team.

For a product to be successful, it must address a genuine need of its target audience; and, to return to the concept of product-market fit, there must be a sizable population of potential customers who share that concern. You won't achieve the momentum you need in the market by solving a problem that doesn't exist or that just a small percentage of people have. It’s imperative to understand the needs of the target audience. A key mistake which many product managers, data scientists, analysts or developers make is that they spend less time understanding the business problem and focus more on the way they can solve it. Stop right here!!!, take a step back, relax and read those meeting notes carefully, address any ambiguities, ask all the right questions, and make sure everyone understands what the solution will look like. Have a clear product road map and maximize stakeholder’s buy in on your plan.

2. The “Swiss army knife” pitfall

A common tendency within the development and engineering teams is that too often they try to solve multiple problems and get carried away by the sheer ambition to deliver above and beyond. Just scrap the idea, trust me it’s not worth it. Don’t let these wishful desires of doing more distract you from the delivery of basic commitments. There will always be that next iteration where you can get a chance to prove metal.

3. What Documentation?

In the realms of data, the developers, engineers, scientists, and analysts are all more interested in one thing than anything else: writing great pieces of code that can do wonders. They are rightly proud of their skills; I feel for them. Hundreds of times I have come across great artifacts in the form of SQL queries, code, excel reports, Tableau or Power BI insights, and super-efficient APIs, all of which solve the problems straightaway. All works well up until the moment when the customer says, “This looks great, but what do we mean by this certain KPI?” at which point, no one has the slightest clue of what has gone on under the hood.

Goodness!!! Product managers: don’t roll out a product until you have all the required end user and developer documentation in place. Make sure this documentation is easily accessible and readable, aka “written in non-technical and user-friendly manner." A product won’t get any kudos if it doesn’t make sense.

4. Talent drain

Finding exceptional data specialists is never simple. And the battle for talented data professionals is particularly intense. It's not simply about finding qualified talent. Organizations must discover the optimal mix of qualified talent. The days of the lone data analyst executing a whole data project on their own are long gone. Rather, comprehensive data products encompass conception, deployment, and detailed processes. To perform all these stages, you'll require a diverse array of responsibilities and keep them engaged

5. What the Creep

You come across it, you have cracked it and right before you put a date on the final deployment, the customer says, “You know what, before you deploy, can we just have this one small feature built into the product?” and you say, "Sure, why not, We are here to please." That's it; the never-ending cat and mouse game begins, and the deployment date will be pushed several times if at all. Do yourself a huge favor and instead say, “No, but we have made a note, and this will be added to the next version." Oh, and this is also called scope creep, just in case if you are wondering

6. Lack of engagement tracking

It’s important to keep track of how customers are engaging with your data products. This is valuable insight that can help in many ways, such as identifying issues, trends and staying on top of customer needs. Most data products don’t come with a way to track usage data, leaving the product teams in dark. If time and $$ allows, do bake this feature in your data products, it’s totally worth it

7. Salesperson dilemma

Overselling is typical of most products; in fact, we are bombarded with this most of our screen time. So, there's nothing unusual about it when the sales team overpromises features or customizations that can be delivered in the next data product, right? No, not at all.

Sales teams have less to do with development teams, and unless someone bridges this gap, (I truly wish), most think that making small customizations here and there in the data product would not be a big deal. Product managers, this is on you; stick to the course and don’t create problems for the dev teams. Make friends with the salesperson and tell them what can or cannot be done right away.

8. Product Fatigue

You build a successful product, you deploy it, the customer is happy, your organization is happy, and everyone starts living “happily ever after." A few good years pass, and you wonder why no one has contacted the organization about this product, Worse, you hear people gossiping about the customer leaving for a competitor, and you start thinking about what could have gone wrong. The reason is quite a simple cliché. No new features and a lack of innovation meant that there was nothing new your product had to offer, while in the meantime, competitors caught up and built a modern, feature rich product. One advice, keep innovating and keep it fresh

9. Stakeholders Ghosting

When an idea is new, it appeals to many. Most of the organization's stakeholders would put their weight behind it, and people would join hands to make things happen. Time passes, a new idea comes along, and the same people who were at each other’s throats over certain features "only figuratively” would jump off the wagon. More time passes and it’s hard to get anyone’s attention, this is where product managers must raise the alarm.

10: No support?

Once a data product is successfully deployed or sold, the most important thing is to listen to the users and be available to address any concerns 24/7. Even if for any reason the problems can’t be addressed immediately, keep communication open. Lack of a direct support channel or sloppy turn-around times will push the customer away big time

I am sure there can be plenty more reasons; these are just the ones I came across and thought would be worth sharing. Please provide feedback, or if you have any suggestions for how to improve this post. Follow me on twitter @ibilalahmed