This post was originally posted on Reforge.

Two of the biggest challenges for a marketplace involve suppliers: acquiring them in the first place and keeping them long-term.

As a result, product leaders in marketplaces are constantly asking themselves how they can make their value proposition to suppliers more attractive and more competitive. While there are many ways to answer this question, there is one answer that is meaningfully more important than the rest: demand.

However, time and time again, product teams in marketplaces end up investing too much time into features that ultimately won’t be the differentiating factor for a supplier staying in the marketplace. And at the opportunity cost of investing time and resources into the core marketplace value proposition.

Let's dive into why  this happens and how you can build your marketplace without falling into this trap.

Why Marketplaces Build Supply Features

At a high level, there are three main motivations marketplaces have for building supply-side features.

1. Make the Marketplace Work

The first reason is that the feature is table-stakes; your marketplace doesn’t work without it or it is part of the baseline expectations suppliers will have about participating in your marketplace. For example, any marketplace that includes booking, such as Airbnb or Turo, requires a calendar function. Craigslist requires messaging; figuring out when and where to pick up an item is core to successfully completing the marketplace use case. If you are entering a market with a prominent competitor, their feature set might be part of the basic expectations suppliers have, and so you’ll need to build them to be competitive.

2. Fuel the Marketplace Flywheel

The second reason to build a feature is to fuel the marketplace flywheel. There are a few different ways a supply-side feature can do this.

1. Help suppliers drive more demand to the marketplace. For example, consider a built-in feature that lets suppliers email their customers. That feature may bring more of those customers on to the marketplace, eventually increasing marketplace transactions.
2. Make it easier for suppliers to put more supply on the marketplace. Marketplaces can incentivize their suppliers to provide even more supply to the marketplace by increasing the value or reducing the cost of adding more supply. For instance, an inventory management system may make it so easy to upload and sell items, and increase the share of inventory that suppliers offer and sell through the marketplace.
3. Unlock a whole new set of suppliers. This type of feature makes it possible for new types of suppliers to participate in the marketplace. For example, Lyft has a program that enables potential drivers to rent a car through Hertz and Flexdrive. This opens up a whole new set of potential supply that can be tapped as drivers for Lyft.  
4. Help suppliers grow their business. When suppliers have more resilient and thriving businesses, the marketplace benefits because suppliers are able to provide quality services to more consumers. For example, DoorDash has a program called DoorDash Capital, where restaurants can get an advance on their payments in order to invest in their business. Restaurants can “pay employees, cover unexpected expenses, upgrade equipment, and more.”

3. Create a SaaS value proposition

The last reason to build a feature is to create a SaaS-like value proposition for your suppliers. There are a few specific reasons marketplaces leverage a SaaS-like value proposition: to buy time when demand is not available as a value proposition, to add an additional revenue stream to the business, and to make it easier for suppliers to run their business.

OpenTable, for example, couldn’t offer demand as a value proposition for restaurants in the beginning. They started with a table management system that really helped restaurants improve their efficiency. This enabled them to acquire a quantity and density of suppliers that made the marketplace value proposition possible.

Etsy, on the other hand, has features that are bundled together in a subscription product. Sellers can pay a recurring fee for access to features like ads, shop customizations, and the ability for users to request re-stocks. Finally, SaaS-like features can resolve a pain point that suppliers have in running their business. For example,  the product team at Eventbrite invested in reporting tools for suppliers to make that part of the work more efficient, helping creators focus more of their energy on organizing great events.

While all of these can be strong reasons to start building a supply-side feature, the mistake marketplaces often run into is over-indexing on features that are mainly driven by a SaaS-like value proposition. In a marketplace, it’s critical to realize that features have to benefit suppliers and the marketplace rather than just suppliers directly.

The Supply-Feature Trap

It can be very easy to fall into the trap that supply features create: you keep investing in the feature, and end up focusing on a SaaS-like value proposition. This means you are trying to deliver efficiency or service improvements, and your competition landscape grows tremendously. This comes at the cost of focusing on creating more marketplace activity through incremental demand, and enhancing marketplace liquidity. And that is truly the biggest value add for the suppliers.

This happens because when you first develop a feature, the decisions you make are focused on ensuring that the feature works, is used, and is liked by users. If you can’t achieve that, it's certainly not going to drive larger marketplace goals. But without intentional adjustment, as the feature matures, you can fall into a cycle of continuing to invest primarily in the SaaS value proposition.

