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.
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.
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.
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.
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...