208. Ultimate Guide to Platforms

The simplest definition of a platform is a technology that serves as an ingredient for the success of others but is so important that it achieves recognition and a market position on its own. The market position is such that there are many attempting to offer the same complete product or service, but the platform defines the not-so-secret ingredient upon which most, or even all, of the end-products or services rely. (View Highlight)

the biggest and most successful platforms simply started out as trying to solve a problem. (View Highlight)

The key is that the solution was obvious to at least a small set of people and it delivered an immediate win. This small set of people are not always what we think of as builders or software developers but are simply users. (View Highlight)

There are a number of challenges in this lifecycle stage. First, no matter how well a product might be architected from the start if you’re building a user experience first two truisms exist. First the UX itself probably pokes into the abstractions in unpredictable places, just in the crush to get the product working. Second, without the UX in place it becomes impossible to maintain the integrity of the data as you quickly learn how much of the integrity tier was developed or enforced in the UX. These are both solvable with time and rearchitecture all while most engineers on the backend or runtime are cursing the frontend team for violating the abstractions. This leaves the app/plaform in a bind which is the developers want complete control but the business wants to keep the brand and full capabilities of the product front and center. (View Highlight)

A rule of thumb I have developed about building products that help people while increasing stickiness for a company is as follows: source of truth >> code >> process >> individual skills. By this I mean that the stickiest platform is one where the source of truth for a business process exists only in that product. Once data is the source of truth, no matter how open (via API or ETL) the data is, the ability to move off a platform is constrained by the semantics of that data or the code, not simply the bits on disk. The next most sticky platform is one built on third party code. (View Highlight)

While any single person might be significantly attached to a product, organizations and people are far more willing to switch and learn something new than they are to change a process, write new code, or transport data. (View Highlight)

Why do platforms fail at launch:
• Failure to solve a problem that platform consumers really have
• Asking customers to solve your problem not their problem
• No one wants to leverage it
• Experience v. API and “who is on top”
• Doing too much
• Doing too little
• Charging in the wrong place, the wrong way (View Highlight)

for a platform to succeed, customers will need to put in effort. (View Highlight)

Enthusiasts love when they can assemble a complete product from various add-ins, but rarely does the mass market. (View Highlight)

Often the root of this failure is platformizing too early, before the whole (the whole product+device, or product+experience) has firm footing or a clear use case. (View Highlight)

There’s a strong desire by developers and potential consumers of a platform to use the underlying data or compute engine, but the platform maker sees their app as needing to remain visible and front and center. The problem is developers want to own the full experience for business and usability reasons (View Highlight)

When designing a platform the “Hello World” equivalent must be a one hour or less experience and the next steps obvious. (View Highlight)