Whether you’re just starting on a new feature or realize you might be in the trap, there are a few things you can do to avoid over-investment in supplier features.

How to Build Features That Tie Back to Marketplace Value

There are three levers product leaders can use, separately or together, to build a marketplace where features tie back to marketplace value.

1. Metrics: Evolve the feature metrics to focus on marketplace value
2. Team charters: Leverage a product team charter to confirm the team is headed in the right direction
3. Product organizational structure: Ensure teams are focused on outcomes or user problems, rather than features

Evolve the feature metrics to focus on marketplace value

When a feature is being developed, there is a typical life cycle of metrics it follows. In the beginning, the metrics focus on ensuring the feature works, measuring things such as usage, usability and satisfaction. This is a good start to ensure that the feature is viable. Then, once you have confidence the feature works, the feature success needs to be connected back to the reasons you choose to build it in the first place.

There are three categories of metrics you can use to focus the feature on marketplace value:

• How the feature increases demand
• How the feature increases supply
• How the feature benefits liquidity (creates more activity in the marketplace)

We can consider three different features at three different marketplaces to showcase how evolving metrics helps features connect and drive marketplace value.

Email marketing tool at Eventbrite

Eventbrite developed an email marketing tool that allowed event creators to email their audience through Eventbrite, as many creators needed help marketing their events.

In the beginning, the team measured how many creators were using the tool and how many emails were sent. This aligned naturally with the focus on achieving the required functionality and experience that would get creators to use the tool.

The team did a tremendous job improving and enhancing the tool based on insight and feedback. But at some point, product leaders began to question whether each iteration of the tool was driving increased marketplace value. To avoid just thinking about the email tool as a feature that increases supply stickiness and retention, the team needed to shift focus.

So, the team needed to evolve the metrics to connect back to driving demand and liquidity. For example, looking at how much incremental demand and ticket sales are generated by creator campaigns sent through Eventbrite. Or, what part of that demand ends up buying a ticket to a different event on the marketplace.

Inventory management system at Faire

Faire is a wholesale marketplace for retailers and brands, and they have an inventory management system for its suppliers. When first building a tool like this, metrics like supplier satisfaction with inventory management could be a classic starting point to ensure the feature has functionality and user experiences that enable suppliers to use it successfully.

However, metrics should quickly evolve to focus on the desired marketplace outcome: how the system supports supply growth and liquidity. Evolving metrics could orient the product work on outcomes like how much inventory suppliers add to Faire and how much gross merchandise value is driven as a result.

Performance analytics at Amazon

Amazon has a robust Brand Analytics toolkit available for suppliers. While supplier satisfaction and usage of the tool are necessary, it's not sufficient for marketplace value.

The true value is in how the product helps suppliers succeed on the marketplace: by encouraging sellers to use Amazon ads effectively, informing pricing decisions and deals, and even supporting decisions about which product to add to their portfolio.

Evolving the metrics can be a helpful tool to refocus the team or product manager on what is important about the feature in relation to the marketplace. If you’re just starting out with a feature, having a strong hypothesis of what the future metrics will be should be part of your case for building the feature in the first place.

If you are finding that you have features that are mature and still aiming for usage and satisfaction, you should go through the exercise of understanding how they should support the marketplace and start measuring that.

Leverage a product team charter to connect to the marketplace value

A product team charter is a short document where a team recasts their understanding of the team goal and how it connects to the company strategy. So in any business model, it can be an effective tool to ensure the team’s scope and objectives are well-defined and in line with the business goals. However, it is even more effective and helpful for product leaders that are balancing a lot of complexity.

Reviewing a team charter can be a quick gut-check on if the team is connecting to marketplace value or is pursuing feature excellence in more of a silo.

For example, a product team that is building the email marketing tool for an events marketplace should not be trying to build the best marketing product hands down. Immediately from that goal, a product leader can see the feature is not going to be focused on driving marketplace value.

A closer version of the product team goal could be to build the best tool for event creators, as it narrows the scope to be effective for the target suppliers, but it still does not explicitly show the connection to the ultimate marketplace value that should be driven by the feature.

An example of what might be a more nuanced goal for this team is: Build the best marketing tool for event creators that enable them to attract new demand to our marketplace. This provides constraints to ensure that the team is focused on the right target audience and working in service of a marketplace value proposition.

One of the best reasons to leverage a team charter is it forces each product manager to develop the habit of thinking in service to the marketplace and working backward from outcomes.

