Enterprise SaaS chart of pain

A hopefully refreshing read (with supporting images and videos) for battle-hardened SaaS businessmen, new SaaS entrants and aspiring VCs alike. We answer the questions: “why is enterprise SaaS so hard”, and “why is the common tech startup guidance sometimes plain wrong”. We also sprinkle in some wise words from the dudes who know.
Enterprise SaaS chart of pain

Enterprise SaaS does not get as much ink devoted to it as its more accessible, popular cousin: consumer tech.

If you are a member of an 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 lense to look at this world through.

Enterprise SaaS is a marathon, not a sprint As the post below explains, there are no quick wins.

“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.”

Jessica Livingston, author of “Founders At Work”, and founding partner of YCombinator.

(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.)

Enterprise SaaS chart of pain

The above chart shows, from top to bottom (on the vertical or y-axis), user value increasing from negative to positive.

On the horizontal or x-axis, from left to right, it shows product completion time (or development effort). In enterprise SaaS, depending on team size and product complexity, product completion can take from 1 year to 10 years.

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 a (later-)phased version of the final product.

The (curved) dark blue SaaS product line

Before getting into the detail, if you look at the dark blue SaaS line, you will see how long it takes to deliver a product of value.

However, after a slow start, value add starts accelerating relative to time or effort.

Anti MVP

A good metaphor for the first half of development effort (shown on the x-axis): “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

  • Half the development effort can deliver negative to 0% value to users
  • Moving from 50% to 60% effort can deliver 5% of value
  • While the last 5% of effort can deliver 20% of value

Talking specifically to the chart

The horizontal light blue line, providing the industry around 35% value, represents existing industry “home-made” solutions. Generally these comprise a more-effective-than-doing-nothing-outcome hodgepodge of various technologies and faster-horse solutions. Often they can be high total cost of ownership (TCO), non-scalable, NIH syndrome-influenced projects. This light blue line is a rational and innovative response to the pain that industry participants are feeling.

Enterprise SaaS laggards, early adopters, innovators, late majority

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.

The upper grey band explains the perceptions of the late majority and laggards¹. Comparatively these user personas are default negative.

Enterprise SaaS laggards, innovators value perceptions

Polygon 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, polygon 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.

Polygon 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 solutions.

Polygon C is the Holy Grail for SaaS businesses. From here, 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 tech are increasingly disadvantaged.

Industry application and learnings


Talking to the industry I know best, commercial real estate (CRE)… It’s an immensely complicated space involving both tech and data solutions. We as industry insiders are inclined to underestimate the sheer cost and time to deliver a 100% solution.

This underestimation increases risk of failure of internally-built product projects. Here are some personal experiences… Generally 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. Cue 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-funded. 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 projects are understandably wary of exposing themselves to similar pain again.


“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

If you go to market too early, users are going to hate your product. And justifiably so.

Expanding from here, while the wisdom around the tech adoption lifecycle is relevant, the converse for enterprise SaaS is especially relevant. Be hyper-vigilant in avoiding the late majority and laggards, even discriminatory potentially towards the early majority. In other words, avoid this segment of your potential customer base initially.


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: 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 not create pain for) with your first set of features. So test those features against user pain and needs, define and ring fence them, and proceed towards that development milestone (making peace that you will inevitably encounter feature bloat) for that specific target market. 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:

CRE tech adoption lifecycle

About the author

Related posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.
You need to agree with the terms to proceed