Building a product—any product—is a complicated task. Between the design, the building of the product, and the launch there are many things that can go wrong. When you are building a data product (one that uses analytics to turn raw data into insights for your users) it gets even worse.
For most data product leaders, this is the first time they’ve built an analytic-based product. Everything the are doing is a new learning exercise and it’s on the clock and highly visible. As a result, many data product teams tend to focus on the most concrete tasks at hand—the technical tasks.

In my experience building data products over the last ten years, the technical parts of the project are rarely what will jeopardize success. Between the sophistication of today’s embedded analytic platforms and the implementation services offered by vendors, you’re pretty much covered when it comes to the technical side of things. It’s the non-technical stuff that’s going to be your downfall if you’re not careful.
Luckily, you’ve got someone to guide you around the potholes in the data product process. Someone who made a whole lot of mistakes themselves and who knows where to pay special attention. Me. I made many errors as I learned about data products by actually building them, but I made one great decision. I wrote down what I learned so that I could avoid making the same mistake twice.

Here’s what I learned so that you can avoid the five biggest mistakes of building a data product.

1. Failure to Get the Team Aligned Early

This seems pretty simple right? Of course the team is agrees on what should be built. Unfortunately this essential step in the process is often overlooked. Although the executive team agrees that analytics are needed in the product suite, the details never quite get resolved.

What are the essential elements without which the project won’t be a success? Does everyone get analytics or just new customers? Will the analytics be rolled out all at once, or over time? Will we build special features for customer who ask for more?

These questions can all be answered with a “product workshop” session but too often they go unanswered. Until it’s too late. These product-critical question always arise at some point during the development process and, if not answered early, they usually cause problems. They slow progress as the team stops and considers each issue when they come up piecemeal during development. Sometimes it’s a simple delay, other times the answers to these strategy questions result in rework and significant time lost. It’s better to take the time at the start of the project and ensure alignment before any implementation work begins. Hold a team alignment product workshop and get the team aligned.

2. Failure to Build for User Needs

Teams that build analytic products tend to be pretty smart folks. They have a deep understanding of their core product and the types of data available for the analytics. They often have a sense of how to display the information to best serve the customer. And this is what gets them into trouble.
Inexperienced product teams often start from a position of “what data do we have” to show our users and this results in a design that fails to serve user needs.

On a regular basis, I see analytic products that are the result of the “we’ve got lots of data, what charts can we make” approach to product design. As a result, these products can fall prey to the “engagement curve of death.”

In this chart of user engagement over time, there’s an early spike in
due to the “newness” of the analytics. Everyone loves new stuff. But slowly, the engagement sinks. And sinks, and sinks, and sinks until it approaches the zero line and little use occurs. Now you’re in the worst possible situation—no engagement (and therefore, no revenue) AND you are paying to support the platform. Ugh.

The best way to avoid the curve of death is to build to specific user needs. Start by identifying the 2-3 personas (detailed user profiles) that you expect to be primary customers for the first iteration of your product. Learn everything about this persona. If that persona is a inbound call rep, go observe an inbound call rep doing their job. Seriously. Get up and out of the building, find a rep, and watch what they do in the course of a day.{Get their permission first. Otherwise you’re just a creepy person with a notepad.} Map out the workflow steps they follow and what they can’t do easily due to the lack of analytics. These gaps determine what you build into your product. Every table, every chart you place on the page should correspond to a gap you found when you watched your persona doing her job. This process of matching gaps to analytics helps you break out of the “we’ve got the data, let’s show it” mentality that traps many teams.

3. Failure to Determine Your Pricing Strategy

