Applications vs. Platforms. Rules for the Many. Exceptions for the Few.

Working with a number of enterprise software companies that are creating new categories of business applications running on top of exciting and innovative SaaS platforms. And they are all trying to navigate the tradeoffs between creating customer value via continued investment in their applications vs. opening up the platform in order to discover additional application opportunities that might also have very good fit with their underlying engine. Plus trying to figure out when and where opportunities for developing partner ecosystems would help scale the business.

Rules for the many:

Traditionally the picture has been very clear: It is infinitely easier build and monetize business applications that create immediate value for a specific use case than to build and monetize generic platforms. Look at SAP spending decades in the applications business before productizing the Netweaver platform. Or Salesforce having delivered tremendous customer value for a long time with their applications portfolio of SFA and CRM and service desk automation products before subsequently externalizing the Force.com platform for generic application development by customers and ISVs.

So the normal progression is sequential and takes a long time. The business application(s) need to be compelling and unique, show a high degree of sustained innovation, and be an order of magnitude better than the incumbent competition. Such an effort requires a company and leadership with strong customer access, deep domain expertise, and a long-term commitment to creating more and more powerful business logic in their application portfolio.

Which means that the conservative advice is to refrain from dreaming about platform productization and monetization for a long time. That’s a different product and a different business and a different entrepreneur. Meaning 4-6 years in the applications business before, maybe, you can spend another 2-3 years on your platform before that is anywhere close to business relevance. Sound advice that you should take. Seriously.

Exceptions for the few: 

All the more interesting when you see a company compress this progression drastically and race through these phases in record time. In this specific case we’re looking at a perfect storm of the right things falling into place at the right time:

The business application that serves as the initial “get-in-and-then-spread-out” entry vector into the enterprise customer replaces an industry-standard legacy solution that ran out of steam and virtually the whole market decided in unison to move to our application at the same time.

The underlying platform has been developed in a previous environment specifically as a generic platform, so breadth, depth, and maturity of the platform are strong and visible from the get go.

Customers immediately latch on to the capabilities of the platform and start to develop custom solutions on their own without much nudging or support from the software provider.

Also the platform has unusually strong support for “no code” developers (sometimes also called citizen developers) who do not need extensive programming skills to deliver instant value to users. So the get-in-and-spread-out dynamic can happen in the line of business without having to involve central IT for access to pro-code programming resources.

Next step is to publish a wide variety of “apps” that help customers

  • understand what the platform is capable of
  • receive instant value if their needs are basic and a “good enough” offering is perfectly acceptable,
  • or help jumpstart the development process for building a custom application with proprietary business logic.

Leave a comment