Especially as the marketplace scales, it will be critical to have product managers who are able to critically analyze the value of their work, raise flags if features are potentially moving too far away from delivering marketplace value, and come up with creative ideas for the marketplace that are not restricted to specific features.

Ensure teams are focused on outcomes or user problems, rather than features

Finally, product leaders can use organizational structure to reinforce the target behaviors and mindset within a team.

Individual product teams, regardless of if they are organized by alignment to stakeholders (supply side or demand side), value drivers, or steps in the user journey, should never be exclusively responsible for a feature.

While it might seem like the fastest or easiest way to get a feature working, putting a product team on a feature creates a laser focus on how to create the best version of that feature. Instead, product leaders should focus teams on a goal or user problem, and the feature can be a part of the product roadmap to achieve the goal or solve the problem.

“No team should be dedicated to a feature. Teams should align to goals or user problems.”

— Ben Lauzier, former VP of Product at Thumbtack

At Lyft, for example, they created a team around the “scheduled rides” feature. This is a feature where a potential rider can book a driver in advance, for a certain time, location, and destination. While the initial goal was to prioritize the ability to reliably schedule rides, the team quickly ended up in a spot where they were shipping features with minimal impact on the marketplace.

Orienting a team around a goal or user problem is a forcing function for them to think about trade-offs around value, rather than trade-offs around supplier satisfaction.

Once the scheduled rides team realized they had lost sight of the original user problem, they went back to first principles: they oriented around a core user problem and found meaningful unlocks in new areas.

Maximizing Marketplace Value From Supplier Features

There are many strong reasons to build features for suppliers, but unlike in a SaaS business, it is critical for marketplace product leaders to be aware of how much they are investing in those features and to constantly evaluate the value those features are driving toward marketplace value.

Product leaders can rely on evolving metrics to connect to marketplace value, tasking product managers to be diligent about their mission statement in a team charter, and ensuring product teams are aligned around outcomes. These different levers help ensure you are building a marketplace that is set up for success, and they can also help you get out of a situation of over-investment.

‍To dive deeper on how different features could connect to growth and business value, you can apply to Reforge and check out the Growth Series program.

For marketplaces, choices about payment processing are often really about business models and product strategy. How a company builds in payments impacts the ways it can capture value, create trust, and even achieve product-market fit.

In this essay I’ll cover the different options marketplace companies have for building payments into their product and how to choose.

Types of marketplace payment solutions

The different ways a marketplace can enable supply and demand to transact fall into three categories:

• No payments: when the company directs supply and demand to exchange money outside of the marketplace.
• 3rd party referral: suppliers are required to obtain a merchant account with a payment processor and link that account to the platform to transact.
• Embedded payments: a variety of different solutions where suppliers onboard as merchants with the marketplace. Control over how merchants get paid and how funds flow through the system are up to the company.

No payments

The first thing to consider is whether a transaction on the marketplace needs to involve an on-platform payment at all. If facilitating a payment transaction is not high on the list of problems that customers need you to solve for them, there are real advantages to offering no in-product payments solution; it means that a company takes on no payments risk and has no integrations to build or maintain. That translates to development, operations and additional resources that can be spent focusing on other things.

Of course no in-product payment limits the product’s utility. Not only does the transaction itself have to happen off-platform, but related functionality for both demand and supply, like order management and financial tools, won't exist either. Other downsides are that there’s no opportunity to monetize payment processing and no way for the company to control the transaction.

Creating trust without payments

With no control over the transaction, a company is limited in its ability to arbitrate. It can’t prevent bad transactions, force refunds, or withhold payouts from suppliers. Just compare the confidence consumers have purchasing from sellers on Amazon Marketplace with the learnt vigilance Craigslist customers must adopt to avoid being scammed.

But certain types of marketplaces can achieve a sufficient level of trust without controlling the movement of funds. Thumbtack uses high quality ratings and reviews, pricing information, structured leads and other tactics to create enough trust so that pros and consumers connect initially. If they can do that, it’s via chat, on a subsequent phone call or at an in-person meeting, where consumers and pros really size each other up. And the value exchange takes place off platform -- a common pattern for a Light Marketplace. 

Third party referral

