DaaS: Operating Model Implications for SaaS Companies

Part 4 of a series exploring how can “non-data” companies (SaaS, marketplaces, etc) build out commercializable data businesses alongside their core offerings.

Photo by Javier Allegue Barros on Unsplash

There are critical distinctions in a data business that may not perfectly sync with your existing model. Here’s a running list of areas where I’ve noticed special attention and/or change required:

Product and Engineering

• Having a working approach to “data as a product”, ideally close to the relevant data area, is critical. If your existing organization hasn’t adopted this for internal data products, you’re going to have to before commercializing (what are you taking to market if not a product?). The added benefit here: structured data product thinking will likely benefit internal producers and consumers of data as well.
• Be cognizant of when you’re productizing data into software. One of the primary reasons companies commercialize data is because it’s a high leverage play on an existing asset. As you explore use cases, and particularly as you approach the chasm on the innovation curve, customers will seek more features in your data product. This is where the exclusionary strategy/objectives above comes in handy.
• Talent-wise, one missing piece for some companies: solutions engineers or other client-facing technical talent. If you’re a SaaS company, your existing pre-sales/customer support may not be in the technical weeds enough to work directly with a data science buying center. This is a great place to look at Data Startups and look at some of their hiring profiles (e.g. the “Field CTO” as “Field CDO”)
• Additional reads: Treating Data as a Product, Data as a Product vs Data Products

Sales and Go-To-Market

• The commercial data ecosystem is heavily partner-oriented. To the chef analogy above: as a data vendor, you’re the truffle provider. While those same diners may buy truffles for at-home cooking, you’re likely to also engage with specialty food stores, wholesalers, and other chefs. You may ultimately stay focused on pure B2B sales to existing customers, but it’s likely you’ll find yourself engaging with both channel partners as well as product partners (e.g. other tech ingesting your data) along the way.
• Pricing models may vary: multi-year SaaS style licenses are common but so is consumption-based pricing. In general, licenses are high cost, high(-support “firehose” shares (e.g. all credit card sales for all retailers in 2022), whereas consumption pricing applies to low cost, high volume plays through APIs (e.g. return item attributes for individual SKUs). Rule of thumb: start with whichever is more closely aligned to your existing commercial model.
• A note on Hedge Funds: the most common starting point in commercializing data is that “hedge funds will definitely pay for this”. Everyone is thinking the same thing. Yes they buy data. Yes they spend a lot on data. But that also means they are probably the most sophisticated, practiced data buyers in the world- you may want to get some friendly reps in first before approaching.
• Great read on key commercial considerations: Data Republic Whitepaper (pdf)

Operations, Legal, and Risk

• Data commercialization carries one particularly unique organizational requirement: data delivery. This is a customer-engaging combination of product, engineering, and consulting responsible for making sure your data products get to the customer. As with any product, the higher the contract value, the higher the assumed support and having fully automated / self-serve support systems is not easy- expect to have a team of analyst-types ensuring successful delivery, resolving changing upstream and downstream requirements, and troubleshooting client issues with the data.
• Have Legal involved from the beginning for a couple of reasons. First, you have to ensure you have the contractual / regulatory right to share data. Legal can help bound the limits of addressable use cases. Second, it’s unlikely your existing client software licenses were designed with raw data shares in mind. Data-specific annexes, SoWs, and evaluation agreements will need to be drafted (I’d advise tackling from the ground up so Legal is fully caught up vs just trying to modify existing materials).
• Depending on both your source of data as well as your target audience, you may encounter new risk procedures. Consumer data in particular carries a whole host of regulatory considerations that should be reviewed and refreshed regulalry with privacy council, and financial institution clients will have regulatory review processes during evaluation. Beyond regulatory, there’s also internal commercial risk: if you’re leveraging data derived from your clients, you need to be prepared to face that conversation, or remove the data from your product. This area isn’t just Legal’s problem — I’m a firm believer that the Data Product Lead/GM should be on top of all of these considerations.

Disclaimer to the disclaimer: I suspect that the main flavors to this playbook are determined by A) whether commercialization is an internal decision or an external, investor-led plan and B) whether commercialization is a upfront-planned strategy or is more opportunistic. My primary experience is in an internally opportunistic approach that became more strategic over time.

Series Contents

• Summary: Time for Your Software Company to be a Data Company
• Part 1: Introduction and Definitions
• Part 2: Understanding your assets
• Part 3: The Value Calculus
• Part 4: Operating Model Implications