

Discover more from The Beautiful Mess

It is common in B2B SaaS to describe companies as vertical and horizontal.
For example:
Vertical: Procore "Make it easier to manage construction."
Horizontal: Miro "Where teams get work done."
Procore focuses on managing construction projects. Miro focuses on helping teams collaborate.
You likely understand (either explicitly or implicitly) the limitations of these labels. What happens when Procore starts to expand to different types of construction projects? What happens when Miro starts catering to markedly different collaborative workflows?
Instead of the simple vertical vs. horizontal dichotomy, I prefer to think in terms of dimensionality.
Relevant Dimensionality
Dimension is defined as:
"An aspect or feature of a situation, problem, or thing"
Dimensionality is defined as:
"The number of dimensions something has."
Importantly, we consider dimensionality as it relates to our business and strategy.
Depending on the situation, only some dimensions matter. An international apparel company cares about dimensions related to regional climate and holiday patterns. A local shoe store does not. Even within a company, you'll find specific dimensions mattering more to some teams and less to others. For example, a product team may have little interest in a customer's precise purchasing process. Sales, on the other hand, does. To make things even more interesting, what matters changes with time.
We might call this relevant dimensionality.
Relevant dimensionality is critical because it is a key limiter to—and catalyst of—growth. Product (and corporate) strategy is mainly about deciding which dimensions matter and why they matter.
Theory vs. Reality
Every company wants to be a "pure" horizontal, capable of selling to every company in the world—or a "pure" vertical. Both are powerful because they have low relevant dimensionality. A pure horizontal caters to incredibly diverse companies with a single product offering (low dimensionality; the differences don't matter much). A pure vertical also has low relevant dimensionality. In theory, at least.
In reality, things get messy—both an opportunity and a challenge.
Some companies cater to multiple industries with the same product but develop unique marketing and sales strategies for each industry. The big question is, "how unique?" Can you do a light amount of customization and be good? Or do you need drastically different approaches?
Even within industries, you can discover relevant dimensions like "maturity." Imagine if you cater to four industries but discover that each industry has three clusters based on maturity. Boom…3x4=12. And different personas. 12x?. Oh no! Or not: maybe the dimensionality isn't relevant to your product and GTM strategy.
Companies often bank on a "platform strategy" or similar to lower relevant dimensionality. They are offloading the relevant dimensionality to customer and partner developers. It sounds good on paper, but what happens when some developers are experts and others are less experienced? Or the demands on the platform become markedly different?
Many startups grow initially by tapping into a single dimension: "early adopter." If a prospect is an early adopter, that's all you need to know. But what happens when you've exhausted the pool of early adopters?
Each of these puzzles centers around relevant dimensionality. My company, Amplitude, has an interesting example. In many ways, we are a collaboration tool, data tool, and analytics tool. Data products require DATA. That little twist—needing to involve engineering in instrumentation—adds more relevant dimensionality, which, we believe, is offset by the value of crisp, granular event-stream data.
Challenges
Teams struggle with three key things:
The Relevant Dimensionality Bias
When we want something to be true, we tend to underestimate the number of relevant dimensions. We downplay them. When we don't want to do something (or don't want it to be true), we overestimate the number of relevant dimensions.
My mom, when she doesn't want to go to a restaurant:
Oh goodness, WILL we need to park? Where will we park? What is on the menu? Do they even accept early reservations? What does work?
My mom, when she does want to go to a restaurant:
Wonderful. Please arrange it. Whenever! I can move my schedule around.
The net effect here is that teams struggle with predicting and acknowledging relevant dimensionality. We don't want to hear it. We hope it doesn't exist. Teams miss opportunities to be more proactive and deal with it.
Cross-functional Perspectives
It is vital to incorporate different views from across the organization. As mentioned before, some teams can get away with low relevant dimensionality. Meanwhile, other groups grapple with more variables.
This dynamic extends to disciplines.
Designers, for example, are more aware of how dimensionality might impact their work. An organization that diminishes designers' work—or doesn't hire skilled designers—may miss this detail altogether. A sales engineer tends to be more aware of how high dimensionality impacts the sales and onboarding process. It would be best if you had the perspectives of every function to get a good picture of the situation.
Linearity Bias (for Relevant Dimensionality)
The final issue is linearity and non-linearity. As relevant dimensionality increases, we experience a non-linear effect, not a linear effect. It can be challenging to predict how things will scale. Adding one more dimension could bring an organization to a halt. Or not.
Conclusion
To summarize, I invite you to think about relevant dimensionality instead of verticals and horizontals. Fight the relevant dimensionality bias. Invite cross-functional perspectives. And don't put too much weight on your predictions about how things will scale.
TBM 46/52: Verticals, Horizontals, and Dimensions
Great insights. Its not often that a company can have aligned relevant dimensions across all parts of the business. I think the key here is an aligned strategy that clearly identifies the venn diagram of which relevant dimensions are taken care of by different parts of the org (if at all) and which overlap. Otherwise, every group tries to make other teams optimize for their non-overlapping relevant dimensions.
We had very similar scaling issues, and initially opted for the framework approach, offloading scaling to customers to some extent. You quickly hit lack of skill challenges. Now we are building modules, maybe not scale all the way, but ease the scaling that the customer has to do.