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 through iterations and actual work with our founding teams (just like with every product development journey).

The Maple approach is based on 3 key ingredients -

1. Intense collaboration is key. When meeting with teams, I 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 the team's 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 my work since the very beginning. It provides a real opportunity for the team to get to know me and for myself 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 - cyber, data infrastructure, vertical AI, devtools and other domains which will emerge in the coming years with similar characteristics and which our typical founders (elite engineers with high EQ) are looking to tackle. Grouping these symbiotic domains with one another is what creates domain expertise.
   

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 I 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 the work and are the basis of a shared language, which is the underlying engine behind Maple.

The Customer Profiles Framework

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.

The Art of Dumbing Down Your Product

There are many ways for a startup to pivot. Pivots can be driven by switching target users, finding adjacent use cases, moving between industries or changing business models. One pivot method that is far less discussed and has always surprised me in how prevalent it is - is the “dumbing down your product” method.

In the past few years, I’ve seen many instances of products that only fit the early adopters niche of an industry but miss out on the vast majority of the market. The reasons behind this are usually a combination of the amount of friction the adoption of the product involves vis-a-vis the amount of market education the startup needs to perform in order to will the market into dealing with that friction.

Market education, as many founders will tell you, is far harder than it first seems at the very early stages. It is a continuous process that never really ends. Sometimes, it is better to let the market educate you than to be the educator.

A few years ago, I examined an investment opportunity in a startup that started off as an AR glasses company but eventually dumbed it down to a product that essentially replaced excel files. The technological gap between these two offerings, needless to say, is vast. But that is what the customers could adopt more easily to solve a particular problem at that point in time. Oftentimes, customers know better than us what they need right now (though admittedly, it’s not always that simple). And while educating a workforce to work with new AR hardware could be more beneficial in the long term, on the whole, making a more gradual technological hop could be a better fit for the situation.

To be clear, I am not advocating for less ambitious technological leaps - every now and then a startup arrives with the right approach that does move everything forward in a way that no one expected. That’s critical. And yet, I would argue that that happens when the technology does most of the leaping forward, while the user can still advance at his gradual pace. Also, these are usually the exception to the rule. And that is why dumbing down a product is really more of an art than a science. Founders need to be very precise in pushing markets forward while not pushing them too hard.