Enterprise SaaS does not get as much ink devoted to it as its more accessible, popular cousin: consumer tech. The advice that works for one, does not always work for the other.
If you are a member of a B2B or enterprise SaaS tech startup it is my hope that the information in this post spares you wasted resources, self-flagellation and despair. If anyone else, hopefully it gives you a different lens to look at this world through.
Enterprise SaaS is a marathon, not a sprint. As the post below explains, there are no quick wins. In the words of Jessica Livingston, author of “Founders At Work”, and founding partner of YCombinator:
I’d say determination is the single most important quality in a startup founder. If the founders I spoke with were superhuman in any way, it was in their perseverance.
(In the seminal “Founders At Work” Jessica records unique insights, from founders, of early-era Silicon Valley businesses such as Adobe, Apple, Craiglist, Firefox, Flickr, Gmail, Hotmail, Paypal, TripAdvisor, Viaweb, and Yahoo.)
The above chart is my attempt at sharing my experience (read: mistakes for you to avoid) in this space…
On the chart’s vertical or y-axis, user value increases from negative to positive.
On the horizontal or x-axis, running left to right, it depicts development effort and time zero, to product-market fit. (In enterprise SaaS, depending on team size and product complexity, product-market fit can take from roughly 1 year, to 10 years. This requires, as Livingstone says, a distinct level of perseverance)
A simple summary of the chart above: users would start off hating their low-maturity solution, then, as the solution matures, turn to loving it.
For a pithy 35 second explanation of the chart, see Marc Andreessen of Andreessen Horowitz above. (The video should start from 46mins 31seconds, if it does not, please move it forward to this time, and watch for 35 seconds)
In simple terms – in comparison to consumer web or mobile solutions, enterprise SaaS does not have a traditional minimum viable product (MVP). In opposition to the popular consumer tech view, the enterprise SaaS product’s “MVP” is closer in time to the later-occurring product-market fit.
Before getting into the detail, if you look at the (above chart’s) dark blue SaaS line, you will see how long it takes to deliver a product of value.
Relative to time and effort applied to product development, value added to users starts slowly. Then value add starts accelerating relative to this time and effort.
A good metaphor for the first half of development effort (running left to right on the x-axis) is: “building the invisible iceberg under the water”. (Ref image alongside)
Referencing the chart once more, the last third of development effort feels like “jig saw pieces clicking together”.
In other words
Shape A represents a period of time when the value of the product (in fact and perception) is less than that of current solutions. It also represents approximately 70% of development effort!
Interestingly, shape A1 represents a period of negative value. I.e. using the product will actually hurt businesses. Feature deficiencies (whether deemed enhancements or implicit bugs) will be regarded by users as bugs, and will create user angst.
Shape B indicates a period when the product, depending on which user type (innovator, early adopter, early majority etc.) assesses the product, will perceive it as good or bad. During this period, assessments of value are subjective. I.e. it is either more or less valuable to users than current DIY solutions.
Shape C is the “happy place” for SaaS business sales people. In this stage of the lifecycle, where product-market fit has been achieved, the relative value of the product is objectively superior. The competitive advantage in the industry belongs to all users who embrace the innovation. Users who don’t embrace the technology are increasingly disadvantaged.
The horizontal light blue line represents existing industry DIY or “home-made” solutions (Excel often plays a starring role!). It lives at 35% of total possible value provided to users. This light blue line is a rational and innovative response to the pain that technology-starved industry insiders are feeling. Generally such DIY solutions comprise a more-effective-than-doing-nothing-outcome hodgepodge of various linked technologies and “faster-horse solutions”. By their nature, such projects can be:
Either side of the light blue line is a grey area. This grey area represents human subjectivity.
The lower grey band represents the product value perceptions of innovators and early adopters¹. These humans possess a forward-looking bias – their value assessments are influenced by the gradient of a product’s (up-sloping) development curve. To clarify, they over-estimate the product’s value add relative to maturity.
The upper grey band explains the perceptions of the late majority and laggards¹. Comparatively these user personas are default negative. Despite the greater than-status-quo-value add, they under-estimate the new product’s value. This is neither good nor bad, it is simply how such personas operate.
In an effort to provide value to you, I unpack my mistakes and experiences below.
1.
Talking specifically to the industry I know best, commercial real estate (CRE)… CRE’s complexity is amplified because of its intersection between tech and data.
We, as industry insiders, are inclined to underestimate the sheer cost and time to deliver a 100% solution. Such underestimation increases the risk of failure of internally-built product projects.
Some personal experiences: Generally internal product launch will be premature (but delayed against projected timelines). Oftentimes such launch is motivated by an expenditure milestone number being hit, instead of agitated by product readiness. This immature solution creates negative PR. Then the actual hard work and money-spending starts. Features will be reassessed, scope will increase, and the project will be identified as under-resourced. If the decision to keep feeding the project resources is made, unintentionally optimistic representations (on unknown unknowns) will be made, and this will justify the project recommencing. Accordingly, at the next milestone, the probability is high that the project is over-budget, and behind time. And so it goes. Any rational (non-tech) decision-maker will bail on the project long before it hits the 75% completion mark required to deliver value.
Those industry participants (both product champions and users) burnt by well-intentioned internal projects are understandably wary of exposing themselves to similar pain-by-technolocy again.
2.
Warning: trying to force growth by skipping a step is the number one mistake entrepreneurs make, and it is often fatal.
David Skok, General Partner Matrix Partners
Against the flow of the Silicon Valley logic, going to market too early can actually hurt your business. Achieving the first phase of product-market fit is your first major milestone.
While the wisdom around the tech adoption lifecycle is relevant, the converse for enterprise SaaS is especially relevant. Until you have proved your product, be hyper-vigilant in identifying and discriminating against the laggards, late majority, and early majority. In other words, it is recommended, initially, that you actively avoid this segment of your potential customer base.
3.
Chase two rabbits, lose them both
Almost the mantra for software development, this is hugely applicable to the early stages of SaaS product development.
The take away here, and this is tougher than it sounds: exercise discipline in phasing your product development, based on meeting requirements of your “beachhead market”. Your beachhead market is that first group of strategically important customers that you can viably satisfy (or, rather, not create pain for) with your first set of features. Here you want to be ruthless in descoping, and doing development cost-user benefit analysis. Test your potential features against user pain and needs, define and ring fence these needs, and proceed towards that development milestone for that specific target market (making peace that your required feature set will bloat).
This narrow focus may seem counterintuitive for a business model based on scale. But, to lean on the wise words of Paul Graham here:
It’s better to have 100 people who love you, than 1,000,000 people who like you
Thank you to my mate Rob Levinson for highlighting the need for this post
¹Explanation of tech adoption lifecycle user personas:
Startups that seek to fuse enterprise SaaS and data (proptechs) are hard. Attempting proptech in an under-funded, under-sized market dials up the difficult. Is it impossible? No. But it will be easier if you know the pitfalls upfront, and can plan for them
A short post, leaning on a wonderful story by Nike’s co-founder and current chairman emeritus, Phil Knight, to explain the concept of domain knowledge, and the challenges and opportunities for businesses playing in high-barrier-to-entry domains.