A marketplace can direct suppliers to get a merchant account from a 3rd party payment provider and connect it to the platform. So, for example, when Substack writers want to offer a paid newsletter they link a new or existing Stripe merchant account. When a supplier’s merchant account is linked in this way, the company gets limited control to do things like make a transaction and take a fee. As for everything else -- payouts, chargebacks, reporting, support -- that’s all between the merchant and the payment provider directly.

The leading solution of this type is Stripe Connect Standard. But there are others and many processors will offer an OAuth solution that can grant a platform permission to take action on a merchant's behalf.

When is 3rd party referral the right fit?

For many marketplaces, the limited control over the way funds flow makes the referral model too restrictive. For others it’s the goldilocks ‘not too hot, not too cold’ balance between offering payments in-product with little investment or risk. If the following are true, it’s a good sign that this model may be ‘just right’:‍

Simple transactions and simple fees: Because the transactions are actually happening on linked merchant accounts that belong to each supplier respectively, there are only very specific things that the company is authorised to do with the money. So you should only consider this setup if transactions are going to be between one buyer and one seller at a time (i.e. you don’t need consumers to fill their cart with the merchandise of several suppliers), and if you expect to charge a simple predetermined fee per transaction. Generally speaking, anything more elaborate than that won’t work well.‍

Building trust through payments is not critical (at least not on day one): A 3rd party referral setup lets a buyer make a purchase through the platform. However, consumers still have to deal directly with the supply side to get resolution for things that go wrong after the purchase; like disputes for example. The company has more visibility and can intervene to a degree, but it’s limited and doesn’t ultimately control the exchange of funds. For this reason a 3rd party referral setup is not a fit for a marketplace where trust vis-a-vis payments is key to the value prop. For example, StockX -- where trust is the value prop to both sides of the marketplace -- couldn’t exist with a referral solution.

For marketplaces where trust via payments is not a blocker for getting off the ground, a 3rd party referral setup can help avoid or defer a lot of development work and payment risk. For Airbnb and Eventbrite, trust is obviously incredibly important. But both still started out directing the supply side to create a PayPal merchant account and link it to the platform. The two marketplaces later graduated to an embedded payments model where they could broker trust and really control the transaction.‍

Your suppliers ‘get it’: By choosing a 3rd party referral setup, you’re requiring suppliers to manage a merchant account in order to use your product. That works if your supply side can handle the complexity. But if they are mostly casual sellers or a user type who would find that burdensome or confusing, then you may want to go another way. That’s one of the reasons that Facebook Marketplace offers both ‘no payments’ (i.e. pay off platform) and an embedded solution to sellers, but no 3rd party referral option. For the type of supply they’re targeting, managing a merchant account is a barrier and overhead.

Embedded payments

With an embedded setup, the supplier’s experience—from onboarding through processing to payout—is so tightly integrated (or say, embedded) into the product that they can’t tell if there’s a 3rd party in the mix at all. An embedded solution allows the company to determine the timing of payouts to supply, split the funds more flexibly (whether its between multiple parties, or across complex fee logic), and to make a margin on payment processing. 

With control comes risk

With the added control over the flow of funds, the company can arbitrate between supply and demand. That makes an embedded solution a good fit for a Managed Marketplace. 

But with that control come added risks: the company is ultimately responsible for disputes and chargebacks. As opposed to the 3rd party referral option, where chargebacks are between the suppliers and the 3rd party processor. Here the marketplace is in the middle. That means that the company has to build fraud detection as well as tools and operations to resolve disputes, and chargebacks and fraud losses become a part of doing business.

Full stack vs. mix-and-match

Stripe Connect Custom or Express, and Adyen for Platforms are examples of a full-stack embedded solution -- one product that provides an end-to-end embedded infrastructure. But a company may also choose to use several payment partners and piece together it’s embedded solution to varying degrees. For example, instead of using Stripe as a sole partner, a company could use Hyperwallet for onboarding and payouts, and separate partners for payment processing. Etsy uses primarily Adyen and Worldpay for accepting payments, has built its own onboarding and KYC program, and pays out sellers through different banking partners.

An embedded solution already requires a larger development cost than a referral solution does. Piecing together that embedded system with multiple vendors is even more of a technical and operations lift because the company has to worry about the connective tissue bridging the different components. Things like reconciliation systems, logic for routing transactions to different processing partners, a vault, working out a compliance program, tracking balances, funding accounts, and reporting, are all things that you could rely on a single full-stack solution for, and may become more complex with multiple partners. For mature, Heavily Managed Marketplaces -- some of which are basically a vertical specific neo-bank -- it may be a relatively small investment in the grand scheme of their fintech aspirations. But for most companies, supporting this added complexity can be challenging.

