NextWave Insight
Best Practices for Creating Great Data Products
NextWave Insight
Best Practices for Creating Great Data Products
I've had several conversations lately where, at some point, I get the question "which vendors provide data product capabilities?" It only took me hearing this question 5 or 6 times before I thought that perhaps I should create a list of embedded analytic providers.
My hope is that this will provide a good starting point for product leaders trying to select a vendor for their analytic application.
Note: this isn't a list of recommended vendors or platforms, it's just... a list. If I've left out a vendor that you feel should be included, please let me know.
When you look at the analytic landscape, it becomes apparent that most platforms are either directly focused on enterprise analytics or are derived from platforms intended for use inside a businesses walls.
It’s rare to find a platform that works both for internal analytics and for data product teams. Looker is that rare platform that, while initially focused on internal use cases is an excellent choice for those seeking to build data products with embedded analytics.
Looker’s cloud-based approach offering fast, flexible, and powerful analytics allow data product teams to focus on creating value for their customers rather than on the care and feeding of analytical systems.
Data products are different from enterprise analytics, and as a result, product owners need to seek out slightly different functionality when selecting a platform on which to base their data-driven functionality.
Beyond the data loading and visual analytic requirements, product teams need:
Building a data product can be a real nightmare for a product leader.
An actual nightmare as in, it can keep you up at night working about all of the things that can go wrong.
Will it function in an embedded environment? Will it scale to thousands of customer tenants? Will it make life difficult when I need to rollout a new version? Will the vendor “pivot” and stop focusing on data products?
If you are building an application with customer-facing embedded analytics and you value your sleep, you need to make the right choice when you pick a platform.
I’d like to introduce you to Izenda—a platform purpose-built for embedded analytics backed by a team that understands what it means to make analytic-powered applications successful.
Often analytics fall into one of two camps: either you’ve got powerful functionality that can serve the needs of the data scientists inside your business, or you can have flexible, user-friendly analytics that are suitable for use by customers as part of a data product.
The “analyst” oriented tools are extremely powerful, but they require expert knowledge of databases, data modeling, and languages like SQL, R, and Python. The “customer” oriented platforms look great and are easy to use, but often lack the capabilities to perform the sophisticated analysis required by analysts (or many power users).
The use cases just don’t overlap—you’d never use one product for both of those scenarios. Or would you?
What if you built a data product and no one came? What if you spend months evaluating vendors, connecting to data sources, designing beautiful dashboards and no revenue was generated? If your customer-facing analytical application became a cost center rather than a tool to drive customer engagement and revenue? It's not a far-out scenario — it happens, and it happens frequently. And it happened to me.
Being a product owner is a little like being a parachute packer… Nobody pats you on the back and congratulates you for each successfully completed task. People only seem notice when you get it wrong—and then, they really notice.
One of the first tasks faced by product owners building a data product (analytical functionality embedded in a core product) is to decide: should we buy it or build it?
Recently, I’ve been frustrated with some of the articles I’ve read about building great analytics dashboards. Their titles often led me to believe that they contained must-have insights about creating dashboards that engage users, but in the end, most are about use of color, pretty charts, and the latest feature a particular vendor has launched. And in my experience as a data product builder, these things aren’t what will make your embedded analytics product a success.
Today analytics powerhouse Tableau announced Adam Selipsky as its new CEO and president. My thoughts.
Not too many years ago, I was charged with building my first analytics-based product for the company I had just joined. I wrote user stories, worked with Engineers and interaction designers, and visited users. I did everything right.
Except I didn’t.
It's the nightmare that keeps analytics leaders up at night:
Our analytics—the ones we spent so much time and money on—the analytics that were supposed to generate new revenue and new customers, are failing.
Whether you are building a customer-facing data product or implementing analytics inside your organization for internal use, the fact is that some analytics projects do fail. But when they fail, they almost never fail the way you think they're going to...
As a data product builder — someone building customer-facing analytics that to will be part of a product — the needs are no different but achieving agility can be a real challenge. Oh sure, every analytics platform provider you might consider claims that they can connect to any data, anywhere, but this leaves a lot of wiggle room. Can you really connect to anything? How easy is it? How hard is it to change later? What about [insert new technology on the horizon here] that I just heard about? If you want to build an agile data product, you've got a tough road ahead... as I found out.
It's one of the most important decisions you can make when adding analytical capabilities into a product. And, unfortunately, it's an easy one to get wrong. What platform should you choose? There are a hundred options these days—each claiming to have what you need. How do you decide? Here are three tips...
Before you start evaluating features or selecting vendors, you need to get a handle on what YOU mean when you ask for analytics in your product. Although it seems simple, it really isn't so straightforward. There are many ways to "embed" analytics in a product and the method you choose can create limitations for your product roadmap and determine the overall user experience for your customers.
A great place to start is by understanding the "Three Faces of Embedded Analytics". It's a great starting point because this simple concept is directly tied to defining the underlying data you'll need to access and to the ways you might offer your data product to users. Get it wrong and you can end overlooking some valuable ways to generate revenue.
It happens every time. Every single time.
From the moment I meet a customer for that very first session, the clock is ticking. It might be seconds, it might be minutes, it might be hours—but it always happens. They always ask the same question: "how can I make money with my data?"
Back in the early 1990's, I created one of the first metric dashboards for the telecommunications company I had just joined to help improve business processes. My goal was simple: build a web-based dashboard that let management view charts showing the performance of key processes. Sounds pretty simple, right? Today it would be, but 20 years ago creating "business intelligence dashboards" was a convoluted process at best.
Here's what the workflow looked like back then. First, I created the intranet site that would serve as the holder for the dashboard charts. It was pure Microsoft FrontPage with a black background, animated GIFs, and crazy colors...
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.