This is the third part of the blog, and here we will talk about Go To Market strategy, namely Business Model.
To remind, we will stick a business model discussion to the chosen product from the chosen industry:
Solar Farms Configurator
Architecture, Engineering & Design + Civil Engineering Construction
Obviously, there will be differences for different products, but the main concept, "reasoning from the first principles", will stay the same.
What we have done in the previous blogs
We defined TAM/SAM market size based on the Top-Down approach
We built a value chain around our target customers and defined their market share, and this is how we ended up with SOM calculations
We described solution space and stuck together hypotheses, features, benefits and values
Time to talk about Go To Market
We continue on the Supply side of our mutated Pythagoras tree:
The process of going through the mutated Pythagoras tree framework is not really linear; it is more about back and forth, trying to start from the different ends and to meet somewhere in the middle.
Business Model
A business model defines how we (software providers) create and deliver value for our customers. It includes products and services we provide and the way we paid for them.
Obviously, there are a lot of nuances, pitfalls, pros, cons in any business model. And the business model should be as well thought out as the product/service itself.
Let's go through business model characteristics and define our model for each:
Distribution (on-premise, cloud, hybrid) We build Utility PV Farm Configurator as a fully web-based product, so the value it creates is distributed to our customers through the cloud.
Code Licensing (proprietary, open-source) We develop our own code and algorithms, so the choice is obvious.
Interaction (one-to-many, many-to-many) We will solve customer problems directly, without involving any third parties; thus, interaction is one-to-many. A good example of many-to-many interaction is Airbnb because it creates a platform where providers and customers meet.
Target Audience (B2C, B2B, etc.) We already know that we will sell our product to companies, so it is a B2B model.
Revenue Stream (License, Usage-based, Subscription, In-App Purchases, Fremium, etc.) To define the best Revenue Stream or Pricing Model for us, we need to analyse our end-users in-depth (see below).
As you see, most of the Business Model characteristics were defined by the product idea and bits of knowledge we built on top so far. However, we are still unclear with Revenue Stream or Pricing Model, so let's work it out now.
When we speak about the Business Model (Revenue Stream or Pricing Model), we cannot use the market size dollar numbers because it doesn't show us the total number of end-users, the average end-users number per account, etc. We need to dance around the same market, but from a software supply (distribution) standpoint of view, we need to grow our ideas from the end-users, how they work, what they do, etc.
This is what is called the 'Bottom-Up' approach. Let's put down all questions we need to nail down during this phase:
What is our SOM end-users size?
What is the average number of end-users per account?
In addition to the questions above, we will refresh one's memory about how our end users solve current problems without our software. What do they do? What software do they use? What are their frustrations about the current software? How many iterations do they have?
The more information we have, the better and more scalable the pricing model we can develop.
The main question here is how we can explore the same market, but from a Demand-side standpoint of view?
I personally use two tools for these purposes: Linkedin Sales Navigator and Linkedin Campaign Manager. The approach is based on some educated guesses, and as you already understood, it is all about the quality of our assumptions.
Philosophy minute: when we plan such a complex process as product development with unpredictable outcomes, our goal is to understand better probabilities of different outcomes (not to predict the exact future). Obviously, if there is the information we can mine today that help us to make a better decision, we need to extract it. This information can easily change the way how and what we build.
We will use inductive reasoning to start. First, let's google 'top solar EPC contractors in the US'. Then let's filter this list (where PrimaryMarket = Utility and PrimaryService = EPC) and sort it by ascending.
As you see, we spent a few minutes googling information and already have quite a few insights:
We found the biggest solar EPC contractors in 2019
As you remember, in the marketing report from the previous blogs, there were some numbers about GW installed: 2019 - 8.4 GW, 2020 - 14.0 GW; also, there were numbers about utility-scale PV installations: 2019 - 362, 2020 - 313. So we can easily calculate the average utility PV farm size: 2019 - 23 MW, 2020 - 45 MW.
Solar EPC contractors above installed 5.6 / 8.4 = 67 % of overall utility-scale farms in the US in 2019
I propose not to make far-reaching conclusions but to focus on determining the overall size of the EPC contractors market.
For the so-called Bottom-Up approach or for working with the market size from a demand-side standpoint, I usually work with Linkedin Sales Navigator and Linkedin Campaign Manager.
Linkedin Campaign Manager allows us to search accounts by filters like 'Keywords', 'Geography', 'Fortune', etc.
Obviously, different filters are useful for different goals.
Let's see what we can do for our Utility-scale solar EPC contractors in the US:
We narrowed our search by 'Geography' and 'Industry', but it is still too broad.
I can save us time if I tell you that the most potent part of filters above is 'Keywords', but there are quite a few tricks to learn about how to use them.
The first thing that comes to mind is to use obvious keywords like 'solar EPC contractor', and you can try it, then check the first 10-20 results and see how irrelevant they are. This means that we need to find a more robust approach.
I suggest we do a kind of reverse engineering. We have the list of Utility Solar EPC contractors (17 companies); let's go through all of them and find similar keywords and patterns in their descriptions.
Then we need to group found keywords:
Renewable Energy, Renewable Energy Construction, Renewable Energy Market,
Solar Design-Build Firm, Utility-Scale Solar, Utility Solar Projects, Utility Solar PV systems, Solar PV, Solar Fields, Industrial Solar Projects, Solar Photovoltaic Plants, Photovoltaic Solar, Solar Systems, Solar Projects, Solar Power, Solar Energy, Solar PV Configurations
Engineering Procurement and Construction (EPC), EPC firm
After that, we need to play around with boolean search (AND, OR, NOT) to refine our market. And remember, as you get results, always validate them: check the first 10 results and make sure they are relevant. Also, make sure you found companies on the list you wanted to have.
I think there is no need to dive deeper into explanations about how to filter and search in Linkedin Campaign Navigator (it can be a holistic separate blog topic).
When the blog coverage is too wide, it is hard to consider all details for its parts. (c) Captain Obvious
For educational purposes, let's assume that we figured out the market size of ~200 companies (small, medium and enterprise).
What does this knowledge bring to us? And how are we supposed to use this data when working on revenue stream (pricing model)?
Knowing the Demand-side of SOM, the average number of users per company, how much the company spends money on the competitors' software, we can easily compare different pricing models (Subscription, Usage-based, etc.).
Let's say we played a bit with our end-users current software pricing structure vs our software hypothetical pricing structure:
Then we will play with company profiles trying to understand which revenue stream they will create for our product. Finally, doing back and forth calculations, we will find the scale in our pricing plans.
A bit of explanation about 'finding the scale in our pricing plans'
We assumed that our market is 200 companies with 6 end-users on average. Let's assume that we will achieve 10% of the market in the next 2 years.
With the Subscription model (the second table above), our ARR will be $500x200x6x10%=$60,000.
To calculate our ARR with the Usage-based model (per volume: designed GW), we need to make some assumptions like the number of iterations per project (50). As you remember, it was 313 PV farms installed with average farm power of 45 MW. Thus the ARR will be 313x45x50x10%x$0.2(140 GW plan)=$14,085.
To calculate our ARR with the Usage-based model (per volume: project), we also need to assume the average number of projects per year (20). Thus the ARR will be
200x20x10%x$100=$40,000.
I want to emphasize that we should only make assumptions above after talking to potential customers or trusted sources.
From the numbers above, it seems like the first model is the best one. But it is not fair to consider only the final numbers without considering the model's scalability.
The only way to scale model #1 is by increasing the number of users - we can create additional roles (for indirect functionality or kind of that). The only way to scale model #3 is by increasing the number of projects EPC contractors go through (it is tough to affect). At the same time, it is relatively easy to scale the number of options (designed MW) for the priding model #2.
It is all about trade-offs.
Conclusions
The more information (quantitative and qualitative) we have about the Demand side of the market, the better pricing model we can build
To build a scalable business model, we need to know thy customer profile (both company and end-user)
It is less likely that someone can predict a future, so it is all about probabilities and well-educated guesses.
Thanks for reading to the end. 😉