Follow Datanami:
December 19, 2018

3 Ways to Avoid the Analytics Death Curve

Kevin Smith


When you build an analytics-based application, what’s the worst thing that can happen? As a former product owner charged with using analytics to drive new revenue streams, I’ve considered this question many times. At first, I thought it was a failure to get the project done on time and on budget. Then, as I learned a bit more, I was concerned with technology selection and picking the right vendor. Later, my fears drifted toward scalability as I was certain the product would explode in popularity.

As I gained more experience in building analytical applications, I started to realize that these “problems” that I imagined were trivial concerns at best. The big problem was what I called the “analytic curve of death.”

The analytic curve of death is a shorthand description of the journey that many analytic product owners experience — especially the first time they build analytics for their users. Here’s how it works:

Phase 1:

In the initial phase of the journey, expectations and enthusiasm for the new analytical application and the use of insights to drive decision making are high. The product team sees the light at the end of the tunnel as they’ve gained an understanding of how analytics can provide valuable insights that will drive new revenues, reduce churn, improve customer support and so much more. The numerous use cases are on the whiteboard and people are excited about all the ways they can improve business processes. They can’t wait to get started.

Phase 2:

Enthusiasm and overall excitement for the project continue to explode during the second phase of the journey — vendor research. The project owner has done the research and brought vendors on site to perform demos, they’ve heard real-world examples of success, and are excited about the promises of the riches to be had by embedding analytics within their daily workflow.

Phase 3:

In this phase of an analytic project, team attitude reaches its zenith. A vendor has been selected, the technology has been implemented, and all that’s left to do is reap the promise of riches. Unfortunately, it’s usually downhill from here.

Phase 4:

Although there was an initial uptick in engagement and some new customers signed up as a result of the new analytical capabilities, the explosion in growth that was promised hasn’t materialized. In fact, overall engagement declines. Users who came to the analytical application because it was “shiny and new” aren’t coming back as they realize that their needs aren’t being met. Now, the team starts to realize something is wrong, that these analytics won’t be a panacea for all that ails them.

Phase 5:

During the fifth and final phase of many analytic projects, everything starts to come apart. The explosion and growth promised and anticipated when thinking through the business case, never materialized. The new revenue streams haven’t materialized. Engagement hasn’t increased as was expected. And there’s no change in customer satisfaction or customer churn. Now the team is faced with a difficult decision. There are just enough users of the analytics to warrant keeping the functionality up and running, basic maintenance if you will, but not enough new revenue to make the project self-sustaining let alone fund further development. What was supposed to drive revenue has instead become a cost center. You’re now spending money to maintain those analytics that are failing to deliver the promised results to your customers.

But avoiding the analytic curve of death is not only possible, it’s easy. All it requires is a little planning before you start building out your data-driven application. Here are a few tips that can help you avoid the curve.

1. Answer the business problem

It’s not uncommon to see analytics that are simply replicas of the way reporting was performed in the past: a dashboard is a collection of the MS Excel spreadsheets that were sent out via email, the mobile analytics are tables of rows and columns just like those spreadsheets. ‘Webifying’ those spreadsheets won’t satisfy your users. Getting the same information they used to receive, just on a different platform, does nothing. And, they certainly won’t pay for that type of “insight” into their business. Instead, make a complete break from the past, throw away the spreadsheets, and start from scratch. What are the steps that the user follows to make decisions? What does their daily workflow look like?  Using your expertise as the builder of these analytics, you can create a workflow that allows them to answer questions, to solve their business

(By SFIO CRACHO/Shutterstock)

problems, or improve efficiencies, perhaps without them even realizing analytics are involved, because it’s all built into the way they currently work. Using an analytical workflow is more powerful and more engaging than replicating the spreadsheets of the past on a web page.

2. Focus on the personas and their needs

Don’t just focus on technology. That often turns into a feature and function bake-off instead of analyzing the core business issues at hand. The best way to avoid the curve of death is to focus on personas and needs, rather than the technology being implemented. As technologists, it’s easy to get caught up in all the new functionality that’s being implemented, to focus on the elegance of the solution rather than the problem being solved. While users might be attracted initially to an amazing feature, ultimately, features aren’t what keeps them using the analytical application. What ensures engagement, what keeps users returning (and makes them willing to pay for the analytics), is the degree to which you solve their problems in an easy to use environment. Focus on the pain or business problem experienced by a specific persona and design analytics to meet their needs Understand the workflow a user follows and where they struggle. Then, address those needs. In the end, solving pain, not beautiful technology, keeps users engaged.

3. Start small and build on success

Finally, you can avoid encountering the curve of death by starting small and building from lessons learned. Too often, teams are reluctant to release an analytical application until everything — all metrics, all data, all personas — is 100% complete. They think that releasing a partial solution will result in users being turned off by the lack of completeness. In fact, trying to deliver all functionality at once is a major cause of the curve of death. The product team gambles, rolls the dice, guessing that they know exactly what will engage the users. Sometimes they are right but often they missed the mark. It’s a better idea to build a little, learn what worked, what users still need, then build some more. It allows you to incorporate feedback from customers and avoid the death curve both for each individual functionality release and for the product as a whole.

The analytics curve of death is real, it’s a problem, and it appears all too frequently. Luckily, it’s easily avoided with planning: understanding the business problems or business processes you are trying to impact, understanding your users and their workflows, starting small, and constantly building on previous success.

About the author: Kevin Smith is Vice President of Product Marketing for GoodData. Prior to GoodData, Kevin was responsible for delivering consulting services such as analytic product strategy, data monetization, and go-to-market services at NextWave Business Intelligence. He is the author of numerous ebooks, articles, and webinars on embedded analytics and building data products. In addition to NextWave, Kevin has held leadership positions heading analytics teams, designing SaaS products, and performance and managing product teams for both small start-ups and Fortune 500 companies such as SAP, ServiceSource, and Qwest Communications. Kevin holds a B.S. in Finance, as well as an M.B.A. in Quality/Process Management, both from the University of Maryland, College Park.

Related Items:

Attention to Small Details a Key to Big Data Success

Practical Tips for Success with Machine Learning