One of the key metaphors I’ve been using in recent years is equating the common software stack into a tree trunk and branches.
For most personas/departments, there is one main piece of software that dominates a significant part of their usage and budget. This is the trunk, also occasionally referred to as the departmental operating system/platform. Onto this trunk, there are many smaller software solutions which often integrate with it - these are, naturally, the branches.
Startups frequently start as branches and eventually evolve (in reverse order) into a trunk. It makes sense - startups usually don’t have enough resources to develop a trunk as their MVP (or even within several versions later).
Founders need to make sure that there’s a clear pathway allowing them to evolve from their branch into a trunk. It means several things:
The features of their branch (aka first few product versions) can be organically and strategically leveraged by the trunk.
They won’t be easily chopped off if the incumbent occupying the trunk position decides to stop granting access to certain APIs.
There might be a different branch that is better strategically positioned to grow into that trunk, so alternative routes are important for consideration.
The key benefits of their branch are a strategic achilles’ heel of the incumbent trunk.
The persona and budget tied to the trunk are the same as for the branch (at least ideally).
And many more.
Lastly, another key point is that founders often overrate the importance of the differentiation of their specific branch. Or in other words, the importance of their penetration point. While the branch/penetration point is definitely important - the eventual trunk is no less important. And if two startups start off from two different branches, but eventually aim for the same trunk - then they’re competitors, even if not at first. And they aim for the same TAM, the same opportunity.