Product Usage Data Strategy (A Nerd’s View)

“We have data gaps preventing us from knowing what our customers are doing. We have some manual workarounds, but we are flying pretty blind.” 

I hear this all the time. I’ve dealt with it at every startup I’ve ever worked and almost every one I’ve consulted with. 

In this post, I want to share the learnings I’ve experienced on how to build an adequate plan and set realistic expectations. Because each setup is unique and can vary so much, I must keep this high level and share the aspects applicable to almost everyone.

Note: “Data strategy” can refer to an awful lot of topics. This article is centered on taking product usage data about our customers and creating a richer, more inviting experience for them.

Real-world example

This was a very big deal at my last company, where it took us several years to connect the data from our internal systems into our GTM tooling. For more information, see the public handbook page. As you look at the graphic, you realize how complex the entire system can become. It took us 18 months just to get accurate license utilization data into Salesforce and Gainsight! There were a lot of components involved, and one of the biggest obstacles at the time was support for both SaaS and on-premises customers. Any additional requirement that you add will amplify the complexity of the overall project.

 (link to page)

The negative results from the audacious amount of internal systems work caused:

  1. 18 months to ship basic license utilization (peeling back the onion of problems)
  2. Delayed true customer usage data
  3. Lack of insights for our on-premises customers
  4. Executives unable to use data to grow and retain customers like they were told/imagined

Contributing factors to these results stemmed from:

  1. Lack of internal alignment/agreement on this being a priority. Getting an exec sponsor was a game-changer!
  2. Jumped right in instead of assessing the true data needs. With the Data Team’s help, we began peeling back the onion
  3. Did not set up clear exit criteria. This led to a project that just “kept going” and dragged on
  4. We lacked a Product expert who could advise on what the data fields were, how they were ingested, and the specific definitions; we later got an AMAZING partner
  5. Build vs buy: many of the metrics were built years before us by people no longer there. That required a lot of code review to understand how data flowed, what each field represented, and how they were intended to use
  6. Poor documentation: as you can guess, in SaaS with high employee turnover, documentation isn’t a nice-to-have but a necessity. The lack of documentation easily put us behind 9-12 months

Critical steps

There are several key opportunities and risks every company faces with their product usage data design:

  1. Systems
  2. Integrations/pipelines
  3. Data labeling
  4. Data mapping
  5. Using the data
  6. Evaluating the data
  7. Data quality
  8. Feedback loop
  9. Company alignment
  10. Proposal for the next phase

With this in mind, it’s easier to visualize why so many companies struggle — it is not as simple as “let’s run a hackathon to break through.” It is more deeply involved than we expect or want. To launch something with spectacular depth and capability requires intense thought, elbow grease, determination, and time. Coffee, too.

When crafting your product usage strategy, keep this framework and tips in mind:

Framework

  1. Define the why: What do you want the data for? What does “great” look like? Bonus: what does “good enough for now” look like?
  2. Success criteria: Define the criteria for when you’re complete. This is also called “exit criteria” and is needed to avoid scope creep, orient the team toward their goal, and rally momentum
  3. Dependencies: What are you dependent upon to make this a success? This includes teams (IT, RevOps, exec alignment) and systems/tools (“we need access to…” or “we need to procure…”)
  4. Resources needed: What’s needed to make this project a success? Do you need software, people, contractors…?
  5. Executive sponsor: You will need a sponsor at the executive level to break through barriers, alignment issues, and help you gain resources where and when needed
  6. Alignment: Do you have alignment with stakeholders, the exec sponsor, the project team, and others?
  7. Communication: Ensure frequent and visible communication outward to stakeholders, and also feedback back to the project team

For example, you may say:

  1. Why: To develop a robust churn prediction score to alert the AE/CSM two quarters in advance of churn risk. V1 is to flag potential risks for the next quarter.
  2. Success criteria: When we have a system that has been tested and vetted by the CSM/AE org and has final signoff by our executive sponsor
  3. Dependencies: We require support from IT for ______, Product to develop _______ (new metrics), and Data Engineers to pipe data into XYZ system
  4. Resources needed: XYZ tool to analyze and develop correlations between past churned customers and their usage, a RevOps analyst to own this project, and ….
  5. Executive sponsor: our VP CS will be our exec sponsor
  6. Alignment: We have alignment between Product and CS. We are working with IT to allocate a percentage of their capacity to this project during the next two quarters
  7. Communication: We will update the exec sponsor weekly, post a monthly progress update in Slack, and have a slide for the pre-read material for the board deck

Tips

  1. Keep your executive sponsor apprised of progress. This includes weekly or bi-weekly check-ins, and monthly written updates (short and succinct!)
  2. Have the full picture in mind, yet find ways to deliver value today. What does a quick win look like? Could it be showing license utilization? Perhaps a new metric was added that you can showcase? Or an anecdotal story of how an AE used data to grow an account
  3. If you don’t have a dedicated program manager, this will likely require a MINIMUM of 10 hours of your week. Pursue this project only if you have the capacity to commit to it; it’s not a “set it and forget it” program
  4. Play the long game. A successful product usage strategy is not developed and delivered overnight. Deliver early wins yes, but have your eye on what “great” looks like years from now
  5. Leverage your exec stakeholder! Bring them into conversations, roadblocks, concerns, and victories! Ask them for help with alignment and/or resources

Where do I go from here?

It’s daunting. Take one bite at a time. It’s easy to say and hard to do, but take a full uninterrupted morning* to draft the initial plan. The goal is to make it imperfect, but that’s why it’s called a draft. So start with what you want: with your “why” and success criteria. From there, you can choose to work on it a little bit each week or block another morning, day, or evening to write it all out. 

Future trends

Here are my beliefs on how and where the industry will continue to trend:

  1. Privacy vs. growth: We will continue to see conflicts and friction between privacy (e.g. GDPR) and companies’ thirst for growth and retention (getting all available customer data). We already see this in many places. I hope that we can maintain reliable, trustworthy privacy while allowing companies to understand their users’ behaviors
  2. More departments want the data: In the past, it’s often been driven by Product OR Sales OR CS. A trend that’s been accelerating has been teams working together to share insights. This is due to the high revenue attainment pressure SaaS companies are facing; everyone has to work together
  3. Buy instead of build: Many companies get in trouble as they say “Oh, we can build that in a weekend/month”. That may be true, but it also requires a high cost of maintenance into perpetuity. It’s not just the dollar cost of hiring a team but of documentation and managing all the failures and errors
  4. AI documentation: One small improvement that I hope AI will take care of is documenting how everything works. If your AI system could sit in meetings, read notes, and formulate flowcharts, definitions, and how-to guides, that would significantly reduce the complexity of documentation tech debt
  5. AI to actively help the customer adopt/use the product: Instead of solely humans building pipelines, analyzing the data, and improving the product, I foresee a time when AI is embedded directly into the product to guide the customer. Think of a chatbot as 1.0. This is 4.0

*I try to plan these strategy sessions in the mornings or days near holidays or on Fridays when there is less activity.

References

Published by Jeff Beaumont

I love helping companies scale and grow their organizations to delight customers and employees, enabling healthy teams, fast growth, and fewer headaches. Scaling quickly is wrought with potholes and plot twists. When you’re running a company, losing customers, and employees are on their way out, and don’t have your systems running smoothly, then you’ll be at your wits' end. I've been there and hate it.

Leave a comment