So why would a company today consider piecing it together rather than just using a full-stack solution? There are two main reasons:

• Flexibility to choose and customize: When evaluating payment partners you may find that certain capabilities justify the complexity of a separate integration (or even building certain components of the system yourself). For example, Stripe might be hands down the best solution for your product, except that in order to serve your customers well, you must offer PayPal or some new payment method that Stripe hasn’t integrated. It will add some complexity to your system and operations, but it may be worth it.
• Redundancy in the system: Some companies have a particular vulnerability to single-sourcing payments and need redundancy. For Patreon this type of problem came up when the company’s payment partner, Stripe, determined that creators on the platform were selling pornography (in fact, it was Wells Fargo -- a party up stream of Stripe -- but the consequences were the same). To solve this problem and protect the creative freedom of its supply side, Patreon integrated another payment partner, and selectively routed transactions through them and to a separate merchant ID (MID).

What about payment facilitation?

Becoming a Payment Facilitator (PayFac) is a special type of embedded approach. You can register to be a “Payment Facilitator” and onboard merchants on behalf of a sponsoring acquirer. It’s simpler than it sounds. Basically, as a PayFac, instead of using a 3rd party payments provider, the company steps into that role itself and becomes responsible for merchant onboarding, merchant screening, settlement, risk and compliance.

The work to build all the infrastructure, apply for the licenses, and create the compliance programs that are required to operate as a PayFac is large, expensive, and slow. There are companies like Finix and Infinicept that are making it simpler by providing infrastructure and tools, but it’s still a huge investment.

Payment Facilitation wasn’t built with Managed Marketplaces in mind. It enables card processing, but no alternative payment types, no transaction splitting, no compliance shortcuts, and no access to the other financial services that embedded 3rd parties provide out of the box. Simply put, Managed Marketplaces should not choose a PayFac setup. 

In a previous essay I defined a SaaS-like Networks as a software company that supports interaction between business customers and their end consumer.  That’s who the PayFac model is really better suited for.It’s best for large SaaS-like Networks, like Shopify or Quickbooks, that want to provide sellers a competitively-priced, white-labled payments solution. 

But even for the SaaS-like Network use case, it’s much harder than integrating an embedded 3rd party solution. So, why do it?

• For better economics: Being a PayFac can save a company ~40-100 bps on processing costs. But only if a company has a large enough GTV will the added margin justify the fixed costs associated with becoming and operating a PayFac. And even then, the opportunity cost may be too large.‍
• To compete with payment providers: If the payments component of a company’s business is competing against other payment providers, that’s a good clue that it may want to consider being a PayFac. By creating Shopify Payments, the company started going head-to-head with other payments companies both on and off the Shopify Platform. Simply embedding another 3rd party solution wouldn’t do -- to compete at that level a company needs to get closer to the bare metal. So, while Shopify Payments uses Stripe APIs and infrastructure, it operates as a registered PayFac.‍
• To ‘own’ the sub-merchants relationship: Certain companies value having a direct relationship with their sub-merchants without a 3rd party in between. That way they can avoid being in the position where someone else could deactivate their customers’ accounts or limit them. And when the company is doing onboarding itself, there’s no need to re-onboard sub-merchants or create discontinuity for them if the company ever wanted to change providers.

Choosing the right payments solution

A company’s business model is the primary driver of payment processing choices. As the business model evolves, a company may also need to change its approach to payments. Early on, Thumbtack had an in-product embedded payments solution, which was later removed once it decided to focus on a lead-gen model. Care.com started out monetizing via a demand side subscription. That model fits its senior care business well. But for the babysitting business -- a more frequent, shorter term use case with less disintermediation risk for the company -- Care.com chose a transaction fee model and, to enable that, built an embedded 3rd party solution.

Most other considerations are related to product experience. How much control over payments does the company need to create trust? What payment tools and experiences are required for product-market fit? What payment solution will make sellers most successful?

The answers to questions like these aren’t the same for every company and even for a given company they may change over time. Airbnb started with a referral solution for payments, and that enabled early success. But as the company grew and could invest more development and operations towards payments, it phased to an embedded solution that allowed it to govern marketplace dynamics and trust more effectively and to provide a simpler product experience for both sides of the marketplace.

