The mechanics of platform businesses is often lost in our quest for features and functionality. This post explores the underlying mechanics.
Are you building the Airbnb for X, the Uber for Y or the Twitter for Z? Well, then this article might just be for you.
I work a lot with startups/enterprises building marketplaces and platforms to solve diverse problems.
But these startups often have a problem.
Most platforms and networks fail.
Well, to be fair, most startups fail; irrespective of what they’re trying to build. But the challenges to executing a platform are all the more complex. When users are the main contributors to the value created on the platform, the startup usually doesn’t control the value that is being created. I discussed this in the last article. (If you haven’t read it, you should check it out here.)
The prevailing wisdom which is supposed to explain most startup success is “Build a great product”. When WhatsApp gets acquired, it’s success is attributed to a great product. When Airbnb does well, the same wisdom gets bandied around.
The problem is that, very often, ‘creating a great product’ doesn’t mean anything specific. It isn’t any form of actionable design principle that one can work off. If you think of platforms/marketplaces, this gets more complicated because:
Building great technology is absolutely useless unless you can encourage interactions on top of it.
The other entrepreneurial mindset is “Let’s build the technology and see where users take it”. I believe that this, again, is an outcome of survivorship bias. Twitter did this, so it must work. We, however, never hear of the many stories where the startup built out the technology and users never took it anywhere.
While the Lean Startup methodology is a great way to start testing what makes a great product and what kind of technology users will embrace, it fails to lay out any design principles that help us plan what we want to test. As a methodology, it encourages testing but doesn’t say a lot about what exactly needs to be tested. This often leads to the local maxima problem, which my friend Andrew Chen describes here.
Testing and data only yield incremental improvements in the absence of good systems design.
Through this article, I’d like to lay out a high-level design framework for building a platform. Through the rest of this series, we’ll build on this framework to address the issues above.
In the last post, we explored in detail how value is created when users interact on platforms. The platform, of itself, has little or no value. Consider Airbnb without hosts and travelers transacting, or Medium without any writing and reading going on.
The platform provides the infrastructure and creates the conditions for these interactions to occur.
Our goal, then, is to design a platform that gets this part right.
As far as platforms go, technology is useful only when it enables interactions on top of it.
So how does one go about designing a platform that enables users to create and exchange value through interactions?
Well, to start with, we know the following about platforms:
The infrastructure and conditions define the kind of interactions that are allowed on the platform. The interaction, in turn, creates the user experience for both producers and consumers. The user experience for travelers on Airbnb is determined by the technology and interfaces but more so by the kinds of listings that hosts put up over there.
There are three distinct layers that feed off each other, that are described through the framework below.
This is the part that you can build out.
Tools include all the technology and interfaces that your company builds as part of the platform. Video uploading and hosting capabilities on YouTube are examples of Tools.
The Rules are baked into the platform and lay out the boundaries of user behavior. The 140 character limit on Twitter is one such example that is obvious to the end user. A less obvious example is the search algorithm on Airbnb that determines which listings show up on the first results page for a query.
If you’re designing or running a platform, this is pretty much all you control. You can build out the technology (TOOLS), you can structure the constraints and algorithms that facilitate behavior (RULES), but none of these guarantees any form of success with the platform. They merely create the infrastructure on which interactions occur and the conditions for such interactions to take place.
This brings us to the next layer surrounding the core.
Unless users come on board and interact with each other, the platform merely stays a ghost town. The interaction is the set of actions that users take which creates value on the platform (in the form of content and information added to the platform), provides feedback to the platform (in the form of votes, ratings, etc.) and enables users to consume value on the platform (in the form of on-platform consumption and off-platform fulfillment).
Consider an online education platform like Udemy or Skillshare. The teacher creating the course, the students learning from the course and rating the teacher/course, together constitute the interaction. The interaction is determined by Tools and Rules. What kinds of courses are accepted, what types of payment options are supported, which countries/languages the platform supports are some of the many factors that determine what kinds of interactions will ultimately occur.
The actions that users take on the interaction ultimately determine the final experience.
Finally, we come to the experience of using the platform. Producers and Consumers will participate on a platform repeatedly if they get value out of using the platform. While the Interaction layer is about actions that users perform, the Experience layer is actually about the value that users get out of the platform.
While the Interaction lays out the structure of value creation, there are different reasons different users may use the same platform. The same interaction structure may yield different experiences. This is usually determined by the content or information that is created in the interaction. Some people use YouTube for education; others use it for entertainment. Some use Airbnb for travel; others use it to find a roommate and split the rent for a short period.
For the platform to be valuable to users, it must solve a problem or provide a fix. It must be a vitamin or a painkiller, something that either solves a pain or gives a high. In either case, there is a job to be done.
The Experience layer solves diverse user problems, relying on the same mechanics at the Interaction layer.
I use the acronym TRIE to think of this. Not only does it serve as an acronym, but it also gives the feel of three layers.
The Rules determine the boundaries of the Interaction. What is and isn’t allowed. This, in turn, determines the experience.
In turn, every desired outcome in the “Experience” needs to be coded (in code or in principle) in the “Rules”.
The platform provides the Tools and Rules. The users participate in the Interaction. The Interaction is guided, facilitated and governed by the Tools and Rules to deliver the Experience.
As an analogy, the Tools and Rules are merely the Cooking Utensils and Recipe Book. The Interaction acts like the Act of Cooking and the Ingredients that leverage the utensils and recipe to create the final outcome: Food.
Getting an inside-out understanding, as above, is great. It helps us understand how design decisions ultimately impact the overall experience. It also helps us appreciate how little control the platform manager actually has on the experience that users have. This is what happens in a marketplace. You only own the tools and rules. If, instead, you were running an online store, you would have control over the interactions as well as you would control what gets sold.
However, as with all good design, the focus should now be flipped and should start with the user. In the case of a platform, we need to look at both producers and consumers. Who are the producers? Who are the consumers? And what job are they trying to get done?
Taking a leaf from Clayton Christensen’s book and using his useful (though quite a mouthful) Jobs-to-be-done approach, we lay out the job to be done for both the producer and the consumer. On a dating site, either side wants to find a date. On a marketplace, buyers are looking to buy something, sellers looking to sell it. This gets more complicated on online communities like Quora and Viki where different types of users may be trying to get different jobs done. But, in general, understanding the job to be done is a good place to start.
This lays out the Experience.
Once we understand the job to be done from the producer’s and the consumer’s perspective, its more intuitive to lay out the set of actions that these two roles perform to get that job done.
This lays out the Interaction.
Once we’ve got the interaction in place, we can then go into determining the tools that will be needed for this interaction. We can also, now, define what kind of actions are allowed and which ones aren’t. These are essentially then baked into the rules of the platform.
This lays out the Tools and Rules.
All platform design should frequently flip from the inside-out view to the outside-in view and back to ensure that the technology is designed in a way that encourages actual usage.
Here’s the part where most platforms fail. They just build out the inner core of this business (Tools and Rules) and remain stuck there. Users don’t use the platform to engage in interactions. Consequently, the platform doesn’t get the job done for users. And you end up with a YouTube lookalike but without videos or a Facebook-clone with an empty news feed.
This is what your platform looks like when it launches. And most failed platforms stay that way. When it comes to platforms, the boulevard of broken dreams is strewn with well-engineered technology that nobody used.
To succeed, the platform needs to develop the next layer. This is where platform seeding strategies become very important. Solving the chicken and egg problem is as much about clever marketing as it is about building the Tools and Rules layer in a way that removes friction in usage and encourages interaction. One could argue that Twitter’s 140 character limit is a brilliant Rule, in hindsight, as it enables more people to participate because of the much lower investment required in creating content.
“You know you have a platform when the users can shape their own experience – not just accept the maker’s ideas” – Jeff Jarvis
Great platform test! More often than not, if your platform succeeds in encouraging interactions and creating a great user experience, users figure out new ways of using the platform. Users tinker around at the Interaction layer to create new Experiences. The Experiences that prove rewarding get repeated more often at the Interaction layer. Over time, the platform notes how users are taking things in new directions and may make changes to the Tools and Rules to enable users to move in that direction. This is one of the most common ways successful platforms ‘pivot’ after gaining initial adoption.
Twitter is a great example. Originally launched without too specific a use case, users started using it to discuss and share, even break, news. The hashtag (originally proposed by Chris Messina as a user) and the trending feature evolved over time to accommodate these use cases. Changes in the Interaction led to changes in the Experience. Changes that were received well at the Experience layer further spurred those Interactions. Over time, the trending feature was instituted into the Tools and Rules to further encourage these interactions.
Twitter has a fairly simple set of Tools and Rules (as opposed to Wikipedia, Uber or Quora, which have more complex rules).
If we think of Twitter’s key Rules, they largely boil down to the following:
1. Must have 140 characters
2. #tags are clickable and reorganize feed
3. Must mention user by @
4. What you get is determined by who you follow
5. The stream is reverse-chronological
6. Favorites, Retweets, and Mentions will drive notifications
This is by no means comprehensive, but it gives an indication of the underlying rules at play.
The interactions are also fairly simple. You have users tweeting, retweeting and favoriting. But there are emergent actions. Hashtagging itself was an emergent action that later fed back into the rules. $-tagging was an emergent action that gave birth to a whole new company: StockTwits. There isn’t much of a community culture specific to Twitter that affects the Interactions the way it does on Reddit.
And then, step back and look at the experience. The simplicity of the rules and interactions can barely predict the range of experiences. From the rise of Arab Spring to the unbridled spread of selfies. From Justin Bieber fangirling to Kevin Spacey photobombing. From breaking news to what I had for breakfast. Few platforms generate the range of experiences that Twitter does from such a simple set of core rules.
If we do the three circles above for Twitter, the outer circle would be an explosion, the core would seem very small. Twitter is probably an exception.
If you think of this framework, it helps realize that the problem of feature creep has a much larger implication in the case of platforms. You may think you’re making a slight tweak, but that tweak is actually happening at the very basic layer. The impact that it has on the outside gets compounded.
The goal of thinking in the above framework is to understand why startups often fail at building platforms despite getting everything right. Why focusing on building a great offering means little unless you understand how Tools and Rules work with the Interaction to create the final Experience for the users.
Platform Design: Determine the job to be done and create the tools and rules that enable users to get it done. Tweet
If you’re building a platform, you provide the Tools and Rules for Interactions to happen. Tweet
While building platforms, great technology is useless unless you encourage interactions on top of it. Tweet
To get access to the entire series, click here.
Thanks to Marshall Van Alstyne and Geoffrey Parker from MIT for discussing early versions of this idea.
Why offline network structures are important to online network effects.