Are you going to charge for your analytics? How much? What do customers get for that fee? Will you do custom work for an extra fee?
These issues will cause big headaches if not discussed and agreed upon early. I once worked with a team that worked hard to get product ready from a technical perspective but was delayed by six months as they decided on a pricing plan. They would had a half-year jump on the competition had they just worked out the pricing earlier in the project.
The best way to set your pricing is to follow these steps:

  1. Decide if you’ll charge customers
  2. Decide if you will have a single tier of analytics or multiple tiers with different capabilities
  3. Decide which features to place in each tier to give “basic” users a taste of the functionality, but to also entice them to buy an upgraded level of service
  4. Set the price so that it’s aligned with the functionality you offer and your core product pricing structure. If you’ve generated value by addressing the gaps your personas experience, this step is much easier.
  5. Decide the boundaries of your product. What will/won’t you do if a customer requests additional functionality.
    Treat these items as the equals to the actual development work. Just as you wouldn’t launch the data product without the dashboards being complete, you also don’t want to flip the switch without a good understanding of the pricing strategy.

4. Failure to Involve Key Stakeholder Groups Early

On a project several years ago, we’d spent weeks developing our data product, understanding pricing, and building the go-to-market plan. We were ready for launch day. Or so I thought. I had one last thing to do—meet with the Legal team. This meeting didn’t go quite as I planned. Rather than getting final “OK” on the product, I got an “explain everything about this product and why we’re doing it.” The lawyer wanted to understand the entire business case for the product, the market strategy, the use cases, the personas, and the pricing. In essence, he wanted to know the entire history of the project and why we made each decision the way we did. After this exhaustive and unanticipated review, I expected a final approval that would allow us to launch the product. Instead, the lawyer went on vacation and I had to meet with another lawyer and explain the whole thing again. This did not fall into the “enjoyable” category of project activities.

I learned—the hard way—that you need to get key stakeholders involved in the project in a timely manner. They need to know the details of the project early enough for you to make accommodation if they are necessary. I recommend including the following stakeholders in your kick-off meeting:

  1. Legal
  2. Sales
  3. Marketing
  4. Finance
  5. Operations
  6. Customer Support
  7. Engineering/Development
  8. Product Management
  9. Executive Sponsor

This is harder than it sounds. You think that you can invite these people and they’ll attend your kickoff but they won’t. They’ll assign a junior representative who can’t speak on behalf of the team or worse, they just won’t show up. People will tell you “don’t worry about it, we’ll catch them up later.” Don’t listen to these people. They lie. Get the critical stakeholders involved and in agreement early or you’ll end up reciting the history of the project and why key decisions were made many times for many people. Trust me, I know.

5. Failure to Plan Past the Launch

Building a data product is a journey and launch day isn’t the end. It’s not even a time to stop and rest. Often teams will treat data products like “fire and forget” revenue missiles. It’s launched, now we can kick back and relax as the revenue flows in! Wrong. Assume you’ll get lots wrong with your first product iteration, because you will. Assumptions you made about personas will be off. Gaps you thought were closed for users won’t be fully addressed and it’s inevitable that use cases you never imagined will arise. You need to be ready to respond to the these issues.

Plan process to monitor adoption and usage, to handle customer issues and requests, and build processes to respond. A best practice is to establish “trip wires” for your product. Pick metrics that measure engagement, issues reported, and other operation metrics and set goals for each. Set upper and lower limits that will indicate when something is wrong and resolution is required. For example, your goal might be less than 10 customer issues reported per week with an upper boundary of 15. If more than 15 issues get reported, something is wrong and action is needed. For each metric, decide who will do the monitoring, who will take action, and what actions might be taken (e.g. no more on-boarding until the issue is resolved). Planning in advance is far less stressful than trying to make critical decisions without guidelines when things are crashing down around you.

With metrics and feedback mechanisms in place, use the information you gather to inform the future roadmap of the product. Remember, building your data product is a journey not a destination.


While leading a team that is bringing a data product to market is a difficult challenge, it’s not impossible. Pick a good vendor and the technical aspects will work themselves out. Pay attention to the lessons I learned in my time building data products and the “non-technical” parts of the project will go smoothly as well. And, you’ll have fewer meetings with lawyers.