I recently joined Lenny Rachitsky on his podcast for the second time. We covered a lot of interesting topics, such as why Grubhub ultimately lost to Doordash, over-reliance on frameworks and research in product management, and a deep dive on network effects, SaaS to marketplace transitions, and why consumer subscription is so hard. Listen on your favorite platform below.
Currently Listening to Raven by Kelela.
When founders of startups start to hire employees to work on various parts of the business, it tends to be uneasy for both the founder and the employee early on. The founder may have done that job in some capacity before they hired for it, but they are not an expert. The incoming employee may bring more expertise, but they don’t know the business yet. The founder is going to have a lot of opinions as is the employee, and they won’t necessarily match. In this essay, I’ll talk about how to think about balancing founder intuition vs. team expertise, and how that changes over time. I find that this same balance is true for customers vs. founders when they start businesses too, so we’ll cover that as well.
Generally, the biggest mistake founders can make when starting to hire a team is defer too many decisions too quickly to new employees. This is most painful with new executives, but can also be damaging when hiring new individual contributors. Founders frequently convince themselves that this new person they hired is an expert on this topic, and they should defer to them. The opposite actually tends to be true. The founders are experts on the business. And incoming employees should defer to them until they are confident they have become more of an expert on a certain aspect of the business.
The opposite mistake tends to happen later on as the business grows. The founders have now staffed the company with a lot of great talent who have had time to learn the business, have impact, build processes, know customers really well, etc. Meanwhile, the founders are scaling a bigger business and getting further away from the details. Founder intuition becomes less reliable because the founder(s)’ advantage of having spent more time on the problem goes away. Their thoughts become perhaps dated. And they won’t really know it. This degradation of founder intuition also happens at different times for different parts of the business.
Great founders start to back away from relying on founder intuition when they see the expertise developing on the team, or are proven wrong in a meaningful way by the team that makes them start to question their often blind faith in their own judgment. Moving forward, founders have to calibrate how their intuition stacks up against team expertise on every topic of the business to know how much to intervene vs. let the team drive. Think of this as a simple graph.
It’s incredibly hard to accurately graph where the founders and team are on this graphic for every topic within the company, and when they cross. Normally, founders tend to navigate this based on factors like personal interest, what areas of the company they perceive to be doing well or not, etc. Having worked with lots of founders myself as a leader, advisor, investor, or board member, I default to founders needing to operate differently at different stages. On a bunch of different axes, I have mapped how I think companies optimally behave as they grow (changes in italics).
| Phase 1: Starting | Phase 2: Scaling | Phase 3: Expanding |
| Founder makes decisions | Founder starts to delegate decisions | Founder empowers team completely |
| Speed > Precision | Speed with some precision | Precision > Speed |
| Generalist > Specialist | Specialist = Generalist | Specialist > Generalist |
| Done > Perfect | Done > Perfect | Done Perfect Trade Off |
| Focus > Breadth | Focus > Breadth | Breadth Focus Tradeoff |
| Execution > Strategy | Execution > Strategy | Strategy = Execution |
| Hungry > Seasoned | Hungry > Seasoned | Seasoned > Hungry |
| Cheap > Robust | Cheap Robust Trade Off | Robust > Cheap |
| Teamwork > Process | Some process | Process First |
| Doers > Managers | Doers with some doer-managers | Managers + Specialists |
Obviously, this table can be a bit crude, and understanding when the company is shifting between phases is not always apparent to everyone inside the company. But it provides a default guide on when to delegate and empower teams as a company grows. I find that just asking the question of what phase the company is in builds good awareness on how one might want to be operating at the moment.
If you are a startup employee or leader, you have to respect founder intuition greatly. The company would not have gotten to the point you could have even been hired had that intuition not served the company well. But when you’ve really spent the time to understand the business and you or your team can start to have better judgment than the founder, it’s important to signal that confidence and get alignment on the operating model shifting. It will not be an easy conversation, but worthwhile to have.
What can you gain from such a conversation? First, you make the above graph visible to the founder in a way they may not be aware. Second, you can calibrate where each of you think you are on this graph. If the founder believes their intuition still serves the business better on a topic than the expertise you have built, then you can have a conversation about what would signal those two lines crossing to change how decisions are made in that area? Keep in mind, in some cases, that answer may be that there will never be a signal that changes how much control the founder wants to exert in an area. Companies are not democracies, and founders have the right to run the company any way they want. If they want to drive decisions on what tech stack the company uses or which segments are interesting, they will. If you don’t like it, you should join another company. But most founders want to do what is best for the company, and giving them the signal on where it’s valuable for them to lean in vs. that potentially being unhelpful is worth figuring out.
On the flip side, if the founder is putting decisions on you or your team where the founder would be better fit to make the calls themselves, tell them! There is no shame in admitting you’re not yet equipped to make the calls and empowering the founder to make more direct decisions for a while. This is not an admittance of incompetence. It’s driving clarity on decision-making rights that are optimal for the business. If you’re still asking the founder to make those same calls a year later though, expect them to think you aren’t developing the expertise you should be.
What is ironic about founders and employees facing this split between intuition from expertise is both have to do that same analysis with the company’s customers. When startups are small, most founders and employees tend to think the customer knows best. This may be experienced by changing the product based on customer feedback, allowing customers to experiment with different ways to use the product that help them become successful, etc. But as a company scales, it starts to see every way customers use a product, and what works best. For a marketplace like Airbnb, it might be seeing that hosts that provide toiletries get higher ratings, or for Eventbrite it might be seeing that emailing past attendees of an event a certain time before the next event maximizes their chances of buying another ticket. Then, the company’s job switches from observing what customers are doing and adopting them to teaching customers what best practices the company is aware of that will make them more successful.
So, in summary, founder intuition is extremely valuable, and new employees and leaders should learn to leverage that vs. ignore it because they’ve seen things before. But founder intuition does ebb over time in most areas as founders scale up the company, and of course, teams get a lot smarter as they spend time on deep company problems. This also happens with your customers over time. Having a dialog about where teams are in this journey is important to helping startups scale, clearing a path for teams to have maximum impact, and for leveraging founders’ scarce time in the areas that are most highly leveraged.
Currently listening to my 2022 playlist.
I have written a lot about product/market fit in the past. Whether you are a founder, product or growth leader, being able to recognize and measure product/market fit is a critical tool to make the best decisions on driving success of a company. In the post I linked to above, I make a case on the two metrics you really need to understand about product/market fit: retention and acquisition, and that product/market fit is really about finding a level of satisfaction (usually measured through retention) that will drive scalable acquisition. If you apply this model to a SaaS business, the application is usually pretty straight forward. Measure the retention of your customer, and does either the virality or monetization unlock scalable acquisition loops like sales, performance marketing, referrals, or content. Many founders struggle to apply this same framework for network effect businesses though, and it’s easy to see why. Frankly, it is just much harder. In this post, I’ll break down the nuances of product/market fit for network effects businesses to understand if you’re on the right track.
When a network is a key component of the value prop you are trying to create, and things aren’t going well, it’s hard to understand which is the real issue preventing the product from reaching product/market fit:
I’ll break down some additional insights to product/market fit for different types of network effects to make the product/market fit mystery easier.
Cross-Side Network Effects (Marketplaces and Platforms)
Cross-side network effects can be painfully difficult to find product/market fit for because you are building out a product for two different types of customers that have to align. It can feel like building two companies at the same time. Fortunately, there are some easy ways to navigate this puzzle to make the journey to product/market fit less amorphous. The first is that for businesses like marketplaces, it tends to be easy to understand how to constrain the audience initially. The first thing to understand is that there a spectrum of network effects from global to local:
Based on whether you are pursuing a global or local network effect, you can usually either constrain the audience by category or geography to start: Grubhub started in one neighborhood in Chicago, for example. Amazon started with just books.
Assuming you pick the correct geographic or categorical limit, you can test the value prop and scaling of supply and demand to find liquidity, which is a synonymous term with product/market fit for marketplaces. There is almost always a quality and quantity element to liquidity. If you understand it, you can then measure product/market fit by just analyzing retention and acquisition for both sides of the market.
Platforms are more complicated in the beginning, but eventually follow the same logic as marketplaces; they are just less likely to have a geographical component at the core. Whereas marketplaces need supply to attract demand and are willing to do unscalable things to generate that initial supply like paying drivers to sit idle for Uber and Lyft or delivering from restaurants who are unaware they are on your platform like Postmates and Doordash, platforms tend to have to be the initial supply themselves. Let’s take a look at a couple of different examples. Nintendo has had some of the most successful hardware platforms in gaming across decades. One of their secret sauces is that they seed supply on their platform with games they build themselves that they guarantee are high quality. Now, they can afford to do that with games that are based on incredibly valued IP like Mario, Zelda, and Pokemon. This creates initial demand for a new hardware platform like, say, the Nintendo Switch, that then attracts third party developers to build games for the platform as well. Then, Nintendo can look at demand side retention through purchases of games, and supply side retention through creation of multiple games. This helped them understand that platforms such as the Wii and the Switch had strong product/market fit, whereas the Wii U and GameCube much less so.
The success of the Nintendo Switch was partially due to the console launching with one of the best reviewed games of all time from a beloved franchise: The Legend of Zelda: Breath of the Wild.
On the software side, Shopify and WordPress have spent decades building their own SaaS features to allow the platform to become stronger and stronger with other features built by external developers they would never consider in their roadmap. Now, the majority of the value may be generated by third party developers, but a lot of first party development was required to get them far enough along in customer acquisition to make it attractive for so many developers to build on top of their platforms. You can read more about building successful platforms here.
Data Network Effects (Personalization and Recommendations)
For products that expect to create a better experience through data, the journey to product/market fit is usually about collecting enough data to provide a compelling experience. For some products, this takes a massive amount of time. Pinterest, for example, started as more of a tool for individual users to collect cool things from the internet before it could become a real recommendation engine for things related to your interests based on the wisdom of the crowd. Tinder can recommend great matches after just a few swipes. After I joined Pinterest, we had to make a hard pivot to onboard new users based on topics instead of their friend graph as we realized there was stronger product/market fit as a content recommendation engine vs. a social network. This creates an issue for geographical expansion. By default, we would not have enough data to understand local tastes. To rectify this, we had to reconfigure our feeds to emphasize the local content we had, in the local language, and in the local way of measuring (no more imperial measurements!). And in some markets, the focus needed to be gathering content so we could even have enough local content to display.
Direct Network Effects (Communication Tools and Social Networks)
For many network driven businesses, especially in the social realm, there is a Goldilocks zone of user experience. Too few people or content, and there isn’t enough content to consume or people to communicate with. Too many people or too much content, and it becomes overwhelming, or generates too many notifications. When Yogi Berra said, “”Nobody goes there anymore. It’s too crowded.”, it’s easy to imagine he was talking about Clubhouse, not a local restaurant at the time.
Clubhouse downloads per month. This graph is not up and to the right.
For a marketplace, there is usually a clear way to constrain the audience to generate appropriate retention metrics to evaluate product / market fit. Geography or category is the dominant mode for this in marketplaces. For SaaS, it’s a specific target audience. But social or content driven networks eventually want to scale to everyone, and a lot of times founders or leaders can’t tell which should be the first audience that will hook onto it. The better your thesis, the easier it is to evaluate e.g. Harvard only with Facebook, midwestern moms with Pinterest, USC with Snapchat. So the dominant strategy for building direct networks effect business is to have a strong thesis for the target market, prepare to be surprised both who the target market and right features are, and shift to another type of network effect over time. Outside of communication tools, it’s usually my belief that direct network effect products are actually cross-side network effects products where it’s just too early to understand who the different sides are. So, founders have to understand the user data or have a strong vision for what type of cross-side network effect or data network effect can be created to scale product/market fit over time. Do this, or risk becoming like a lot of other flash in the pan social network fads that failed to scale.
–
My previous post on product/market fit mentioned the Ries vs. Rabois model on finding product/market fit, which you can think of as testing vs. vision. While both concepts have value, attempts at finding product/market fit with network effects businesses tend to reward more of the Rabois model, or else the testing you do will be inconclusive on the reasons why something isn’t working between the core value prop vs. the size of the network. Finding product/market fit for these types of businesses is much harder, but can be much more rewarding in terms of scale if successful.
Currently listening to my Hipster House / Lofi House playlist.
Lenny Rachitsky recently launched Lenny’s Podcast, and I was happy to be a guest. We talk about how to communicate upward, different product design strategies for complex products, what it means to be a product leader, and much more. I’ll expand on some of these in upcoming posts. You can listen to the podcast here or on Spotify below.
Currently listening to my Downtempo House playlist.
Harry Stebbings of 20VC fame is launching a new podcast series focused on growth. I was happy to be his first guest. We talk about growth inside startups, how to hire for growth, and many other topics. You can listen to the podcast here or on Spotify below.
Currently listening to Mana Pool by VAPERROR.
I don’t remember much from high school literature classes, but one of the key frameworks I do remember is the different types of conflicts in storytelling. Now, the internet is confused over how many types of conflicts there are. Much like the 4P’s of Marketing are now 7, scholars are adding more types of conflict in storytelling over time. When I was taught this, however, there were three we focused on; whether the protagonist was fighting against:
Why am I talking about high school literature frameworks? Because every company has a conflict as well. The type of conflict a company is in will determine how you think about competition. I’ll describe these conflicts in more detail, how they apply to companies, and how to think about what to do in each situation.
Company Vs. Nature
Every founder I speak with can name dozens of competitors. That does not mean they are in conflict with another company. Take Grubhub, for example. When I joined, we had raised $1 million in venture capital, and had three competitors all about the same size, but with different strengths and strategies. But this was not a competition about who would become the leader in online ordering for food delivery. This was a competition against nature and to make food delivery more attractive to consumers, and if they were ordering delivery, competing against calling restaurants on the phone. At the time, 99% of people were not ordering food online.
Most startups are in a conflict against nature. There is a status quo in the market – or some other type of barrier to adoption like, say, a global pandemic (“too soon!” shouts my co-workers) that has to be overcome for any type of company in the space to be successful. Normally, startups engage in trench warfare to grind against the status quo over time. Online ordering for food delivery went from a very fringe thing to a completely normal thing that everyone does. Mike Evans, Grubhub co-founder, famously said, “we were an overnight success ten years in the making.” Occasionally, nature provides catalysts to growth as well. Just talk to any telemedicine startup, grocery delivery service, or remote work tool about what happened to them when the pandemic started. The technology already existed for all those companies, but consumers needed a forcing function to accelerate adoption.
If your main goal is to grow the category and make people want its value prop in general, obsessing over competition isn’t very helpful. This is how we felt at Grubhub. We didn’t care too much about competitors at all and focused on our customers. This prevented us from wasting precious time analyzing our competitors instead of our customers, which is what would really help us be successful. Eventually, Grubhub acquired those initial competitors or made them irrelevant. When we acquired those companies, we found they spent a lot of time thinking about us. Now, one can make the counter-argument that that is because we were winning. This is a very important point. If any competitor working to grow a category is being materially more successful than another, you may shift into another type of conflict.
Company Vs. Another Company
In many markets, companies fight vehemently against competitors. Companies are embroiled in a Red Queen effect, where each company is trying to out-innovate or outwork others in the market to gain market share. Think of Uber vs. Lyft as a recent example. Startups frequently think they are in this type of conflict when they are not. I have seen quite a few startups emphatically compete before they are even sure the category will be successful. In many of those cases, it would be better to cooperate and grow the category faster by being coordinated. Stripe and Shopify are an interesting example of this. The categories of ecommerce and online payments are growing so fast that instead of competing with each other, they have tightened their partnership to make sure the category continues to grow quickly. Uber and Lyft however tracked each other’s moves, and responded in kind to new product launches, pricing changes, and market launches. Both of these moves look correct in hindsight. Uber and Lyft’s market, while growing fast, would ultimately be capped by consumer transportation needs, and lean toward a winning take most model due to the strength of the local network effects involved in the model. While Uber and Lyft have been competitive, they ultimately saw value in presenting a unified position on local regulations and working together to ensure its services would remain available throughout cities worldwide. So company vs. company can change depending on the fight back to vs. nature.
Company Vs. Self
The third type of conflict within a company is one many founders and employees seem to forget: competing with themselves. In this type of conflict, the primary fear of the company is not that the market doesn’t unlock or that a competitor will take your opportunity; it’s that the opportunity isn’t realized because the company cannot execute on the strategic vision. This type of conflict can be dominant for many reasons:
Investors frequently call this “execution risk.” A company in conflict with itself means the vision is definitely technically possible (hence, not technical risk), but the company struggles to build toward it either due to being unfocused, people internally competing vs. cooperating, or building is very difficult due to technical or process issues. These types of companies can be appealing to certain types of executives who think they can fix the underlying execution issues. The reason for this is that if these companies do everything right, they win. This is certainly true. But it is not easy. Evernote is a recent example. Technical debt slowed their progress to a crawl, so the new CEO spent two years rebuilding everything. During this time, growth was slow, and more competitive risk emerged with companies like Notion, Coda, and Roam Research. If the company is finished with its conflict with itself, it likely finds itself in conflict with other companies now.
It is tempting to say in this example that Evernote should have paid a lot of attention to these competitors early on, but I think that would have been a mistake. The entire issue with Evernote seemed to be that they spent too long building new things on top of a technology stack that became unbearable to maintain. Movements in the market have no impact on fixing that core problem.
—
The type of conflict you are facing affects a lot of how you build and what you focus on as a company. Spending some time to think through where the real conflict is can help focus the company on the right activities to win. This can affect how much you invest in marketing, the focus of the product roadmap, and even organizational structure. Tackling the appropriate conflict is where the real leverage is in growing a company.
Currently listening to my Vocal Tones playlist.
As a product leader with a background in growth, it’s surprising how much what I actually end up working on is product/market fit. Product people should only be focused on growth i.e. connecting people to the value of a product once they’ve confirmed the product is delivering value. So it’s important to have a strong understanding of what product/market fit looks like before investing in growth. Founders and product leaders struggle with answering this question however, and advice and blog posts on the internet frequently espouse that you’ll know product/market fit when you see it, and that all of a sudden everything will start working. It’s not very actionable advice. I don’t claim to be the world’s foremost expert, but this is what I learned through scaling multiple startups, launching new products, and advising and investing in dozens of companies.
The Quantitative Approach to Product/Market Fit
I define product/market fit as satisfaction that allows for sustained growth. Satisfaction is tricky to understand because, well, customers are rarely truly satisfied. Jeff Bezos frequently drops pearls of wisdom in his shareholder letters, and my favorite of them is the following:
One thing I love about customers is that they are divinely discontent. Their expectations are never static – they go up. It’s human nature. We didn’t ascend from our hunter-gatherer days by being satisfied. People have a voracious appetite for a better way, and yesterday’s ‘wow’ quickly becomes today’s ‘ordinary’.
To put that in product/market fit parlance, product/market fit has a positive slope. The expectations of the customer continue to increase over time, and in fact, total satisfaction is likely an asymptote impossible to achieve. So what is product/market fit then? Product/market fit is not when customers stop complaining and are fully satisfied. They’ll never stop complaining. They’ll never be fully satisfied. Product/market fit is when they stop leaving. Represented visually, customer expectations are an asymptote a product experience can rarely hope to achieve, but product/market fit is a line a product can jump over and try to maintain a higher slope than over time.
All products start below a theoretical product/market fit line and some cross that line and work to stay above it over time.
So, for most businesses, instead of measuring satisfaction, measuring retention is the best signal of product/market fit. Measuring retention is pretty easy. Perform a cohort analysis, graph the curve over time and see if there is a flattening of the retention curve. As I’ve discussed before, what you measure for your retention curve matters quite a bit though. For your product, there is usually a key action the customer takes in a product that best represents product value. For Pinterest, it was saving a piece of content. For Grubhub, it was ordering food online. For your product, there is also a natural frequency to product use. For Pinterest, we eventually determined that people would browse sites for topics of interest on a weekly basis. For Grubhub, people usually ordered food once or twice a month. Once you have a key action and a designated frequency, the cohort graph should have the key action as the y axis and the designated frequency as the x axis. This does not mean companies should ignore other measurements of satisfaction, but to understand definitively what product/market fit looks like, this is the best start.
This graph measures a group of users and how many of them perform the key action of your product over time. There will usually be a stark drop at the beginning, but for products with product/market fit, a percentage continue to find value consistently.
If you’ve been around startups long enough, you’ve undoubtedly seen startups with retention of customers that struggle to grow. If you’re not growing, you definitely do not have product/market fit. So product/market fit cannot be measured by retention alone. That retention has to create sustainable growth, which means the rate of retention matters. Why does the rate of retention matter? Well, most acquisitions of new customers come directly from retained customers through a few key acquisition loops. Either retained customers:
I’ve seen many founders misunderstand this, looking for growth hacks to drive growth or a PR bump. These types of tactics are only useful if they help you sequence to a sustainable growth strategy, but they rarely are sustainable growth strategies directly. This is why other measurements of satisfaction can still be important. If it doesn’t exist, the first two of these loops are impossible to drive growth from.
Sustainable growth is measured by one or more of these loops growing the size of your monthly acquisition cohorts month over month with a flattened retention curve. A flattened retention curve of your key action at the designated frequency plus month over month growth in new customers is the best way I have found to measure true product/market fit. If the rate of retention can’t support acquisition loops that continue to scale new users, retention needs to be improved to find product/market fit. Some companies can scale with 10% retained users, and some may need 40%, all depending on the strength of the acquisition loop. The graph below represents one month’s cohort retention over time vs. monthly growth in new users.
Consistent flattening of a month’s retention curve over time plus growth in new users every month is true product/market fit.
What if satisfaction of your product cannot be measured by retention? This happens. Some products are one time use or extremely infrequent in nature. In that case, I like to use custom surveys to measure the level of satisfaction depending on the nature of the product. Rahul Vohra describes the process they used at Superhuman for this, and it is excellent. Don’t forget to measure new user cohorts month over month though. Acquisition becomes even more important in these scenarios.
The Paths to Product/Market Fit
It takes most products a couple of years to find product/market fit. If you are not there yet by the above measurement framework, don’t be alarmed. The first step is to understand how far along you are and the approach to improve. There are two stages of the push toward product/market fit:
If you are in the first phase, you generally aren’t allowing customers to use the product anyway to measure product/market fit. There are two main schools of thought for how long you should stay in the first phase, which I will oversimplify into calling the Eric Ries model and the Keith Rabois model (unfair to both of them), and they are diametrically opposed on many axes including how long you build before you allow customer access. Thinking about these axes will help you understand what to do next and what successful companies did in this phase. I will outline some of the main differences below.
This is certainly oversimplified, but should help give an idea of the spectrum of things to consider with a new product. Let’s break these down in a little more detail.
Time To Market
The Ries model emphasizes talking to customers early and often to understand what to build, and whether what you have built is actually solving problems for them. The Rabois model is so driven by the vision of the founders of the company that customer feedback is less important than building what the founders have envisioned before any customers interact with it.
Success can be achieved by both modes. In the food delivery space, Tony Xu and the founders of Doordash and Arram Sabeti, the founder of Zerocater, famously used spreadsheets and founder manual labor to prove out their early models before investing in a lot of technology to scale. Shishir Mehrotra, the founder and CEO of Coda, spent four years building the product before any public launch, and now the company is growing quickly. In reality, companies that take longer to reach the market usually have alpha or beta customers that are still driving a feedback loop into the product. Coda used employees at Uber, for example.
Focus
The Ries model tends to target a customer segment and attempt to find out their pain points to build something valuable. The Rabois model starts with a strong vision of both a problem and a target solution and works to build that from the start. The Ries model is common in enterprise business where customers just want to deeply understand data scientists or general contractors or some other segment, identify a problem they deal with a product solution could solve, then build and test with that segment. Here, you’re more likely to see some early pivots as companies try out different solutions to the same problems or target different problems of the same type of customer. We incubated a few of these types of companies while I was at Greylock with success, but it was rarely the first iteration that was successful.
One issue with the Ries model here is successful product/market fit rarely avoids all speed bumps. Without a strong vision and motivation by the founders and being “in love with the problem”, those speed bumps can instead appear to be roadblocks causing companies to change direction too early, causing a lot of “failing fast”, which is just a more acceptable way to say failing. The Thumbtack founders are a good example of grinding through these moments and not giving up on eventual product/market fit.
Many founders with vision put out a product experience and eventually find a market interested in that product solution. TikTok and Houseparty didn’t initially set out to build a product for children. Clubhouse started blowing up in Atlanta, and its founders are both in Silicon Valley. Square and Faire, however, had pretty strong ideas of their initial target markets and did find product/market fit with those markets.
Initial Launch Goals
The only goal of launching a product in the Eric Ries model is to generate feedback from the target customer. These launches are generally limited in size to receive enough signal from the target customers to know if something is working or not. The goal of a launch in the Rabois model is to achieve the initial vision that sparked the creation of the product. Launches are usually broader in this model, because the product may be looking broadly for a market that will be attracted to the product solution being launched. Even if there is a strong thesis for a target market, launches are more likely to go big to try to reach the maximum amount of the market possible, because the product should be ready to provide them value day one. In network driven businesses, a bigger effort out the gate may be required to reach the liquidity necessary for people to experience the product/market fit. In marketplaces, this may be sequenced by targeting supply or demand first, but with direct network effects, it is more driven by volume. Twitter and foursquare both launched at SXSW to get initial liquidity correctly. At Grubhub, whenever launching a new market, we would target to sign up 50 restaurants in the first two weeks to have a good selection to show consumers.
Changes to Vision
The Eric Ries model is very flexible on vision, and companies on this side of the spectrum frequently pivot around customer needs quite a bit. Instagram, Twitter, Groupon, Slack, Pinterest, GOAT and many other successes started in one direction, and through either failure, seeing only part of their initial idea work, or fresh thinking altered their product and mission dramatically to find product/market fit. In the Rabois model, a singular vision drives the company from the start. Opendoor started with a mission to remake real estate through data science and instant sales, and has not strayed much from that vision.
I think this is an area where despite all the news we hear about successful pivots that leaning more towards the Rabois model is a dominant strategy. Blindly trying out a bunch of startup ideas is like being in a dark room and feeling around for a door. A successful vision can turn on a light to that room so everyone can see the door and run toward it. Even many of those major pivots were guided by a strong, albeit new, vision from their founders.
Growth Strategy
The Eric Ries model thinks about product change as the main way to unlock growth in the early stages. This requires a tight feedback loop between customers and the team so the team can tweak and adapt and potentially built totally new things to please potential customers. You’ll typically see these types of companies leverage growth hacks that are long-term unscalable, but could get the initial product to more people efficiently. The Rabois model implies product changes will be more difficult. The product vision is usually taxing, so relying on product change to grow is very expensive. Rabois prefers to leverage a strong go to market model and heavy marketing muscle to scale usage of the product. Neither of these models go particularly in depth on scalable growth loops, and of course I believe thinking in terms of the scalable loops you’re unlocking is a dominant strategy.
Building a successful product and company is like producing a movie. You have a script and vision first and film the movie. Then you sell tickets.
— Keith Rabois (@rabois) July 22, 2019
Risks
It’s weird to talk about failure modes in starting companies as most companies do fail. But there are tendencies of failure types in each model that founders should be familiar with as they are avoidable. The Eric Ries model tends to lead to either iteration to no eventual destination or a lot of “failing fast” that feels like progress and isn’t. We saw a lot of this with startup studios five or so years ago. I can’t recall one of them creating an enduring company. The Rabois model has entirely different risks. This is where you can find solutions looking for a problem, like many crypto pitches you hear these days (how many ICO’s found product/market fit? Is there even one?). Some memorable failures in this area in the past are Color Labs and Clinkle. These companies can spend so much effort selling what they have really hard without ever confirming people want it. Startups in this area can also become so consumed in their vision they fail to actually launch. Magic Leap is a recent example of this in the AR space. The Rabois model can also hide some of the key insights to unlock the market if not careful. Instagram and Pinterest only had a small part of their original visions work, so they pivoted to focus on just that element to build massive businesses.
Applicable Company Types
While these models can be used for any type of business, they tend to lean towards certain models. The Eric Ries model is very common in enterprise businesses because founders are confident certain segments have day-to-day problems that aren’t solved and money to pay to create a reliable business model, so they learn all about that segment to find that problem with the willingness to pay to solve. The quick to launch elements are common in marketplaces where matching can be done manually to validate liquidity before investing in a lot of technology. The Rabois model is more common for hardware because iteration has such long timelines, and consumer models where typically founders have new habits or interactions they need to convince a broad market to try.
So Which Should You Use?
Hopefully, you see from these examples that either extreme is pretty dangerous, and even those that vehemently believe in one of these models over the other seems to have selective memory as to when companies veered away from their approach when appropriate. Founders should build a strong opinion over which parts of which model they need to apply to maximize the chance of finding product/market fit for their business. My personal belief is a strong vision combined with market feedback is a pretty dominant combination of these two approaches whereas many of the other axes depend on the product you are building. I actually find both models fairly weak on the growth strategy side. “Sell tickets” ignores how the product is frequently the most effective way to unlock growth through strong acquisition loops. Assuming new products equals new growth is a “build it and they will come” fantasy unless you get lucky.
—
The reason to understand what product/market fit looks like is of course important for founders of companies. While measuring the product/market fit line directly is impossible, measuring whether a company is above it or not is possible by measuring retention curves and new user growth. If the retention curves every month flatten and new user numbers increase at a healthy payback period, you can feel confident you have product/market fit. If you can’t say this for your product, I hope I’ve been able to give you some axes to understand what you need to work on and how to apply it to your specific product. The next problem is to scale it and keep as customer expectations continue to grow. If you want to learn more about these concepts, we expand on them dramatically in the Reforge Product Strategy program.
Currently listening to my Scrambled Eggs playlist.
Thanks to Kevin Kwok and Emily Yuhas for feedback on drafts of this post.
This is part three of a three part series on sequencing business models. This post is a collaboration with Gilad Horev.
In part two of our Sequencing Business Models series, we talked about the different types of marketplaces and what needs to be built to be effective in each of them. This builds on the first essay in the series of how there has been an increase in interest of SAAS-like models interested in becoming marketplaces over time. In that essay, we also talked about how a more common route for a SaaS business is to become a platform. Platforms can create an immense amount of long-term value for companies, or be a minor component of their product strategy to maintain product/market fit. In this post, we’ll talk about the different types of platforms and what needs to be true to create long-term success.
Bill Gates’s definition of platform has been widely popularized, but it has some problems. To repeat, Bill said:
A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it.
This quote outlines the extent to which platforms enable the success of businesses building on them. But as we try to define platform as a business model strategy separate from any other, we can see that this quote is incomplete as a definition. Assume your company manufactures and sells professional tools for plumbers. Presumably the aggregate economic value that plumbers get from the use of your tools is greater than the value of your company. If not, your tools are overpriced. But a wrench company is not what we mean when we say ‘platform.’
So, if a platform can’t be defined by economic value alone, how does one define it? Well, first, there are two distinct types of platform models SaaS companies tend to pursue, with drastically different chances of success and fundamental value for the company.
Integration Platforms
The first type is an integration platform. In an integration platform, the product integrates with other types of software the product’s customers already use. Integration platforms are ubiquitous in SaaS. It could be argued they are a requirement for long-term product/market fit in most industries SaaS companies compete in. Sure, if you are an upstart company like, say, Roam Research, you might not yet have an integration platform, but you almost certainly will build one as you scale.
If a SaaS company is going to build a successful integration platform, it will need to attract the right integrations that help their customers. Many times, SaaS companies adopt a “build the platform and they will come” approach that doesn’t work in practice. Even if developers do come, and they happen to build integrations that help customers; if incentives aren’t aligned between the two companies, lasting investment will not happen, and the integrations will be poorly maintained. Apps and integrations will simply break over time as the company and integrators reorganize, shift strategy or update APIs and functionality. Failing this test prevents a company from even getting started, and surely from sequencing to a more sophisticated platform model later. In fact, the quality of integrations can impact the customer’s perception of the core SaaS product. At Eventbrite, Gilad and his team found that many event creators who were actively using integrations didn’t even realize that they were engaging with a product built by external developers. From the customer’s perspective it doesn’t matter where the ‘product’ ends and the ‘integration’ begins—they are all part of one customer experience.
What is the right incentive for building an integration? Simply put, it’s when both the platform and developer think the integration will make their respective product better and more retentive for a segment of customers. If the drive for the developer is primarily user acquisition, however, the platform is more likely to end up with an ad than an app. There may be fewer developers who want to integrate for the right reasons than you would like, but volume of integrations shouldn’t be the goal. Incorrect incentives will lead to poor quality integrations. In the best case, those will result in lower usage and a disappointed developer. But the worst outcome is disappointed customers, and the mistrust of other integrations and even the SaaS product itself.
When kickstarting a platform, a SaaS company is creating a form of cross-side network effect. The demand side of the network should already exist. That demand is the base of SaaS customers using the core SaaS product. So, how do you create and manage the supply side? This is frequently done with a lot of business development work early on to get other companies to build integrations. An alternative is for the company to build integrations itself or to contract out the building. An increasingly common version of this is working with companies like Tray.io or Zapier to ensure the integration is successful and maintained. Having the right supply and quality decreases the risk of the network effect not kicking in. But, just because the demand side of the network effect already exists does not mean they naturally find and adopt these integrations either. Companies need to invest in discovery experiences for customers to find these integrations as well as shared documentation and co-marketing efforts.
What are examples of integration platforms? Pick almost any SaaS company, and you will find one. Successful examples include Slack, Gusto, and Docusign. In these instances, the integrations really do add to the experience, strengthening the product/market fit of the core product by either passing data or automating usage of the tools being integrated. We’re probably all familiar with the Giphy integration with Slack, but also Google Calendar, Google Drive, and Github. You may be less familiar with Gusto if you are not a small business, but they integrate well with every type of accounting software, point of sale system, or expense management tool you could possibly use. Docusign integrates with all sorts of productivity, sales and legal software. Go to almost any mature SaaS company’s home page, and you will typically find an integrations link in the footer.
Extension Platforms
Extension platforms are an evolution of the integration platform. First, let’s bring back Brandon Chu’s definition of an extension platform from the original essay:
A business that enables other developers to make your product better where the platform owns the relationship with the customer and provides some of the direct value itself
This is where the distinction between a marketplace strategy and an extension platform strategy becomes the most clear. A successful extension platform strategy takes your existing customers and makes them available as demand for external developers. A SaaS transition to a marketplace takes your existing customers and tries to help them acquire more demand. So, whereas sequencing to a marketplace adds a demand side and turns the SaaS customers you acquired into the supply side of the marketplace, sequencing to an extension platform adds a supply side and turns the SaaS customers you acquired into demand for external developers. This means two things in contrast to integration platforms. A company integrates with your integration platform because they believe it improves their product/market fit, primarily improving retention of their existing customers. In extension platforms, new developers build new businesses on your platform because your platform is a source of customer acquisition in addition to attracting existing businesses your customers already use.
Why should you care about extension platforms vs. integration platforms? Successful extension platforms are much more rare than successful integration platforms, but when they are successful they create fundamentally large business outcomes. Salesforce, Shopify, and WordPress are some of the most notable extension platforms. All of these platforms have billion dollar companies that have been built on top of them. Most operating systems like Windows, iOS, and Android are also extension platforms.
Why do extension platforms create such amazing outcomes? Well, in general, creating a cross side network effect enables the product to get better faster than the company can make it better on its own. Take Grubhub, for example. Initially, the key way that Grubhub got better for consumers was by acquiring more restaurants. When selection improved, the product experience got better. Extension platforms are a version of this phenomenon that is supercharged in two ways. First, while an incremental Grubhub restaurant is only useful to you if it delivers to your location, additional apps on an extension platform are more widely valuable–developers are not building apps for a 20 block radius. Second, every incremental app on an extension platform makes the platform and many of the existing apps more useful as a unit. An additional restaurant provides more choice, but either way you are only going to have one dinner a night. And you’re unlikely to order ingredients from different restaurants to comprise a better meal.
Just because a company has built a successful integration platform does not mean it can or should build an extension platform. Considering the practical differences between integration and extension platform helps clarify what is required for a given strategy. It helps diagnose where a company currently is, what order of operations might be, and concretely what to build, what not to build and where to invest. So first, let’s talk through the raw ingredients that seem to be required. Then, we can talk about the strategy elements that need to be defined to pursue this strategy correctly.
Extension platforms are most likely to be successful when sequenced from successful integration platforms. Why is that? Well, developers want to see other developers already being successful on the platform, and the easiest way to do that is to show successful integrations from companies they already know. So, if a developer sees that Dropbox is integrated with the platform, it will have much higher social proof than an unknown developer. In essence, independent developers need to see that the cross side network effect of the platform already exists before they try to create a new business on the platform. Shopify has remarked about how long it took their extension platform to start working because they did not have these proof points.
Unlike Kwokchain, we do our graphs in Excel, like professionals.
The second thing that needs to be true to have a successful extension platform is having a large volume of customers. If an external developer hopes to run a successful business largely on top of your platform, there needs to be a lot of potential customers for them to acquire on it. It’s actually even harder than that though. It’s not just about volume. The core product needs to support a wide variety of customers and use cases. Otherwise, developers believe they will eventually need to compete with the core product when the company builds that feature itself, and the platform will of course have an unfair advantage. External developers build on top of extension platforms when they spot an opportunity to monetize something for customers on the platform they know the company won’t build itself. Usually, this is because it is just for one segment, niche or country when platforms usually only build horizontal features. Practically, this means most extension platforms won’t materialize until the company is already successful internationally.
One other major factor that is rarely appreciated by companies pursuing this strategy is that the company needs a robust technology platform to support external developers. Developers are doing a cost benefit analysis. Why should they build on your platform? Yes, your customer base (i.e. their potential demand) is the biggest incentive. But if your technology is wanting and your documentation poor, the benefit is less likely to justify the cost. Developers will ask questions to figure this out. They’re going to inquire about your APIs, your SLAs, and your capabilities. If the company would be embarrassed to have to answer those questions, you may not be ready to build an extension platform. Wondering if you are robust enough? Ask your own engineers.
Now that we have defined the differences, let’s look at them on the same vectors as the types of marketplaces.
Click to view in more detail.
Supply Value Prop
Remember that supply in a platform is the group of external developers. In an integration platform, suppliers integrate with a SaaS company to improve their product/market fit, which increases their customer retention. For example, Mailchimp integrates with WordPress to make it easy for their customers to increase email subscribers from a WordPress site. In an extension platform, external developers do receive this value prop, but also list on the extension platform to find new customers. Acquisition becomes the primary value prop for the majority of developers. Shopify, for example, has multiple venture funded companies for whom the majority of their new customer acquisition comes from Shopify, like Shippo or ReCharge.
Demand Value Prop
Remember that demand in a platform is the SaaS company’s existing customers. In an integration platform, the main value prop of the customer is being able to integrate two tools customers already use so they can do things faster. Going back to the Mailchimp example, WordPress bloggers can integrate with Mailchimp to automatically send emails to subscribers when they post a new blog post to their WordPress site. Occasionally, an integration platform can make your customers switch to a tool similar to one that they already use if that integration is more robust. In an extension platform, customers look at external developers’ offerings for new functionality the core platform doesn’t offer. In an integration platform, the platform offers the ability to browse apps and search for specific integrations like “Evernote” or “Dropbox”. Think of this as the platform equivalent of branded search. In an extension platform, while branded search remains, a higher percentage of searches become unbranded search like “CRM” or “subscription.”
Payment
The question of control over the payment for platforms is similar to the one for marketplaces that we covered in the previous post. That is to say, when the platform controls payments, it has more flexibility to monetize the transaction, a greater ability to broker trust between developers and customers, and the ability to make the platform experience better for both supply and demand by improving payments. When Gilad evaluated this at Eventbrite it was clear that the benefits of owning the payment system didn’t outweigh the costs. Monetization of integrations isn’t a high priority since their primary value is in driving retention, trust is less of a challenge since most apps used by customers are known SaaS brands, and the experience of paying for integrations directly to the developer works well and is relatively infrequent. Therefore, at Eventbrite we chose to have the payment to the external developer happen off the platform. So, if an Eventbrite customer decides to integrate their Eventbrite account with SurveyMonkey, they pay SurveyMonkey separately from Eventbrite. That’s typical for integrations platforms—the SaaS customer pays the two SaaS tools independently from each other. However, in an extension platform, evaluating the same criteria usually yields a different result. Monetization is often a priority, the platform is generally far more trusted by customers than the majority of developers building on it, and the platform has room and incentive to improve the payments experience for customers and developers. So, in an extension platform, the platform typically is the payment provider for all developers selling tools on the platform and uses its own payments and billing infrastructure, like Apple’s in app payments.
Demand Side Branding
In an integration platform, there is heavy co-branding of the two companies that are integrating. Integrations pages feature logos of other successful companies extremely prominently. In an extension platform, there is still co-branding, but because so many apps are bespoke to the extension platform, they lead with their value prop rather than with their corporate logo much of the time.
The top result under popular WordPress plugins is “Contact Form 7”, and in tiny font it says who built it. Contrast to Slack, where their popular page is all focused on brands.
Customer Service
This is an area that trips up some companies as they build out platforms. Companies need to build out an entirely new type of customer service to a totally new customer: other developers. This includes API documentation and support. For a platform, external developers are a hybrid of customer and partner. So often, the support function will grow out of business development, which, as we discussed, is how most companies get the first partner companies to build on their integration platform. As a company continues to build out the platform though, the support structure begins to include dedicated API support, partner management, developer support engineers, and technical writers.
Trust and Quality
Once a company embarks on any platform strategy, it has to determine if the apps on it are actually driving customer success and satisfaction. For integration platforms, this potentially can be managed in an internally facing way where the company polices or deletes apps that are not successfully serving customers and promotes apps that have high retention or satisfaction scores. In an extension platform, this typically becomes externally facing to customers with ratings and reviews.
Refund Policy
In comparison to many marketplace models, refunds are mainly handled by the supplier, the external developer. In an extension platform, that refund is more likely to pass through the platform’s payment flow, meaning refund tools need to be built into that system for developers to leverage.
Fees
Integration platforms don’t typically charge fees to external developers to be on the platform. For extension platforms, this can become a significant part of the business model. Apple, for example, charges 30% for in-app payments, and mandates usage of in-app payments for many types of transactions. Shopify charges 20% for payments, but app developers can choose not to use their payment solution.
Committing to building an extension platform is a major strategic decision. It has implications for technical architecture, resourcing, the company’s own product roadmap, as well as its relationship with customers.
One major strategic difference between pursuing an extension platform strategy vs. a marketplace strategy is how decisions are made that affect customers. In marketplaces, companies tend to centralize decision-making over time. So, the dominant marketplace strategy is to deeply understand the market and your supply of customers and control more of how they run their business to streamline the experience for demand over time. Extension platforms require decentralization of decision-making. External developers will decide more and more of the product experience your customers receive over time by what they decide to build and maintain. You can incentivize developers to move in a certain direction, but not control them.
Do not make this decision lightly. In order to pursue this strategy, a company needs to have a good understanding of what value it wants to provide, and what value it wants external developers to provide, and to design the platform in a way that incentivizes external developers to work on the right things and not the wrong things. Then, it needs to create rules or boundaries so that in a decentralized world, the product offering still generally goes in a direction that is good for the company. A framework the two of us have used to talk about this is to ask four questions:
The best way to confuse a bunch of executives at a company is to ask the simple question, “what does this business need to own to be successful?” It sounds like a simple question, but it is most certainly not one. It’s a question all businesses need to answer, but particularly important for extension platform strategies as companies want to make sure external developers don’t build what the company needs to own. It’s a question Casey first had to answer at Grubhub, and subsequently at Pinterest and now Eventbrite. At Grubhub, the answer was the easiest. Grubhub had many partnership opportunities as they scaled, and they’d be willing to give partners data and allow them to build experiences that mutually benefited both companies. But Grubhub would never give partners customer data or delivery boundary data as that would allow partners to rebuild Grubhub more easily. Grubhub needed to own demand to win, and to keep proprietary data around restaurants to make the restaurant network functionality harder to recreate. At Pinterest, that question was harder to define, but as Pinterest developed an understanding of itself as a data network effect company, the user and pin data became a clear answer. Another common answer is owning the payment, which may be practical from a monetization standpoint, and for a marketplace, to enforce trust. This was true for Airbnb.
Deciding to own something means not owning it is an existential threat to the business. For example, at Grubhub Casey was part of a decision to reject integrating with Yelp because Grubhub would not have access to the customer data, and owning demand was the most critical component for Grubhub’s strategy. There are many other areas of a product you may want to own, but competitors are not existential threats, and there will be valid reasons your customers may want to use an external partner for them. We call these areas in which you want to compete. Shopify would love to own email marketing for all their customers, but know that some of their more sophisticated clients will upgrade to dedicated email providers with more functionality. So, they compete by offering their own email marketing tool, but also integrate with third party email marketing tools as well.
The attract category consists of things the company definitely will not build themselves, but wishes the core product would have to enhance value. For example, Salesforce does not build phone software, and they do not feel doing so would fit their core competencies. So they wish to attract integrations with call center companies sales teams use, so the data of length and volume of calls gets integrated into Salesforce. Dozens of companies and consultancies have since been created to enable this for Salesforce clients.
The repel category are apps the company does not intend to build, and they do not want external developers to build them either. For example, Apple rejects apps that disintermediate their relationship with developers, like Facebook Gaming, Google Stadia, and Xbox xCloud service.
Answering these four questions really well while developing a platform strategy can prevent many headaches in the future. Developers have plenty of examples of the rules changing on them because companies put off answering these questions like Apple’s recent spat on requiring in app payments with Hey and marketplaces that pivoted to online models during the pandemic, or Twitter’s numerous policy changes for bots, clients and monetization, or Shopify and Mailchimp breaking up in public. Just as platform companies want to avoid breaking changes for developers at the API level, they owe it to them to minimize strategic u-turns. Now, no amount of forethought can predict possible outcomes years into the future. A critique of the extension platform model is that more and more goes into the “compete” bucket over time, and the platform starts leveraging unfair advantages in that competition, like Spotify having to pay Apple 30% for in-app purchases, but its competitor Apple Music does not. Even with that critique, the more a company figures out how they want developers to be involved the less likely these scenarios are to emerge later. This is another danger of a “build it, and developers will come” approach to platforms. You may not like what they bring.
Wow. I’m literally stunned. Apple just doubled down on their rejection of HEY’s ability to provide bug fixes and new features, unless we submit to their outrageous demand of 15-30% of our revenue. Even worse: We’re told that unless we comply, they’ll REMOVE THE APP.
— DHH (@dhh) June 16, 2020
—
While many companies desire to be a platform, they don’t honestly know yet what that means for their business. While most SaaS companies need to add integrations over time, extension platforms have stricter criteria for being a successful long-term strategy and even stricter criteria for how to execute them well. Mapping these appropriately to your business and making the right strategic moves can be all the difference, and always superior to a “build it, and developers will come” approach that has plagued many companies interested in this direction.
Currently listening to my Ambient playlist.
This is part two of a three part series on sequencing business models. This essay is a collaboration with Gilad Horev.
Casey’s first sequencing business models essay talked about the transition from a SaaS business model to marketplace business model, and why it’s so difficult. In this essay, we’ll go deeper into the gradients of marketplace models that a company can sequence to, and as a follow up, we will do the same for platforms. Models on this spectrum may seem similar to each other at first blush. Especially adjacent ones. But sequencing between models is always hard, and failing to appreciate the practical differences between them makes executing that transition even harder. If the previous essay was about the organization, this essay is more about the roadmap.
If a company is thinking about sequencing into a marketplace, it’s important for it to understand that there are different types of marketplaces with different components. Having a good idea of what you’re sequencing to eventually is important, but also influences the transitions on how to get there.
In Casey’s last essay, he covered the differences between regular SaaS companies and SaaS-like Networks. Building on the definitions from that essay and introducing a few new ones, here are the types of business models we’ll cover:
We find it’s best to describe these marketplace types against each other on some common vectors.
Click to view in more detail.
Before we examine these vectors, it’s important to understand there is no one dominant business model, and the larger companies grow, the more likely they are to sequence to new or additional models over time. Google, for example, has an ads business, a vertically integrated hardware business for the Pixel and Google Home, a developer platform in Google Play, an enterprise SaaS product in Google Cloud, consumer subscription with YouTube Music and YouTube TV, and many light marketplaces like Google Shopping and Google Flights. So, which model a company might want to sequence to next depends on quite a few factors.
Now, let’s examine these vectors to help understand, as one type of business model, what it means to sequence to another over time.
Supply Value Propositions
Let’s start with the most important thing. If a business is a marketplace, it is selling incremental demand to customers as its primary value proposition. A business is SaaS or SaaS-like if it sells anything else software-related. If a business starts as a marketplace, it usually means demand is the most important problem customers need to solve. If a business starts out SaaS or SaaS-like, it usually means its customers have ways of driving demand and have other important problems software can better help them with. It could also mean the marketplace dynamics needed to drive demand are very hard.
When a business starts out SaaS-like—solving problems that are more important to customers than demand generation—the most common problems it’s usually solving is payments. Early on, when Gilad joined Eventbrite, accepting payment and selling tickets online was still the biggest challenge for event creators. Unless you were a very large creator who could afford complicated and expensive enterprise software, you were likely stitching together a PayPal merchant account and a spreadsheet. It was common for PayPal to limit these merchant accounts because they didn’t understand the risk profile of events businesses, and for the ticket buyers to endure a pretty unpleasant purchase experience. Eventbrite offered a simple, vertical specific solution to the problem. Like Eventbrite, GoFundMe, Patreon, and Kickstarter were also all about accepting payments for services or raising money online. The difference between them and a pure software payments business like Stripe or Braintree is that they are self-service meaning they don’t require integration work or code, are vertical specific, and both sides of the transaction interact with the service. Other common value props that SaaS-like businesses address are around managing inventory or calendars. Regular SaaS companies that are not ‘SaaS-like’ have many different value props, but they typically exclude those above. Normal SaaS companies have no relationship with their customers’ customers.
As we move to the right of the business model spectrum, the sophistication of value props offered to supply increases. A light marketplace usually offers leads or connections and leaves it up to the supplier to then close the transaction. The marketplace doesn’t vouch for the demand in any way. It’s a bit of a free for all. A lot of people in the industry tend to feel like this is an old business model that goes away over time as the internet matures. We’re not sure. It depends on the willingness of the market to pay for a more sophisticated offering. When price is most important to customers, they sacrifice quality. Just look at airlines.
Moving further to the right, leads gets replaced as a value prop by liquidity. As opposed to creating leads, liquidity requires more of a focus on matching and that the marketplace does work to ensure supply attracts demand. In the more heavily managed version, the marketplace offers a lot more services to facilitate the relationship with demand. They may personally handle delivery like Doordash, take on financial risk to reduce friction of transactions like Faire, or provide loans to suppliers to help them invest in growing their business like Uber tried to do, or do multiple of these services like Shift. In vertically integrated models, the suppliers work for the company, so they don’t have to offer loans or reduce friction. They just own all aspects of the delivery of the product or service.
Demand Value Propositions
For demand, the value proposition landscape is a bit simpler. If I am a SaaS company, I have no relationship with demand, and therefore offer them no value prop. For a SaaS-like network, it’s really about making the transaction with the supplier as efficient as possible. So, a company like Solv or Styleseat may make the appointment booking process really smooth, or a company like Indiegogo may make the checkout process clean and simple. Moving further to the right, a light marketplace will invest in basic search and contact flows. Managed marketplaces up that game by including not only the efficient booking/transactional flows of the SaaS-like networks, but they offer better search plus other discovery mechanisms. Perhaps curations and algorithmic recommendations, notifications, emails, saved searches, etc. They also create signals to help consumers navigate to the best options through elements like ratings and reviews. More heavily managed marketplaces oversee fulfillment and delivery to make sure it happens to the demand side’s liking. Vertically integrated models have everything standardized, not just supervised, to make sure it is delivered to the company’s specifications.
Payments
This is one of the more tricky areas as depending on where the company wants to sequence to over time, it will make different decisions on how to handle payments. If the company only ever aspires to be SaaS or a light marketplace, it will probably not invest in its own 1st party payments products. But if it’s, say, a SaaS-like network on its way to being some sort of managed marketplace, it will not remove its payment infrastructure as it starts to offer light marketplace value props only to rebuild them when it shifts again to a managed model. Why do many of these models care about owning payments infrastructure? Well, the simple answer is they monetize it, but that’s not really it. Payments also allow the company to enforce policies that build trust in the marketplace. At Eventbrite for example, where tickets are typically purchased well ahead of fulfillment, some of the first primitive, but effective, fraud rules Gilad and his team put in place naturally relied on controlling when funds would be exchanged between demand and supply. Moreover, with additional control over payments, the company can offer more bank-like value propositions to customers in the future. Common forms of this are advancing payouts ahead of fulfillment, loans or a stored balance that can be used for purchases of goods or services.
Consumer Branding
SaaS companies that provide software to business have no relationship with the consumer of that business, and therefore, no branding to them. SaaS-like networks have a relationship with the consumer, but that consumer is not considered their customer. So branding is more minimal, and many of these companies allow white labeling of their software that can be embedded on their customers’ websites. Once a company is officially a marketplace, consumer branding takes prominence, and many of these models may not even allow white labeling as it would hurt awareness of the marketplace brand and the marketplace’s relationship with the demand side. Owning demand is one of the biggest predictors of marketplace success, so this is a big deal.
Customer Service
Customer service in SaaS businesses may take different forms. But it usually includes self-service components as well as some ability to get manual support. SaaS-like networks do the same, but tend to find the majority of customer service requests are from their customers’ customers, who they don’t feel responsible for. So they try to have minimal support there, and push that volume directly to the supplier. Even many marketplace models like Airbnb and Etsy try to push customer service directly to the supplier at scale because demand-side customer service requests are very costly. But since the marketplace owns the relationship with demand, it is tricky to pull off. A negative experience will be associated with the marketplace no matter what, like a bad rental on Airbnb or a bad ride on Uber. Casey certainly felt this at Grubhub.
Trust and Quality
SaaS models and even light marketplaces are more of a “free for all.” The consumer risks transacting with a poor supplier, and the company doesn’t guarantee the transaction. We’ve all had sketchy experiences on CraigsList, but we don’t expect them to step in and fix it for us. Once a company moves to a managed model, there is an expectation that the marketplace tells customers who is safe to transact with and gives a lot of detail as to what to expect. The marketplace should fire people on both the supply side and the demand side who cannot be trusted to create a quality transaction. Even early on, when Casey was at Grubhub, they fired restaurants who gave poor service, for example. Uber riders and drivers with low enough ratings will no longer be allowed to use the product as another example.
Refund Policy
This is another tricky one. SaaS-like models see the supplier as their customer and let the suppliers create their own refund policies. This creates confusion for consumers who don’t understand why they would get a different level of support from the company, based on which supplier they chose. Light marketplaces are usually caveat emptor. Managed marketplaces, because they care about owning the demand, usually have very demand-side friendly refund policies and enforce a standard that supply must comply with to continue transacting on the marketplace. Heavily managed marketplaces usually have demand-side guarantees.
Fees
The broader trend you might have noticed is the further right a company goes, the more in general it is doing to manage the business. The only way to make this work is by charging more in fees. Different companies approach this differently, and will have their own mix of transactional fees vs. subscription fees, and vary in terms of how much is paid by supply vs. demand. But there is no way to move to the right of this spectrum without making more in the process to finance all of the extra services. The challenge some companies face when they want to move to the right is there is no extra money to be made from supply or demand to make that move profitable.
—
We hope this helps people building marketplaces understand the different styles of marketplaces out there and what that tends to mean for what a company has to build to be successful in them. Not understanding the spectrum of models means that companies can build the wrong things in the wrong order, preventing them from sequencing effectively. The same is true for platforms, which we will discuss in the next essay.
Currently listening to A View of U by Machinedrum.
My post on martech was surprisingly well received, so I thought I might go deeper on a particular area of martech that no one is happy with, but it seems very few people attempt to solve: marketing analytics. I’ll pull no punches here: marketing analytics is a bad business. Sure, there are successful marketing analytics companies, and you can definitely build a successful marketing analytics company now. But when people complain to me about marketing analytics, they complain about something specific; that the tools to help me understand how well my marketing efforts are doing are harder to use than they should be. Solving that is bad business. The reason is that great marketers don’t understand what most marketers are hiring analytics products to do.
What does an average marketer want at a larger organization? Cynically, I can boil it down to two things:
It really is that simple sometimes. Yes, there are marketers that are motivated by the truth whether it makes them look good or bad, and marketers who have recommended they should not spend money they are offered because they don’t think they can do it efficiently. I love those people (like the Eventbrite marketing team 🙂 ), but they are the minority. When you get to the enterprise, most people want one or both of the bullets above. So what do most marketing analytics tools that focus on understanding how well a marketer’s marketing efforts are doing actually do in practice? They tell the marketer one of two things:
They literally do the exact opposite role the marketer hired them to do. This creates the Marketing Analytics Death Spiral:
The addressable market for marketers who will be willing to have a tool show them how ineffective they are and will use that tool to improve over time is just too small. People who read my first post may ask: why not just change the target customer? Sure, you can target the finance team or the CEO, who may be less biased as to the effectiveness of a marketing team’s current programs. But then your product creates organizational friction between either two different functions or the CEO and the marketing function. This is a tough win condition for most forms of go-to market.
So what are companies doing instead in this space? Well, Amplitude and Mixpanel decided to focus on analytics for product instead of marketing. If product or engineering becomes the position of strength inside an organization, they can extend their tools into other functions like marketing over time. Many other marketing tools focus on making the marketer more efficient through automation. This makes them look better to their boss, which is exactly the job to be done for most marketers. Another variation that is successful is making something measurable in the first place that historically has not. This tends to solve job #2 for marketers of making budget available to them when it previously was not. For example, it was hard to measure mobile app campaigns before companies like AppsFlyer and Adjust came along, so no one was approving large app install ad budgets. Once these tools became available, marketers adopted them so they could prove their CPA’s were effective to get more budget.
—
The marketing analytics space is so tempting because budgets are large, and there are many unanswered questions. But you can’t forget the job to be done for marketers. If you’re not helping them look good or get more budget, your market size is going to be too small focusing on the few that are not motivated by that.
Currently listening to Let’s Call It A Day by Move D & Benjamin Brunn.