Adoptability and the need for new software paradigms

Adoptability = the willingness and ability of a customer to adopt a new tool.

You would think that the existence of a pain in a target industry and the proposition of relevant value from software vendors would equate to adoption. But that’s not necessarily the case. Which is counter intuitive to many founders but is still very true.

Oftentimes during the ideation/validation phase, we find out about a significant pain in the market. As founders, we start thinking there are no available solutions out there and that this is why the pain remains. We then do our research and find out there are in fact many solutions in existence. Why then, aren’t these solutions being adopted?

Many reasons, among them -

1. Too many SaaS solutions already being adopted

2. Heavy data migrations needed for initial value

3. Lots of integrations needed for initial value

4. Lack of tech proficiency from potential users

5. Nice-to-have but not critical enough to exhort energy on by the implementor

6. Cumbersome solutions

The SaaS phenomenon started as a solution for better adoptability, among other motivators. But it is evident in the past 3-4 years that buyers are fed up with more and more SaaS solutions being offered in new/existing categories.

The no/low-code phenomenon was supposed to improve adoptability by decreasing the barrier to entry from the implementation/configuration angle. It only worked in several verticals.

One of the biggest attractions behind the (still mostly hypothetical) autonomous AI agents wave (a very ambiguous term) is their potential ability to bridge many adoptability-related gaps. An intelligent software component that can avoid many of the above obstacles -

1. No need to open a new tab in the browser (aka SaaS saturation)

2. Ability for self-configuration (aka no need for low/no-code proficiency)

3. Ability to independently create new software integrations

4. Flexibility in new data format digesting

5. Autonomous operations without complex user adoption needed

If (and it’s a very big if) AI agents would indeed represent a viable autonomous product approach and if founders will find a niche where these agents can provide value already in the next 2 years, their ease of adoption will be a key factor in their ultimate success, managing to deliver value where there is either SaaS saturation or to new groups of users that weren’t tech proficient enough to adopt no/low code based solutions beforehand (on top of other competitive advantages).

The Maple Approach

I’ve been in the VC business on and off since 2010. Surprisingly enough, it could be said that our business has remarkably changed since and it could also be said that it hasn’t changed all that much. Both can be true at the same time. When I first started thinking of Maple, I worked with the premise that “different is better than better”, or simply put, differentiation is everything. There was no point in yet-another-VC in the already crowded Israeli VC landscape. I began thinking of most of Maple’s ingredients a decade ago, but the philosophy really crystallized (perhaps unsurprisingly) through iterations and actual work with our founding teams (just like with every product development journey).

Our approach is based on 3 key ingredients -

1. Intense collaboration is key. When meeting with teams, we don’t mind if they don’t have a thesis at all or if their current idea isn’t fully baked yet. Through pre-investment collaboration, we can work together to optimize their direction and frameworks. Not with a superficial meeting once every month but by actually rolling up our sleeves and working together intensely based on cohesive playbooks and methodologies. This has been key in our work since the very beginning. It provides a real opportunity for the team to know us and for us to know the team and provide genuine value - before we decide to commit to each other for the next several years of our lives.

2. Specialization is key. There is an advantage to covering several sectors with a clear symbiotic relationship between them. Maple is dedicated towards several infrastructure domains - data infrastructure, cloud infrastructure, ML infrastructure, devops, devtools, cyber and other domains which will emerge in the coming years with similar characteristics and that our typical founders (elite engineers with high EQ) are looking to tackle. Grouping these symbiotic domains with one another helps us become better domain experts and it focuses us when cultivating our network to make a difference on top of it all.

3. Sharing a similar language is key. Collaborating with founding teams to such an extent wouldn’t really be viable if we weren’t speaking the same language (technically, psychologically and collaboratively). Sharing the same profile as the teams we work with - experiencing similar challenges as they did in the past, sharing similar skill sets, sharing similar values and perspectives - these are all crucial to our work and are the basis of a shared language, which is the underlying engine behind Maple.

We’ve been fortunate enough to gather a group of incredible LPs to back Maple in its journey, so that we can deliver on the above philosophy to the best of our abilities. Our LPs are some of the most talented founders, executives and institutionals from Israel, Europe and the US. With its final close now behind us, Maple Capital I is continuing on its journey at full throttle.

The Customer Profiles Framework (PCP>ICP>ECP)

An incredibly useful framework to leverage when trying to gauge the attractiveness of an opportunity or when attempting to strategize around early stage startup goals is the customer profiles framework, or more technically - PCP > ICP > ECP.

We are all familiar with the TAM > SAM > SOM methodology, which I've always felt was too intangible for teams to work with at the earliest stages. The reason being that these market size definitions are actually a derivative of customer profiles. In other words, if you have a shaky definition of your customer profiles (or no clear definition at all), these market sizes are really just theoretical fluff.

So naturally, the immediate takeaway is that it is far more useful to speak of target customer profiles and their evolution. Another key factor here is that there is usually a significant gap between your early adopters and your ICP (ideal customer profile). It’s important to have a term to describe and differentiate our initial customer profile, since it is not necessarily the ideal one (yet).

So let’s begin with the PCP. It stands for Penetration Customer Profile. “Penetration” is key here since we find it easier to think of the initial use case, initial customer profile, initial budget, initial buyer/user, the MVP and other important aspects as part of the same “penetration package”. This is what helps us get our first hold on the early adopters of our market.

As mentioned, the ICP is the famous Ideal Customer Profile. This profile represents a broader opportunity. The PCP is usually a subset of the ICP with a higher urgency and willingness to adopt our product. A key element behind the delta between the two profiles often revolves around an important parameter, which we call “time for pain increase”. This is the duration it will take for urgency to expand from the PCP to the ICP.

Needless to say, if both the PCP and the ICP don’t represent a large enough opportunity, then we have a problem (this is where market size definitions correlate with our framework - but as a secondary outcome - it is not the primary focus). Also, if the “time for pain increase” we theorize is too long, then we also need to rethink our strategy. Moreover, It is important to understand how our product offering evolves alongside the evolution of these profiles. Naturally, the MVP and several versions following it would be suitable for the PCP but could prove lacking for the ICP.

Finally, the ECP (aka the Extended Customer Profile) represents the ultimate opportunity, which correlates with the grand vision/platform version of our offering. These are the late adopters who will join the party after the majority of our market education has already been accomplished. Or these could be customers from other verticals, which only a broader platform could support.

This evolution of customer profiles is a much more tangible strategizing framework for early stage startups as it forces us to focus on data we encounter on a daily basis (customer characteristics) rather than top-down hypotheticals. It also better represents the gradual nature of how startups evolve and adapt their product and strategies according to the evolution of these customer profiles. I highly recommend it.