A conversation with Kevin Smith of NextWave Business Intelligence had me thinking about how project teams with whom we’ve worked have gotten stuck in data product “bear traps,” as Kevin calls them.
Getting stuck frustrates everyone, but it sounds like he has effective ways around them in this report he authored, “Embedded Analytics Bear Traps (and How to Avoid Them).”
The main tips he describes to assure success take a software company on the journey to building a data product for users while avoiding the traps that catch so many along the way.
Learn more about data products by reading “Embedded BI Bear Traps (and How to Avoid Them).”
Izenda: How would you distinguish a data product from a traditional BI solution?
Kevin: If you examine the origins of traditional business intelligence, it was designed to work inside the organization. These companies primarily used it for operations, sales and marketing. “Data products” differ by focusing more on customers rather than internally, and are often designed generate revenue for the company, add customers, increase engagement, or reduce churn. The focus is on driving revenue delivers insights to customers outside the company.
I: What’s a common problem software companies run into when they’re trying to add analytics to make their application into a data product?
K: Frequently what companies try to do is to “Excel-ify” their existing reports in a BI solution. They want to add analytics because it’s the new, hot thing. They take the 47 spreadsheets they send out each month and just recreate them in in some sort of dashboard. But existing customers look at those reports to see the same old content, just in a different format. It might look nice, but it’s not something they’re willing to pay extra for.
It sometimes shocks software companies when they realize new customers aren’t flocking to their data product and existing customers aren’t willing to pay an additional fee for these “Excel-fied” analytics. But it shouldn’t. It takes a different approach to create analytics that deliver additional results and insights.
I: What’s one of the better pieces of advice you can give to an executive who’s trying to create a data product?
K: I tell executives who are trying to create data products to focus on personas. Too many companies focus on what they have today, what data is available in their system, and that’s they deliver to customers. But that’s the wrong way to go about it.
Start with the personas and everything flows from that. Pick two or three key users, such as the CEO, product manager or front line user. Then figure out what each of those personas tries to achieve and what workflow is necessary to execute this mission. From there, determine what gaps or pain points exist that won’t allow the personals to achieve the mission. Your analytics are destined to close these gaps. That’s how you create your analytics. It’s a very different approach from the “here’s the data we have, therefore that’s what we deliver to you” model.
I: There are a lot of choices in the analytics market today, ranging from very simple to the very robust. What are some considerations that are paramount to you when deciding on a platform for data products?
K: I look at three things when evaluating vendors in context of building a data product:
First, I want easy embedding in a variety of ways. Some products are great used as a standalone platform but are hard to embed. Others seem fantastic embedded as an iframe into a tab as part of your product. The vendors tell you that iframes are sufficient, but having limited options forces you into a certain mode of offering your data product. What if you don’t want framed analytics? What if you want analytics to exist in situ, right alongside the workflow?
I look for the ability to embed analytics in a way that makes sense for the software company’s product workflow, rather than that of the vendor.
Secondly, I look for a robust product management ecosystem. This one really separates the wheat from the chaff.
Data products are more than just visuals—you need the ability to provision new tenants, add and remove users easily, and manage permissions and roles. When it comes time to update the application, you need the capability to perform automatic upgrades of all customer and tenant instances rather than do manual updates of a thousand instances. And if something goes wrong, rollbacks should be just as easy.
Lots of vendors haven’t thought about that, but without a full, robust management ecosystem in place, it’s easy to get in trouble.
Finally, I look for a good team. One that wants to partner with the software company and not just make a quick sale. Too many vendors don’t understand that building a data product is already a risk and that adding more risk in the form of exorbitant costs or slow responses to issues doesn’t help the situation. I look for teams that realize that if my product is successful, they’ll share in the rewards and therefore will do whatever it takes to help my data product succeed.
