It's one of the most important decisions you can make when adding analytical capabilities to 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?
Picture the scene: You are a product manager at a company with a successful SaaS application. Your customers are happy, revenues are flowing in, and as a result your executive team is happy. Then it happens...
The CEO calls you in and gives you the "good" news: she wants to monetize the company's data into a new analytical product line. She lets you know that you'll be leading this project and your mission is to drive new sales, increase user engagement, and create a new revenue stream for the company.
She also informs you that you won't have the time or the engineering resources to build these capabilities in-house so you'll need to pick an analytics vendor. Get it implemented and get the product launched as soon as possible, but whatever you do, make sure you don't damage existing sales or reputation of the company's products.
When I was faced with this scenario for the first time, it was exciting but also pretty scary. I was excited at the idea of building a new product based on our data, but at the same time I had no idea where to begin. So I started by calling analytics vendors and asking questions about their products. I didn't know enough to ask the right questions, but at least I asked lots of them. Back then, I didn't understand how different "productized analytics"—analytics designed to be embedded in an application and displayed to customers—were from enterprise analytics used inside your own company. Dashboards are dashboards, right?
Since then I've created a few more analytics-based products myself and have been fortunate to work with many teams to help them formulate their own analytics strategies. Here are the top three lessons I've learned about what to look for when choosing an analytics vendor to help you build a successful embedded data product.
* * * * *
Tip #1: Seek out platforms with Focused Functionality
Although your first inclination might be to look to those vendors that have as many features as possible, this is a mistake. Look instead for a focused set of functionality.
Wait? What? You're saying that I should look for an embedded analytics platform with less functionality? Yes, yes I am. Here's why...
Some analytics providers have chosen to differentiate themselves based on the sheer volume of options they provide. Anything you mention in passing, they have a feature to address it. Sales meetings with these companies go like this:
YOU: Can you accommodate every known database technology?
THEM: Yes, of course we can!
YOU: What about R, Hadoop, MongoDB, and that Spark thingy?
YOU: We heard about in-memory. Can you do some of that?
THEM: It's included!
YOU: Can your system listen to my customer calls and tell me what I should do next? You know, text analytics?
THEM: Of course. We do it all!
It sounds great—they can do everything you need today and everything you might need way down the road. But there are two issues with the "we can do everything" platforms.
First, products that have every feature imaginable are often indicative of a product team that doesn't quite know what they want the application to be. It further indicates that they may not understand their customers' needs.
A great example is the super-popular Evernote application. Is it a note-taking app? A recipe box? A pen-based sketchpad? A business card organizer? The answer is yes. As Evernote struggled with the question "what do we want to be for our users?" they added feature after feature diluting the core value of the product until long-time subscribers (like me) started to complain and eventually began to churn away. This can become a real problem when you are using an analytics platform led by a confused product team as the engine for your data product. Will they change course? Decide that a feature upon which you relied is no longer important? It's a risk in using "don't know what I want to be so I'll add everything" platforms.
Second, business intelligence platforms that offer overwhelming feature sets often show stagnation in key areas. Big feature sets are tough to maintain.
As the volume of functionality increases, it becomes harder for the Product team to keep the functionality fresh and to keep in touch with customer issues that need to be addressed. The probability that the essential features that you require for a successful product fall at the top of the vendor's to-do list decreases as the total volume of features increases. Sure, there are examples out there of vendors that have huge capability sets and maintain them very well, but these are exceptions, not the rule.
Instead of seeking out a vendor that tries to do everything, take the opposite approach. Look for an embedded analytics provider with a highly focused feature set. Find one that specializes in helping businesses build data products, has the functionality required to support this mission, and will place those needs at the top of their product roadmap. For product creation, a platform with a focused feature set is almost always a better choice than one that tries to be all things to all customers.
Tip #2: Pick a partner, not a vendor
Pick an analytics company that acts like a partner in your product development efforts. This is more difficult than you might think because these days, every vendor claims to be a partner. They're all on your side, rooting for you to win, and want to win together. But being a true partner is more than just words. It means that when you run into problems, you'll get a team that cares and wants to help, rather than an account rep who sees the opportunity for an up-sell. It's almost guaranteed that, at some point, you'll run into issues where you need an analytics team that's committed to your success rather than maximizing their own quarterly sales funnel. Here are a few ways to see if your analytics provider really is a partner in your product's success:
They offer embedded product-oriented contract terms. A vendor will look to make a deal profitable from day one; a partner will understand that you are starting a new product and help to reduce overall project risk by creating accommodating deal terms. This isn't to say that you'll get the platform free of charge or that you'll have 180 days to pay the first bill. What this means is that a true partner will understand why you might be hesitant to sign a strict five-year deal for 10,000 users, paid up-front, and will work with you to structure a deal that makes sense for an embedded use case. Smaller up-front payments, quarterly payment terms, and ramped fees are all good signs that the provider is a partner and wants you to succeed.
They accommodate the unknowns. When you are starting a new product based on analytics, you don't know much about the future. It's hard to predict the number of customers, the amount of data, or the number of dashboards you'll need. A partner will allow some flexibility here, such as wide bands of usage or the ability to change elements of the architecture, before additional fees kick in.
- They don't price based strictly on user counts. One of the sure signs of a vendor is that they want to know the exact number of users that will be logging into your new product. While this makes sense for an enterprise buyer creating analytics inside a company (you know your total employee count), it's problematic for a product owner. It's unlikely that you'll know the exact count this early in the project and pricing based on user count acts as a disincentive to getting your product into widespread distribution. It creates a tension between putting the product in as many hands as possible and paying huge usage fees. Partners price based on factors that are controllable by product owners—like data volumes, data sources, customer instances, and advanced functionality. Vendors ask you to commit to a strict user count.
Tip #3: Find a provider that understands The Product Mindset
Imagine going to a fine restaurant. You sit down and decide that you're in the mood for a nice, juicy, well-prepared steak. You place your order with the waiter only to discover that the chef happens to be a vegan and has never actually eaten meat himself...
"But," the waiter exclaims, "he's really good at tofu-steak! He can easily apply this knowledge to your ribeye!" Hmmm... Maybe, but I'd go elsewhere.
This is exactly what many buyers do when they pick a vendor that's not expert in the creation of monetized analytics for customers. They select a vendor well-regarded for Marketing or Sales analytics and think that the knowledge from the internal use case will transfer to product creation. It doesn't. The needs of a team creating a product for customers is very different and you need to select a vendor accordingly. Weed out the vegan steakhouse chefs from the carnivores by asking the following:
- Can you give me examples of customers who have used your platform to build customer-facing products?
- What's the average revenue uplift they experience?
- What percentage of your product creating customers churn away after their term expires?
- How many customers does your average product creating company support? 10? 100? 1000? Can you scale?
- How long will it take to on-board each new customer who wants to use my data product?
- How do your customers price the analytics to their customers?
- What are your best practices for ensuring that the analytics we build drive customer engagement and new sales?
For the analytics vendors that live in the world of data products, these questions won't be a problem. They'll have thought about these concerns and have answers available. But for the companies that focus on enterprise analytics and only dip into the data product world on occasion, the questions will prove problematic. They'll name a few customers, but upon deeper questioning, you may find that any success was often due to the customer's own product team developing strategies without much support from the vendor. This might not be a problem for you—perhaps you've got a product team that fully understands analytic product development and doesn't need any assistance. But it's nice to know that if a non-technical strategy question arises, your embedded analytics provider is ready to help.
* * * * *
When I was building my first data product, I didn't know what to look for, which features were important, and what might be essential for our success. But I've learned a little since then, and more than any one feature or function it comes down to this: find a focused platform with features designed for product owners, make sure you've got a good partner, and choose a vendor that understands what it takes to make a great data product. It's still going to be a blend of scary and exciting, but picking the right platform will tip the odds in your direction.