Part IV: The Product Score
If you haven’t read parts I, II, or III of this series, you should start here: Part I: Market Score, Part II: Financial Score, & Part III: Customer Score.
For some context before you read this:
- High Alpha is a venture studio that conceives, launches, and scales enterprise cloud (B2B SaaS) companies, thus this methodology largely centers around these types of business outcomes. However, some parts may be more broadly applicable.
- At High Alpha, we score each criteria category from 1–4 to intentionally eliminate any neutral scores.
- The “score” is partially subjective and is dynamic. Thus, scores can change over time based on if they are more developed or our views on a topic change.
In the last section of this series, I talked deeply about the value of strong customers in a business. Recently, new companies and CEOs are focusing more on Sales and Marketing as the method for winning, which has left product building to become a bit “old-fashioned.” Speed to market is important and gaining customer feedback is arguably one of the most crucial parts of early-stage startups, but there seems to be an under investment in good products.
At High Alpha, product analysis is a vital part of our own company creation and larger investment strategy. We believe that customers require good/valuable products to positively impact your business. So rather than one being more important that the other, we see it as a multiplication problem (Customers * Product = Value). Poor performance in either one will harm the long-term value of your business.
When we think about scoring an idea based on the product, we have a few criteria we look at:
- Technical Risk
- Big Vision
- Speed to MVP
- Frequency/Breadth of Use
- Services/Scalability
Technical Risk
While product creation and planning is important, a business needs to understand the larger mechanics of how it works and the viability of its concept.
On a large scale, technical risk may be defined as “can the technology be created?” This may sound a bit ridiculous to ask, but wireless headphones were not possible at a commercial scale until Bluetooth was created and advanced significantly. Similarly, a company that is focused on creating something that requires significant advancement of technology may need to find different ways to show value to initial investors and customers.
A modern day version of this is Hyperloop. The Hyperloop technology is fairly nascent in its current cargo and human transportation use case, so there is a fair amount of technical risk (and investment) that needs to go into the technology. High technical risk is often a sign of a longer company formation to MVP road.
While technical risk is not necessarily a bad thing (high risk = high reward), many companies go into development purgatory (a place where a company may be unable to produce a functioning product) if the technology does not become viable or commercially deployable.
This consideration should be balanced with the overall large vision for your product. Your “big vision” is your version of your “billion dollar idea.” When deciding the value of your product, it’s important to realize that the big vision is inherently counterweighted by having a fast GTM (go to market).
Big Vision
While technical risk is important to minimize, vision for a company must exist even if pivots may alter the course. For businesses with too little risk, the vision is probably too small, but with too much risk, you may run into the problem of not having a long enough product roadmap. Product visions are vital to creating sustainable and meaningful progress in product building. Often, the big vision of a company is the initial “endpoint” for an overarching product roadmap.
At High Alpha, we create large, expansive ideas for what a product could look like. An example of a big vision for Uber might be a fleet of self-driving cars that can basically optimize travel so much that prices fall to be competitive with airlines and that it replaces the idea of car ownership completely.
The value of the big vision isn’t inherently tied to anything tangible for the company itself, but it provides a goal for the company to aspire to. For example, a simplified product roadmap for Uber might be: car-ride finder app → self-driving cars → fleet manager → route and transportation optimizer. And this allows for the company to properly plan strategic initiatives for product development, partnerships, what platforms and technology are used, and much more.
Speed to MVP
The speed to the MVP (minimum viable product) is critical for companies nowadays. Funding opportunities are few and far between and are becoming more competitive. Speed also shows the potential of a business. A company that grows to $1 M in value within 2 years is more valuable than one that takes 5 years. More often than not, your initial vision or plan for your business isn’t going to work and requires you to pivot due to the lack of a product-market fit or a host of other reasons. The speed to the MVP basically forces a company to build a working and functional, but largely basic, version of their application to syndicate feedback, bring in cash flows, and ultimately start to build a market presence.
The definition of an MVP has changed significantly over the past 10–15 years. The bar for an acceptable application (even at MVP) has gone up significantly in terms of product, features, design, etc. Although this may have protracted the larger timeframe from company formation to MVP, it is still critical to find early validation of a concept to build the blocks of a successful business. I find LinkedIn Founder Reid Hoffman’s view to be spot on:
“If you are not embarrassed by the first version of your product, you’ve launched too late.”
Frequency of Use
This is a fairly intuitive point about products, but its an important one nonetheless. Products (beyond the UX/design), need to be something that people actually need or want to use and moreover products need to have users interact with them daily or as much as possible. This is much easier said than done.
The optimal state for every product is that it provides so much overwhelming value for the customer that everyone in the customer’s organization needs to use it and uses it for nearly every second of every day. Outside of a few basic applications, this rarely happens (think of Gmail, Excel, databases, Salesforce, note-taking applications, calendars, etc.).
Usually for most companies there’s an inherent trade off between depth and breadth. We see this with some of our companies. For Sigstr nearly all members of organizations that are customers use it, however most users are fairly shallow with the amount of involvement they have. The person who gets the most value out of the application is the marketing team who controls and monitors the campaigns and signatures. On the other hand, with Zylo, only a few people in any customer’s organization actually use the application, but for those people, it’s a heavily-used, vital product. At the end of the day, a simple equation can be used to determine the value of the frequency of use.
Number of Users * How Often They Use Your Product = Value
The objective here is to somehow balance the two factors enough to maximize the total value to the customer.
Services/Scalability
Another big consideration we have for products is the reliance on services and therefore the larger scalability implications on the business as a whole. Services are often a great way to create additional revenue for a business, but overly services-heavy businesses become difficult to scale and cap out at a certain point.
At the same time, services also typically lead to higher average deal sizes and contract values, so they may be beneficial for certain businesses. It may also directly relate to how expansive your product is; if your product requires many integrations and data sources, more services may be necessary.
Balancing services and the automation of services in the form of software is often a difficult process for companies, but is vital for scalability.
Scalability allows the same tech stack to be deployed to multiple customers (which inherently increases your overall gross margin). Many applications require some level of customization for customers. An example of this would be ClearScholar. Schools all run on different infrastructure and have different ways of interacting with students, thus for each different use case for ClearScholar, it may require significant customization (possibly in the form of services). On the other hand, outside of designs for campaigns, Sigstr is pretty easy to deploy for new customers.
Scalability also should be considered in terms of the tech stack itself. While Excel might be a solution for early data management, with larger data sets, it becomes highly manual and arduous without any knowledge of VBA, R, or some other automated process to make it scale more effectively as more data comes and more customers use the product.
Building good products is a much more arduous task that most assume. However, good products are vital to businesses growing into powerhouses and they have to strike a very delicate balance between a ton of competing interests.
Thanks for reading about how we look at products as a part of the company-building process at High Alpha. Stay tuned for the final criteria category: The High Alpha Score.
