Firmographic Framework for Protocol Demand

Monday, September 11th, 2023

I wrote about the importance of identifying stakeholders (Mapping Stakeholders to the Demand-Side Objective Function) and crafting personas Demand Personas for Protocols.

Firmographic Framework is important for protocols that see large companies as a meaningful part of their target audience as users and developers.

I make the case that The Protocol Guide to Enterprise-Led Growth is a critical for the success of most protocols. If that's the case for you, then thinking about Firmographics is an important foundation; in fact, it probably precedes the work on demand-side personas.

What is a Firmographic Framework and why is it important?

If we believe that enterprise use will drive most growth and adoption (even amongst consumers if the application can be driven by consumer-facing enterprises), then we should have an understanding of what kinds of firms make the best sense for a given protocol? While everyone, of course, desires a purely horizontal play, finding those strengths will matter, especially given the speciation of blockchain protocols at all layers.

The firmographics not only define the use case and the requirements on the protocol, itself, but will shape the developer personas. Developers can vary widely by industry or by company attribute, so having an understanding matters.

Related to the firmographics is the actual use-case or the associated primitives.

Example with a Data Indexing and Querying Protocol

Let's use a protocol that is in the data indexing and querying space. All of these things need to be validated and hardened, but I'm using this as an illustration of the thought process and framing.

If the objective function is something along the lines of "maximize the monthly query volume" (Mapping Stakeholders to the Demand-Side Objective Function and Demand Side Token Design), how can we work backwards from the type of data and the companies or uses?

One of the first areas to explore is the nature of the data: is it public data or is it internal, private data?

While I believe that the blockchain will create new business models that blur the line between the two, it's important to think through it because most of the large TAM data businesses are focused on internal, private data. Snowflake, DataBricks, Oracle, Kafka -- all of the data infrastructure companies that have become huge are large because of the significant investment they make in managing their internally generated data (typically from customers and all of the downstream artifacts).

I think a data protocol that is going to capture a large TAM should position themselves for increasingly private and internal data.

However, short-term growth will come from public data, specifically public data on the blockchain. The thesis that public data that has value will all be blockchain-enabled (perhaps not on the blockchain, but proving or pointed to from a blockchain).

Let's start with this assumption, but keep checking back with the longer-term goal and use case.

The set of attributes should be the volume and the value of the data.

Here is one way to think about the blockchain data available for querying and indexing based on these two attributes:

The actual categories and positions within a quadrant might have some variance or nuance, but these are largely right.

Thinking about the target firms (what do they do, what is their model) helps guide protocol-level decisions as well as the overall go to market.

Imagine a protocol which implicitly believed that they met the needs of companies providing small-scale charity donations as well as real estate tokenization. Doing so would conflate the respective jobs to be done and impact the protocol capabilities themselves.

Consider a protocol which believes its platform could provide both personal identity verification and cryptocurrency transactions. It could....but the firms and application relying on personal identity verification likely would have a set of requirements less valuable to cryptocurrencies: security, KYC, web2 applications, redundancy or fraud detection -- components which a specialized protocol could bake in and gain traction.

Land and Expand

Is it possible to strategically to land in one quadrant and expand to another, later?

Yes, it could be. This would involve understanding the landscape and the respective personas better to do so.

For example, the "High Value High Volume" could drive requirements around throughput and data integrity which could carry over to High Value and Low Volume without compromising the price points of the service. Owning the High Volume wouldn't take much more effort. In this particular case, the over TAM of the Low Volume quadrant seems much smaller, so it's just an added bonus. Had it been big, even bigger than the high volume, those capabilities and a PLG-growth style GTM could own that adjacent market.

However, if we weave in Price, this potentially introduces a challenge of migration from a High Value (where you can command higher prices) to Lower Value, where customers may not be willing or able to pay those same prices. This can potentially limit the ability to acquire.

At this point, thinking more clearly about the personas, GTM and then how the protocol can offer such different prices given the permissionless nature of the service opens some questions.

To answer in this context, it helps to go back to the stakeholders and the stock-flow type diagrams (Stakeholder Maps for Platform) to come up with the answers.

In this example, we see that there are Indexers as the stakeholders, decentralized node operators who provide the compute and the services. The protocol could enable routing based on the quality of service; the lower prices are accepted by node operators who have less complex or lower quality requirements, protecting those who do offer the higher tiers of service to the high value projects.

Designed properly, this would allow for the protocol to flexibly address demand without eating into the protocol's operating margins because the ecosystem would adapt.

Present and Future

A subset which was not included, but should be considered for protocols that have the runway to do so, is to think about timescale. Particularly in blockchain, where the world is not running on blockchains by default, are there ways to think about the protocol and validate this by thinking about companies that fall into one of two buckets:

  1. Enabled firms because of the protocol
  2. Capturing firms that shift from web2 to web3

Enabled firms

This is more exciting, but super hard to find the insights; but if the protocol can identify believable and reliable ways new, non-existing companies are able to grow and thrive because of the protocol, this becomes an amazing, captive audience.

For example, the protocol could discover there is a class of "Data Creators" who are willing to create specialized data, perhaps from web2, perhaps as composites of blockchain data, who want to put it on chain; if the protocol ended up being the mechanism to capture the resulting demand for such data creators, this is a class of firms and customers that are enabled -- they couldn't exist with the protocol -- and can be part of future growth.

Another possible example could be cross-chain insurance products. It's possible such insurance products need to have a data-rich, real-time view of cross-chain assets to provide insurance against defaults (for example, if providing something like the FDIC to a loan-like protocol). If the ability to provide that rich data view were not possible or too expensive/brittle, these new businesses could emerge.

This approach to growth is harder because it's imagining a future of businesses and business models that don't already exist; so I think this is more about gathering insights from the "outliers" of the existing business.

It's like the famous story behind PayPal's growth: they identified a set of users on eBay who wanted to use PayPal as a payment method. It wasn't expected or anticipated, but it ended up being a double-down strategy that paid off.

Capturing the web2-web3 shift

Also hard, because typically transformation from one paradigm to another is slow; consider the move to the cloud. So many major household names resisted doing so because their DNA didn't support the shift. But once they did, the leaders like AWS were already there and captured the lion share (of note: Microsoft already had the legacy relationships with the big enterprises, and so that extremely strong position gave them alot of leverage in the space to come as a fast-follower).

A protocol that has found enough PMF to give them headroom to position themselves for this shift will capture lots of demand. The challenge is that the timing of a shift from one paradigm is unclear. Many people anticipated the cloud would have been adopted much sooner. The growth, however, was fueled by cloud-native companies.

As we see major brands like Starbucks and Tiffany's experiment with the blockchain, however, we can anticipate that they would want ways to track and monitor the performance, so the shift isn't far off.

Thinking through potential use cases and then validating them with customers, however, will give a protocol significant advantages.

For example, web2 stock trading applications may want to be able to provide their own real time analytics into the cryptocurrencies, even if they aren't already trading. Doing so directly may allow them to come up with proprietary added value which gives them a leg up into the market space as crypto trading becomes more mainstream. This would be a valid thesis for web2-web3 shift.

Firmographic impact on developers

Once the firmographic thesis has been vetted and validated, the more extensive and targeted developer outreach can come into play.

This may or may not change existing strategies.

For example, if the developers using the platform have already been mostly using it for NFTs (low volume, low value), and the target firmographics are crypto and legacy trading firms, the developer outreach would need to change.

Firmographics that has been validated and fits within the strengths and strategy of the protocol will be increasingly important for protocols to conduct to add focus and sustainability.