As a company optimizes for product experience, it’s got to also set itself up for long term maintenance and improvement. Payment products are getting better and the industry is moving pretty quickly. So ensuring that you have the right partners and editing out integrations or customizations that have become unnecessary is an ongoing endeavor. At Eventbrite, we’ve updated our payment stack in some meaningful way every few years. It’s not necessary or wise to jump at every minor improvement or new payment method right away. But as payments companies innovate it’s smart to take note and ensure your product and customers aren’t left behind.

--

Thanks to Yael Barak and Casey Winters 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 Casey Winters.

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.

The Types of Platforms

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.

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.

Common Platform Vectors

Now, let’s examine these vectors 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.

Extension Platform Strategy

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:

• What does the company need to own?
• What does the company want to compete to win?
• What does the company want to attract?
• What does the company want to reject?
  

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.

--

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.

This is part two of a three part series on sequencing business models. This post is a collaboration with Casey Winters.

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.

The Types of Marketplaces

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:

• SaaS: software that businesses access online and purchase via a subscription e.g. Slack, Adobe, Atlassian
• SaaS-like Network: any number of different models where a business sells software to businesses online and that software supports the interaction between the business customer and their end consumer. The business does not charge via a subscription, but rather fees are transactional or pre-revenue e.g. Square, Styleseat, Mindbody
• Light marketplace: a network model focused on transactions that happen without facilitation by the marketplace. There are two common modes here in lead gen and peer to peer e.g. Zillow, Thumbtack, Craigslist
• Managed marketplace: a network model that facilitates transactions between supply and demand by processing payments and ensuring quality of transaction by establishing trust e.g. Etsy, Ebay, Airbnb
• Heavily managed marketplace: a network model that facilitates transactions by participating in the delivery of the transaction in a meaningful way e.g. Uber, Amazon, Faire
• Vertically integrated: The company owns or directly employs the “supply” e.g. Clutter, Oyo, Honor
  

We find it’s best to describe these marketplace types against each other on some common vectors.

Common Marketplace Vectors

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.

How a manager leads through a difficult or unpopular action will shape their relationship with their team. And the way that they represent and contextualize these moments can also impact the team’s relationship with the company.

As I help PMs and other managers on my team navigate these situations, I talk about cheap popularity. I want these leaders to see that cheap popularity creates different management challenges down the road, and ultimately, I want to help them find authentic ways of bringing their team along, without undermining their responsibilities to represent the broader company and its leadership.

When I say cheap popularity, I mean influencing and finding allegiance by commiserating, expressing inappropriate pessimism or mistrust, placating, or pandering to the team. This type of behavior compels a manager to overlook some of their key responsibilities: instilling confidence, clarity, and trust in their team or reports. 

Seeking cheap popularity can look like several things. We’ll address two types:

• Fostering skepticism about a strategy, roadmap, or decision. It looks like this: a leader hides behind more senior managers to justify a tough decision, or explain why the team has to prioritize a project they’re not confident in. The leader says things like “I agree with you. I’m sooo mad ＼(｀0´)／ But that’s what they’re telling us to do ¯\_(ツ)_/¯”.
• Failing to hold the team to standards that will require them to hustle, push, or step outside their comfort zone. It looks like this: a manager feels uncomfortable demanding something from their team and fears potential rejection. So he or she establishes expectations in a way that conveys that they’re merely following instructions from above, or softens the demand so much that they sacrifice clarity.
  

Cheap popularity may have an immediate positive payoff—the team feels soothed by commiseration, or safe in the promise that they don’t have to deliver a complete solution. But this is no way to lead for the long term. Managers may not even realize they’re setting their teams up to be distracted, uncertain, or under-performing when they’re sending these cues. That’s why it’s so important to give it a name and teach managers well.

In this post I’ll share how I coach managers on recognizing cheap popularity. I’ll cover the motivations that might tempt us into it, its negative impacts, and some advice on how to avoid it.

We all want to be liked. What’s wrong with that?

Leaders use cheap popularity tactics because they want to be liked. But as a leader, you don’t get to distance yourself from the organization’s strategy or its decision-makers for fear of rejection by your team—even if you personally disagree with the direction. This can be hard. It can feel inauthentic. But authenticity doesn’t mean full transparency and saying whatever is on your mind. 

You also don’t get to lower expectations to keep people happy or avoid uncomfortable conversations. Having high expectations, owning them, articulating them clearly, and helping your team achieve them is how you drive results. And failing to do that effectively, means simply that your team is unlikely to reach its potential.

