Let me save you some time and money before you create your next Analytics product:
Your users just want an Excel spreadsheet.
And if I’m being completely honest, they really just want an API.
Lemme tell you a story:
A long time ago on a project far, far away, another developer and I were “awarded” the roles of building the initial offering for our Brand New Product Direction. It was to be the Future of Our Company.
Even better! Our Brand New Product Direction had actually “existed” for about a year. Although we were a small company providing a suite of web-based tools, this “product” was completely handled offline through Sales and Service. It was a fully vetted idea and was already making quite a bit of money before we decided to throw more resources behind it. Eric Ries would have been proud.
Herein lies the true story of how an entire product line was killed, but the analytics tool we built still lives today.
As the “product” had already existed for quite some time, we had a plethora of user feedback and real world use cases that needed to be solved. The product should enable our clients to:
What would you start with first?
If you asked, “Well... what provides the most value?” then kiss me on the mouth and send me an email. Seriously, you’re amazing! I’d love to hear from you (my email’s at the bottom).
Well, our clients were already creating and managing content themselves. It was a bit cumbersome, and something we’d eventually automate, but they were really lacking on Analytics.
Let’s build a UI!!
Wait, but what are our customers actually asking for?
“A UI would be great. You mean I’d actually be able to concisely see all of my various metrics in one place? And it would be visually stunning? Nice. Thank you!! We’ve been wanting a way to see this data more frequently... Could I have a way to export all of my data?”
“Now why the fuck would you want to do that? I created this award winning dashboard with drag and drops and transitions and a single page interface and …”
“But I need to combine it with my sales data”
So that’s where we started. A data export feature that delivered our analytics data daily to our clients via email and CSV’s. There was no UI.
It launched. Clients loved it. I got a promotion.
The product never got more engineering resources, the company changed focus, and the Brand New Product Direction was no longer the Future of Our Company. The market shifted… something better came along... or politics. Whatever. No big deal. These things happen.
However, since the analytics tool had already been built, and this “product” was already quite profitable, we decided to keep a small team of Sales and Service running it. Our tool provided them a ton of value with very little overhead. Our CSV approach worked! Had we spent time building more infrastructure and creating a web-based UI, the product never would have launched and the entire division would have been shut down.
Note: This post wasn’t actually intended to be an example of a Lean Startup approach gone right, but today you get a two-fer.
Don’t be scared to do a bit more digging and build only what needs to be built.
Sometimes that means a little more upfront planning, but vetting an idea and really getting to know the customer and their problems can remove a lot of waste. Having engineers that aren’t overly eager to “Just Write Code” helps. Or sometimes, screw it. Just build what you want and hope the world catches up.
Now let’s focus on what our users said, “can we export the data?" That’s a very vital point. Users just want their data in any form you can get it to them. CSV’s are acceptable, and if your customers are large enough (read: “Enterprise”), then they really just an API.
Why? Because they have a plethora of other data they want to combine it with. There’s just some data they’re never going to give you. They need to do their own manipulations and calculations, so enabling this for them is a Good Thing.
Still not convinced? Good neither am I. All I see is a braggish developer tooting his own horn about how he executed something so obviously simple.
Oooo, such directness. I like it! First of all, it wasn’t all that simple to see that we just needed a CSV. Blogs appreciate brevity, so you got the quick version. Second, I agree.
Lemme ask you a question: For your product, who’s your target audience?
Well what value do they provide if everyone can see the same data? If your tool provides a UI with the same metrics for all customers, then why does the client need the agency? The agency needs to perform their own proprietary analysis, so that they can provide more value to their clients. You want to facilitate this.
They’ll either be sophisticated enough, or think they’re sophisticated enough, to do even more of their own analysis. Hell, they may even create a team to sift through that data, as well as form an internal development team to integrate all of their metrics from all of their sources into one place.
Better yet, if you want to make real money, create a shitty, incomprehensible UI, then sell training on how to use your product. It’s a potential for up-sells, has a high switching cost, vendor lock-in, etc. As your product moves up the ranks towards these inevitable “Enterprise” customers, it's what they’ll expect anyway.
Mom and Pops?
They just want to “put it in Excel.”
Ah, that’s not entirely true. A nice web UI would have the most impact here. Smaller market size though. However, there’s still a nice business to be had serving these customers. You’ll definitely need Customer Service.
This post was not meant to downplay the importance of providing your own Analytics. That’s one of the reasons your customers are using your service in the first place. You’re the expert. Half of your Value Add is showing them what metrics matter most. Just give them a way to analyze it further.
As for the aforementioned CSV product, we had a quite sophisticated set of clients using our product. Most of our clients were larger mid-tier and enterprise companies and agencies.
But you wanna know the real kicker to the story?
In over two years, not a single client, has ever once asked for a web interface.