Building customer-facing analytics for your application is about more than just the technology you select. in fact, it’s almost never the technology that causes data products to fail — it’s the business end of the process. Here’s a simple set of checklists to help you consider the business part of bringing a data product to market.
Checklist 1: What’s the Plan
Every project needs to start by examining the resources, timeline, goals and manpower needed in its planning phase.
☐ Has an executive sponsor been appointed? We find that successful projects don’t happen by chance, they have a champion guiding them through possible roadblocks.
☐ Is the project essential to revenue growth, customer retention, or market positioning? Analytics projects that tie directly to a key business goal are more likely to get the attention they deserve. Can you tie this project to a critical objective?
☐ Will this be considered a profit center for the business? Analytics— especially when embedded into your product— can serve as the basis for increased revenue when create analytics “tiers” for customers.
☐ Is the executive team in agreement that a data product should be? Have goals been set? Disagreement is a huge red flag. Make sure that, before the first connector is connected, you’re team has a shared definition of success.
☐ Has a timeline been set? Projects with no end date tend to languish forever. Set an ambitious but achievable target for completion (often <30 days for Toucan)
☐Is the timeline realistic given the goals? Is budget available? If you need to connect 1000 data sources across 100 regions, two days might not be a realistic project timeline. Plan realistically!
☐ Is the budget realistic given the project goals? Has a priority been set for the project? As with timeline, make sure that you’ve allocated budget where it will be required. If you DIDN’T choose Toucan, make sure you budgeted for connectors, user training, refactoring for mobile formats, and user management systems.
Checklist 2: Have you considered the logistics?
Once a plan is in place, the next step is to assign accountability, subtasks and metrics with which to measure the plan's success or failure.
☐ Has a project team been established? Make sure that you’ve got people from operations, support, IT, and even Legal involved early— it will save you headaches later!
☐ Has a chairperson or leader been selected? Are all stakeholder groups represented? We’re all for self-directed work teams, but here it makes sense to have a leader who can surface roadblocks and make sure they get resolved quickly.
☐ Do all members have decision-making authority? What’s the point of having the right representation on the team if they have to get every decision cleared by their management team? Make sure that your members can commit for their organizations.
☐ Has a process for tracking tasks and communicating status been implemented? Project Management 101— what gets tracked gets done. Don’t leave key tasks to chance.
☐ Have you defined the "table stakes" or "must-haves" for project success? What MUST you have (table stakes) and what are “nice to haves” (delighters) for your analytics? If you know these at the outset, it can ease decision-making should you need to prioritize.
☐ Have you defined the constraints or "off-limits" items for the project? As important as what you WILL do is what you WON’T do. Decide early what thing you won’t support (e.g. custom metrics for different customers, on-premises deployments, etc.)
☐ Have all executives approved the strategy? There a reason that, in the early days of space flight, they good around the room and make sure everyone gave a thumbs-up. Don’t wait until launch day to find out that Steve is Ops never really liked the idea of analytics.
☐ Do you have the resources to execute the strategy? Never send troops over the hill until you know you’ve got the rifles you’ll need for battle. The same is true here— make sure that, from technical resources to legal assistance, everyone is prepared to support the project.
☐ Have you set metrics and goals to track performance? It’s hard to declare success if it wasn’t defined at the outset. Set goals for revenue, engagement, adoption, and ROI prior to starting your analytics project.
Checklist 3: Data Readiness Basics
The data is the building block of analytics. So before diving into the implementation of an analytics solution, it is imperative to have the data clean and read.
☐ Have you defined a plan for data cleansing/preparation? How will you get data into the right format? With Toucan, you can either connect a pre-cleansed source (e.g. Snowflake) or use built-in tools for easy data prep. With others, you may need extra steps (and budget).
☐ Have you performed The “buy vs. build” analysis for data preparation needs? The temptation is always to say “we’ve got great engineers— let’s built it ourselves!” With analytics, this can be catastrophic. From filters to user management to version control, analytics require lots of things you might not have expected. Plan wisely!
☐ Have you evaluated data preparation vendors/platforms? If you’re NOT using Toucan, you’ll want to pick a data prep platform and budget for implementation, support, and maintenance. If you are using Toucan, well, it’s included so drive on!
☐ Have you evaluated the cost of the data preparation solution under
high/medium/low user growth scenarios? IF you brought a data prep platform (i.e. you decided not to use Toucan and its built-in YouPrep™ capabilities, you need to do a bit of planning. How much will your data prep cost if adoption explodes? If your data load triples? Good to know in advance.
☐ Have you evaluated the initial (year 1) cost of buying a data preparation solution? What’s it going to cost for year one of your data prep tool (hint: zero if you use Toucan)
☐ Have you evaluated the long-term (years 2-5) costs of buying a
data preparation solution? Sometimes things that look inexpensive end up quite pricey over the long term. Make sure you know what your costs of data prep will be post-year one. (hint: with Toucan, it’s zero. All of this “it’s include with Toucan” is getting boring, isn’t it?)
☐ Have you selected a vendor (if not building in-house)? Does the vendor make professional services available? If you’ve decided to pick a vendor that’s part of the “friction industrial complex”, you might a little help getting your analytics deployed. We’ve seen projects from other vendors where the implementation services were 2-3X the cost of the platform itself. Of course, this isn’t an issue if you pick Toucan— the natural enemy of data friction.
☐ Have you evaluated the support model offered by the data preparation vendor? Oh, wait? You have a question? That’s an extra 20% if you want a response. Make sure that whichever vendor you choose has a good (and cost-effective) support model.
Checklist 4: Analytics Technology— What’s the Plan?
With so many analytics technologies out there, evaluation and goal alignment are essential in pick the right solution provider. Understanding vendor services, capabilities and support could be the difference between analytical success or data friction.
☐ Have you evaluated analytics visualization vendors/platforms? At last count, there are hundreds of options for analytics, but a vast difference between your choices. Using a list like this one can help you quickly divide those vendors aligned with your needs from those that aren’t.
☐ Have you selected your preferred deployment model (cloud vs. on-premise)? Although these days many businesses opt for the scale and flexibility offered by cloud/SaaS deployments, there might be reasons you need on-premises analytics as well. Whatever you choose, make sure your analytics vendor not only supports but has a history with the option you need (hint: Toucan works with any cloud or on-premises)
☐ Will the technology scale in terms of customer instances (tenants)? We’re not naming names, but there are a few platforms out there that demo well, but quickly run into limitations when trying to scale to many customers or data sources (you know who you are...). Make sure that you won’t need expensive hardware or elaborate clustering schemes to support your analytics goals.
☐ Do you need real-time analytics? Some analytics are historical, based on stored data while some are real-time. Not everyone needs real-time, but if it’s a requirement for you— make sure the platform supports real-time analytics along with stored, historical analytics (hint: Toucan does both and can blend the two easily).
☐ Have you evaluated the initial (year 1) cost of buying an analytic platform? Like with data prep, sometime analytics priced too good to be true are, in fact, too good to be true. Expensive implementation services and mandatory training for users add up very quickly.
☐ Have you evaluated the long-term (year 2-5) costs of buying an analytic platform? Like with data prep, the post-year one costs can be radically different than the start-up costs. Make sure you understand the costs for years 2-5.
☐ Have you evaluated the cost of the data visualization solution under high/medium/low user growth scenarios? Spinners and “loading...” messages suck. Make sure that the vendor you select can handle your needs as you grow, both for concurrent users and for data sources.
☐ Have you evaluated the support model offered by the data visualization vendor? Extra fees for support are a nice way to pad revenues but make for a high-friction user experience. Know before you buy.
☐ Does the vendor make professional services available? If you need help, can the vendor provide support or will you need to contract with a 3rd party? Some vendors have an extensive network of partners, others? Well, not so much...
☐ Can/will the vendor provide project management services? Getting guidance through your projects, from planning to deployment and testing can be a huge time saver. See if your vendor offers project management services or if you’ll need to supply your own.
Checklist 5: Product Strategy
Understanding your analytical needs and aligning them to the product capabilities is essential in delivering a great product to your users while managing expectations. You do not want to over promise and under deliver in terms of functionalities or the timeline.
☐ Have you determined what functionality will be a "must-have" for the data product? Like the table-stakes and delights for the project goals back in Checklist 2, you’ll want to identify “must-haves” for your analytics. Is it essential that you can combine stream and store data (like you can with Toucan, ahem)? Is the ability to deploy to both desktop and mobile with no rework (like, um, with Toucan) a key? Make note of the must-haves.
☐ Have you determined the "nice to have" functionality for the data product? Likewise, what functionality would be nice, but isn’t essential? Check with the vendor to see if your long-term wants match with their product roadmap.
☐ Have you defined the "Minimum Viable Product" for launch? Planning on a 100% perfect analytics app at launch isn’t a great idea. The things you might have thought were critical can turn out to be not so essential while key elements were overlooked. Create an “MVP”—an analytics product that’s useful and functional but not the absolute perfect, complete, end-state version and iterate.
☐ Have you defined problem sets or requests that will be addressed by the core product? Sometimes analytics team build based off of old Excel spreadsheets or other reports and then are surprised to find that there’s little adoption of the new analytics platform. A better option is to outline the critical issues and problems to be answered by the analytics— the pain points. Use these findings as the starting point, not the traditional reports.
☐ Have you defined problem sets or requests that will be addressed through custom (paid)feature development? Often, teams will divide data product functionality into the “core” experience and an “add-on” experience. 12 months of sales data might be core, while 24 month is an add-on. Determine what you’ll offer as standard and then, what are the optional upsells you’ll offer customers.
☐ Have you defined problem sets or requests that will NOT be addressed by the core product, services, or through custom development? Conversely, what WON’T you offer? This can be a critical item to consider— especially when money is on the line. If you are selling sales analytics (based on Toucan, of course) and a prospect wants you to add in marketing analytics (or something else that’s not core to your product), will you do it? It’s good to know your boundaries before money muddies the waters.
☐ Have you planned for user permissions and roles? It’s never fun when people can see information that they shouldn’t and, these days, lapses like this can be a huge financial liability. Make sure that your vendor of choice (which is clearly Toucan) offers data, row, user, and role-level security and permissions. Extra bonus points if these permissions can be controlled programmatically (like here at Tou... well, you get the idea).
☐ Have you brainstormed a list of possible personas to be addressed? Analytics for all are analytics for no one. The dashboards required by C-suite executives are vastly different than those needed by front-line employees. Know for whom your building, separate the roles and the analytics, and prioritize based on impact.
☐ Do you understand the key personas that have the most leverage over the buying process (e.g., executives, high engagement users, champion users)? Not everyone will have the same impact on the process of buying your data product. You might have a line of business leader screaming for your app, and finance person involved in the process, and an IT person who doesn’t really care much as long it fits the technology strategy. Know your buying committee and make sure you can answer their key questions (which you can if you’ve been following this checklist).
☐ Have you selected 2-3 personas for the first phase of the data product? You might start with the C-level dashboards but quickly move to middle management. Or start with front-line employees and then jump to managers. Whichever you choose, make a plan and understand who gets what and when.
Checklist 6: The Engagement Model
What is the point of implementing an analytics solution if your users aren't going to continuously use it? The key to high engagement rates is understanding user pain points and their journey.
☐ Have you identified the "missions" or objectives for each persona within the data product? If you’re spending the time to build a data product, you want people to use it. Engagement is the key here and it all starts with mission. For the 2-3 person as you selected as the starting point, what are the big objectives? For example, for a Head of Sales the mission is to understand the sales pipeline and be able to project quarterly performance. Therefore, everything on this persona’s dashboard should orient toward that mission.
☐ Have you identified the workflow the persona follows to execute their mission? Once you know the mission, you need to understand how they go about (or would like to go about) achieving the mission. That Head of Sales might like to start by looking at overall performance, then by region, sales rep, and then see the top performers. Understand the workflow they follow, build the analytics to match this flow, and you’ll improve your engagement rate significantly.
☐ Have you identified the key pain points within each workflow to be solved for each of your selected personas? Why can’t they follow the workflow you identified? Is it lack of data? Complexity of analysis? Find the pains points, build analytics that fill in these gaps, and you’ve got yourself a winning data product.
☐ Have you defined the "triggers" that will draw the user to the product on a regular basis? Let’s face it— people get busy and forget to check the analytics from time to time. So build in “triggers”— alerts or notifications that inform user that hey, somethings is going on that you need to know about. Make sure the triggers are tied to the mission, workflows and pain points and engagement will soar.
☐ Have you structured the dashboards into a workflow to guide the user through the analytics? Nothing is worse than a dashboard that tries to tell YOU how to do YOUR work. You already know the mission and workflow— now ensure that the dashboard layout works WITH not against the way the persona works.
☐ Provide logical drill downs for analytics. Don’t frustrate user by limiting the information they can see. Provide easy to find drill paths (e.g. overall sales -> regional sales -> store sales) for users to keep them engaged.
☐ Have you created easy-to-understand explanations for each analytic? What exactly does “conversion rate” mean? Wouldn’t YOU like to know... Don’t keep your users guessing (sometimes erroneously) what charts, metrics, and data sources mean. Add in the definitions for these elements to eliminate confusion. Of course, if you use Toucan which provide context and definitions everywhere, your job will be a lot simpler, but hey— your call.
☐ Have you created a help system for the user? Make sure you’ve got a way for user to get assistance when they’re stuck. Some tools are pretty complex (not Toucan) and require extensive training (not Toucan) and users frequent need help (not Toucan). Make sure they can get the help when they need it.
Checklist 7: Pricing & Legal Readiness
Pricing in the B2B space is always tricky. You don't want to find yourself in a sticky situation where you are legally bound to pay hidden costs you weren't aware of or not get the upgrades you were hoping for.
☐ Will you be charging additional fees for your analytics?
There's a correct answer here and it’s “yes, we’ll be charging for our analytics.” If you followed all the steps in this checklist, you’ve created tremendous value for your users— and when you add value, you charge for it. If you’re struggling with the “should we charge” question, go back and make that you’re adding the value you planned.
☐ Ensure that your pricing fits your core model. If you charge for your “core product” based on users, charge for analytics the same way. If it’s based on transactions, likewise. Make the pricing of the data product match the core product.
☐ Is the pricing easy to understand? We’ve seen pricing based on the craziest stuff—from named users to connectors to made up things like “power units.” Keep it simple.
☐ Have you defined an upgrade path (tiers, levels, etc) for analytics buyers? Not all users have the same needs. Not all buyers want the same things. A good way to account for these differences is with product tiers, such as “basic,” “plus,” and “pro” analytics offerings. Create path for users so they can start simple with your basic offering (less data, simpler metrics, less customization) and then, when ready, purchase more powerful capabilities in the plus or pro-level tiers.
☐ Have you defined the specific features in each upgrade tier? If you include everything is the “basic” tier, well, you’ll never sell plus or pro. List all the possible ways you could enhance your analytics (e.g. more data, more storage, more customization, mobile, exporting, etc.) and then divide the features across the tiers you’ve selected. By considering this well, you’ll create tiers that satisfy initial needs while providing a powerful drive to buy the next tier when ready.
☐ Have you defined the implementation or setup pricing? Will you charge to set up a customer’s data product? How much? What’s included?
☐ Have you defined the professional services and customer-work pricing model? Just like your analytics vendor may offer services, you may decide that you’ll provide set up, management, or analysis services to your customers. Plan these offerings before launch— it’s easier than scrambling to design them once requested by users.
☐ Have you determined the subscription term and cancelation policies? Have pricing sheets been updated? How long does a subscription (if that’s your model) last? When can someone cancel? Things such as your breakeven price on set up will factor in heavily here and can significantly impact the profitability of your data product. Once determined, make sure your “core product’s” pricing sheet is updated to reflect the new analytics offering.
☐ Has the Legal team approved the business model? This is a big one... We’ve seen data product rollouts stopped in their track just before launch because the Legal team has concerns. Make sure that someone from Legal is part of the planning team and is involved early in the process.
☐ Has the Legal Team approved the new contract template? You’ll need to update your contracts to specify what customers can and cannot do with your data product. We’ve seen this go very badly when the limits aren’t clearly delimited (i.e. no, you can’t resell the “unlimited” data product your bought from us for 10X the price).
☐ Have you created or updated your contract template to account for analytics? Data product powered by a 3rd party will require that your customers acknowledge that there’s 3rd party processing going on. Make sure this is revealed and accounted for in your contracts.
☐ Have you developed a plan for re-signing existing customers to the new contract? If you’ve already got a bunch of customers and THEN add analytics— do the old customers all need new contracts? This is a great question for your new best friend, the Legal rep, mentioned earlier. Take them to lunch, get to know them... You’ll be spending lots of time together.
Checklist 8: Marketing & Operational Readiness
Investing in an analytics solution extends to your sales team. You need to know if they understand its features and would be able to explain the benefits to the users. Marketing efforts need to be coordinated around a similar messaging to drive home the point.
☐ 
Has the sales training been updated? It doesn’t matter HOW good your data product is if your team can’t sell it. Make sure that you train the sales team! Help them understand the new capabilities, how it differs from the competition, and how the product tiers work.
☐ Has the sales presentation/deck been updated? You probably have a sale “pitch” deck that you use to discuss your product with prospects. Well, now you need a section on the data product.
☐ Have marketing materials including webpages, brochures, presentations, logos, etc. been updated as needed? Along with the pitch deck, your web site product pages and all of your marketing materials — including things like comparison/evaluation sites— need to reflect your new data product.
☐ Have you created marketing campaigns and/collateral around the analytical capabilities? If you built your new data product using Toucan, it looks amazing and the competition is likely trembling at the thought of competing against you. Drive the stake in a little harder by creating marketing campaigns about your new analytical capabilities. If you didn’t use Toucan, well, maybe you can design a cool logo?
☐ Has the ordering process been defined? How prospect order the new analytics once they see your cool new marketing campaign about the offering? Can they activate themselves? Do they call their account manager?
☐ Has the change management process been defined? Has the provisioning/setup process been defined? What about the installation and change processes? Dos everyone know how to set up the analytics? If you picked one of those “friction-filled” analytics vendors like [REDACTED], you might need to have THEM perform steps in the process. Make sure everyone knows their role and expectations.
☐ Has the billing process been defined? How. Are. You. Going. To. Bill? Seems simple, but this can be a killer. We’ve seen companies price base on consumption— with no methods in place to track actual usage. This is a problem. However you’re billing, make sure that the Billing team is aware and the system are in place to make sure you’re invoicing for what buyers owe.
☐ Are systems in place to track utilization and overages? Has the decommissioning process been defined? If the buyer purchases the “2 data sources” package and then connects 10 data sources... what happens? Could you even tell if this occurred? Make sure you can track situations where the buyer exceeds the limitations of their purchase. And, make sure you’ve defined the process for turning off the analytics should they ever decide to leave.
☐ Has the issue management/trouble reporting process been defined? The time to find out that you don’t have a process for handling customer issues with analytics IS NOT when the first ticket rolls into support. Then everything is a mad scramble. Define the support process early— it may involve your analytics platform vendor for certain, high-level issues.
Checklist 9: The Launch
A full-scale analytics launch is often preceded by a beta test to see how well the product and the marketing resonate with your users.
☐ Have you defined the launch timeline? Big bang? Slow burn? How are you going to be rolling out your new data product to the world? Build a plan that encompasses when existing customers will be on-boarded, when the data product will be offered to new customers, and when an existing reporting will be decommissioned.
☐ Are you conducting a beta or limited launch? Have you selected beta customers? It’s always nice to find any problems BEFORE you deploy to your entire customer base. Hence, the beta launch. If you want to ensure that your analytics are as bug-free as possible prior to the big day, plan a smaller beta launch. Pick “friendly” customer that will give you feedback that can be used to get everything as perfect as possible before the main launch.
☐ Do you have a process to gather beta feedback? What’s the point of a beta if you don’t have a good way to gather feedback from testers. There are great tools out there, from Google Forms to WuFoo— pick one and get it in the hands of your testers.
☐ Is there time allocated to make changes that surfaced during beta testing? Have you defined the general rollout plan? A common issues is that, when a beta tester find that an analytic calculation is wrong or a data feed isn’t as expected, there just isn’t enough time to make the fix before the scheduled launch date. Make sure you’ve allocated plenty of bug-fix time between the beta and the launch.
☐ Have you created the messaging for customers who will be receiving the analytics? How are you telling existing customers about your new data product? Email? In-app notifications? Account manager calls? Plan a strategy that allows you to inform every customer of the pending changes (and generate a bit of excitement) and make sure that no one fall through the cracks.
☐ Have you prepared training and training materials for the customer base? No matter how easy the analytics (Toucan) or how complex (everyone else), customers will likely need some training. They’ll want to know about new capabilities, new data sources, and everything else they’ve been begging for from your analytics. Create a plan— webinars or video— to get your users up-to-speed.
☐ Do you have a roadmap for functionality development beyond launch day? As soon as you roll out new data functionality the questions will come— what’s next? You need an answer. Especially if you’ve followed the “minimum viable product” approach so that you can learn what customers find most useful. Have a basic roadmap so you can share your priorities and, get feedback on what’s next.
☐ Have you defined an issue management process? Have you defined a change management process? No matter how awesome your data product, you have issues at some point. Make sure you’ve got a process to handle systemic problems and feed the intelligence back to your product team.
---
☐ Have you called Toucan to help with your embedded analytics data product? What? Are you kidding? You’ve made it THIS FAR and you’ve still not contacted us? We’re the experts in friction-free embedded analytics for companies from big to small. Lots of data to spreadsheets only. Cloud or on-premises. We’re not in the business of complicated, we’re in the business of making insights from data easy.