But when a leader shows that they're disconnected from the true decision-makers; or they fail to get the most out of their teams, they are systematically undermining their own authority. The result: your reports will learn to circumvent you. Because what’s the use of a middle-person? If your team sees you grumbling about a strategy or project you don’t like, rather than disagreeing and committing, you can’t really expect them to feel good about working on it with you. And eventually, if they see this behaviour from you a couple of times, they’ll model it too. Your team will be less likely to trust you and commit when, inevitably, there comes a time when they disagree with you.

Cheap popularity also inhibits your ability to fix problems and impact the larger organization. If you’ve complained about the company strategy to your team, or pinned blame unproductively, or rolled your eyes at a person or function or group; good luck trying to create positive change in the organization. Say that you’ve declared that the adjacent dev team is a hopeless, sloppy bunch. All they do is introduce bugs that your team then has to clean up. You may have made your team feel good about being the heroes that saved the day, but the adjacent dev team is now less likely to be receptive to your feedback, and you’ve diminished your ability to make things better. You may have scored some short term relationship gains by commiserating with your team. But you haven't actually solved anything for them. 

Navigating the temptation for cheap popularity 

There are a few things that can help you avoid succumbing to cheap popularity, and to navigate situations when you need to represent an unpopular message or move in a direction you don’t fully support.

Criticize the right way. 

Disagreeing and criticizing is not a cheap popularity tactic! You just need to express dissent in the right way. That means find the appropriate place and time for it, and avoid doing it when the target of that criticism is absent. It also means being intellectually honest. The goal should be arriving at the best decision possible, not reserving the pleasure of saying ‘I told you so’ further down the road. It’s human to get this wrong from time to time, so debrief with yourself. Was that a constructive thing I just said? Would I be happy if anyone at the company had overheard me? Engaging in critique and debate shows your team that they can trust you to advocate for and affect change when you disagree, and that you’re not just a shill whose job it is to convince them to do things they don’t want to. 

Disagree and really commit. Then explain it to your team.

Once you’ve decided to disagree and commit, it’s your job to sell it into the team. If you’re hedging because you haven’t really committed, it does two things: It confuses your team about whether or not they should be all in. And it reduces their confidence in you, making it seem like you’re powerless to correct a bad decision. You’ve got to reliably, without bias, convey to your team the business context and rationale for the decision you disagree with. When you personally object, you may be tempted to just pass down directions without adjusting the message to fit your team and getting them engaged. Perhaps you’ll be inclined to simply rebroadcast the motivation for the decision precisely as it was shared with you. That doesn’t count as committing. Spend extra time understanding the decision deeply, and translate the justification for the decisions into a narrative that is relevant and compelling to your team. Hey, who knows? Maybe by the time you’ve done all that you’ll agree a little bit more.

Choose your moments.

Some conversations are best left between you and your manager. That can give you both more flexibility to change your mind, and can save your team from the distraction of following the play-by-play. Part of the manager’s job is to both represent the organization to their team, and their team to the organization. Situations where these two constituencies are at odds are often best resolved without an audience, because they can become cheap popularity traps. For example, assume an area of responsibility needs to be reassigned, and you don’t think your team has the bandwidth. You know that aside from your input, you also need to learn about the tradeoffs for other teams and company priorities. And either way, it’s not completely up to you. Sure, you can explain any outcome to your team. But choosing who to bring in and when, will help avoid demoralizing narratives like “my manager goes to bat for her team, but this company doesn’t listen...”.

Enlist your manager.

Nobody wants to put you in sticky situations that push you into being disloyal to the organization. Chances are, that if you told your manager that it’s going to be difficult for you to sell something into your team, they’d be able to help. That might be enough of a reason to change course, but at the very least your manager could assist you with messaging, or offer to provide more context to your team directly. Even if none of that is possible, surfacing the challenge could inform other decisions pertaining to your team further down the road. 

--

You don’t have to act like you’re not the manager to demonstrate that you’re a member of the team—that you understand, empathize, and are not living in an ivory tower. It’s important to internalize this lesson, because the temptation of cheap popularity often shows up when nobody but the manager and their team is around. Managers need help learning the difference between authenticity and cheap popularity; between things that nourish a strong relationship with their team, and the empty calories that erode trust in the long run. In a strong company culture, employees respect and like their managers, but not at the expense of trusting the next layer of management or the company.