Tag Archives: strategy

Finding the Next Wave of Growth: S-Curves and Product Sequencing

I’ve had the pleasure of speaking at TCV’s Engage Summit the past two years. The Summit gathered ~40 CPOs and product leaders to chat through topics centered around product development and product-led growth. This year, topics ranged broadly from incorporating AI to deliver world-class consumer experiences to defining and measuring different forms of community-powered growth. I never posted my talk from last year, so I’m adapting it into a blog post here, and will do the same for this year’s talk in the following weeks and as well as some follow up questions from the Summit I’ve had a chance to ruminate on.

Also, I publish on Substack now! So subscribe here.

After product/market fit, most companies’ obsession is not thinking about how to create their next amazing product. Their obsession is thinking about growth. Specifically, how do I get this product I know is valuable in the hands of everyone it can be valuable to. Most companies have a primary acquisition loop that drives this scalable growth, and unfortunately, there aren’t that many acquisition loops that really scale. Even when they scale, they eventually asymptote, and companies need to find new ways to grow. This can be new growth loops for the same product, or entirely new products. In this post, I’ll explain how to think about the timing of that, and show some of the successes and failures of my career.

As I have discussed in previous essays, product/market fit can be hard to interpret at the time. When you find product/market fit, problems don’t go away. Customers don’t stop complaining. In fact, they complain more, because they like the product enough to care. What they stop doing is leaving. And you start being able to acquire more of them in a scalable way i.e. an acquisition loop.

Because of this and other factors, when you find product/market fit, you can’t stop iterating. Product/market fit has a positive slope. If you find product/market fit and don’t continue to make the product better, a rising competitive landscape and customer expectations can have you fall out of product/market fit over time. But when you do achieve product/market fit, while you don’t stop iterating, your portfolio of what you work on needs to change.

At Reforge, we talk about the four types of product work. Once you find product/market fit, zero to one product/market fit work goes away entirely for a while as your portfolio shifts to different types of product work:

  • Features: improve current product/market fit
  • Growth: connecting more people to existing product/market fit
  • Scaling: being able to scale the product to more users and more teams internally
  • Product/Market Fit Expansion: new segments, markets, and eventually products


The growth work in particular becomes a major focus, strengthening and discovering new acquisition and engagement loops. Most companies when they find product/market fit with their first product only have one acquisition and engagement loop that is successful, and the job of most of the team is to refine and scale those loops. At Pinterest, I was originally in charge of building a new acquisition loop built on top of Google. It looked like this:

We eventually re-architected our engagement loops to be based around personalization instead of around friends. When you stitch these acquisition loops and engagement loops together, it creates a more complicated growth model that looks like this:

The acquisition loop now feeds new users into a personalization loop that increases engagement over time, and emails and notifications reinforce that loop by distributing relevant content to users outside the product to bring them back. The entirety of Pinterest for the first few years I was there was tuning these loops in one way or another. Eventually, the company needed to layer in new advertiser focused loops to monetize, but I’ll skip that detail for now.

When I arrived at Eventbrite, the company was a lot more mature than when I started at Pinterest. But similar to Pinterest, it started with one acquisition and engagement loop driving its growth.

Creators market their events to bring in new ticket buyers. Many of those ticket buyers, once introduced to Eventbrite, start creating events themselves. And when event creators are successful at selling tickets, they come back and create more events. But Eventbrite didn’t stop there. It kept investing in making its overall growth model stronger.

Why did they do this? Well, all growth loops eventually asymptote. If you get good at modeling your loops, which basically takes the diagrams above and turns them into spreadsheet based forecasts of the impact to your business, you can start to predict when they will stop driving the growth the company needs. Modeling both helps you predict when those asymptotes will happen and unconstrain those loops by finding their bottlenecks and alleviating them. At Pinterest, we 5x’d conversion rate into signup over time, and doubled the activation rate of signups to engaged users over time as a couple of examples.

Some constraints in your growth loops can’t be fundamentally unconstrained by optimization though. The company requires either new growth loops or new products to acquire, retain, or monetize better. Modeling your loops helps you start investing in building out those new growth loops or products well in advance of when you need them to sustain your growth, because of course developing them takes much more time than improving a current loop. We think of this as sequencing different S-curves of growth.

By my arrival as an advisor by 2017 and CPO by 2019 at Eventbrite, the company had layered on many more acquisition loops onto its original loop to continue to grow, creating a much more complicated growth model.

Now, I know this looks complicated, but all that is really going on here is Eventbrite took its monetization of ticket sales and re-invested all of that money into new acquisition loops to bring in more event creators (sales, paid acquisition, content marketing). Also, Eventbrite took the increasing scale of event inventory created on the platform and started distributing it themselves to drive more ticket sales per event to places like Google, Facebook, Spotify, and its existing base of millions of people who had bought tickets to previous events.

People don’t talk enough about how much S-curve sequencing work went on at all these successful companies, so I wanted to give you a taste of what it looked like across my experience at Grubhub, Pinterest, and Eventbrite because it’s a lot, and a lot of it didn’t work. Let’s start with Grubhub summarizing ten years of decisions that both helped and hurt Grubhub as it scaled to be a public company (+’s show up where I think the decision helped, and -’s where I think the decision hurt):

  • 2004: Grubhub co-founder collects menus of Chicago neighborhood restaurants, scans them, and puts them online (+)
  • 2005: Grubhub expands to cover all of Chicago (+)
  • 2006: Grubhub launches online ordering from restaurants (+)
  • 2007: Grubhub optimizes sales model and expands into second market (+)
  • 2008: Grubhub unlocks demand side channels and refines expansion playbook (+)
    • Grubhub launches Boston and New York (+)
    • Grubhub landing pages for restaurants that deliver to X start ranking well on Google (+)
    • Grubhub unlocks paid acquisition to drive demand (+)
  • 2009: Grubhub scales market launch playbook (+)
    • Grubhub switches from flat fee to percentage model (+)
  • 2010: Grubhub launches pickup (-)
    • It doesn’t find product/market fit and hurts delivery use cases (-)
    • Grubhub now launching at least one new market per month (+)
  • 2011: Grubhub acquires Campusfood and launches restaurant websites (+)
    • Grubhub acquires Campusfood to expand to many college markets (+)
    • Grubhub acquires Fango to build in-restaurant tech (+)
    • Grubhub launches restaurant websites to drive in-restaurant growth (+)
  • 2013: Grubhub acquires Seamless (+)
  • 2014: Grubhub goes public and starts building a delivery network to compete with Uber and Doordash (+)
    • It doesn’t matter as those companies raise billions of dollars to destroy Grubhub’s network effect (-)

What you can see here is despite a successful outcome of an IPO and $7.6 billion exit, Grubhub made a lot of mistakes. If you strip those mistakes out, the sequencing of S-curves looks like:


The main lessons that matter here to me are that Grubhub tried product expansion too early with pickup. But market expansion became a major strength and well oiled machine through sales and SEO expertise as well as strategic M&A. That strategic M&A failed them, however, in responding to the threat of delivery networks. Grubhub was integrating its largest acquisition when Doordash and Uber Eats rose to prominence, and while Grubhub acquired over a dozen companies, it never acquired the one that was truly disruptive (Doordash).

Okay, let’s do Pinterest in the same format:

  • 2010-2011: Founder visits DIY/Craft Meetups and convinces Influencers to start “Pin It Forward” Campaign (+)
    • This gets people to learn how to use the “Pin It” functionality in their browser (+)
    • Pinterest uses Facebook Sign-In to bootstrap network of friends as more people join the platform (+)
  • 2011-2012: Pinterest leverages Facebook Open Graph to share every Pin into users’ Facebook feeds (+)
    • Pinterest starts to amass enough content to make discovery, not saving, primary value prop (+)
    • Retention and frequency of use improve (+)
  • 2013: Facebook turns off Open Graph and growth stops (-)
  • 2014: Pinterest fails to unlock growth with new products, but does unlock User Generated Content distributed through SEO (+)
    • Pinterest launched a maps product, a Q&A product, and a messaging product, and all fail to drive growth (-)
    • Pinterest finds another channel in Google to distribute its high quality content to after Open Graph turned off by Facebook (+)
    • Users come in with less match to existing network, so friend graph ceases to drive ongoing discovery. Retention decreases. (-)
  • 2015: Data network effects kick in (+)
    • While friend graph ceases to work, Pinterest now has the scale of content to recommend great content just based on users’ interests. Moves to interest, not friend based discovery. Retention improves again. (+)
    • Pinterest pauses all U.S. work to make sure we unlock international markets (+)
    • Pinterest tries to re-ignite user sharing and fails (-)
  • 2016: Pinterest crosses 50% international active users (+)
    • Focus shifts to building advertising business to make money (+)
    • Growth team starts seriously experimenting with paid acquisition as new channel (+)

Despite Pinterest being worth *check’s today’s stock price* $21.5 billion on the public markets today, you still see a lot of the mistakes we made. Too much new product development that didn’t pan out and too much trying to regain what we had lost vs. leaning into new areas that were working. Network effect products rely less on new product innovation unless it’s the only way to monetize. And Pinterest tried the harder expansion before the easier ones. Market and category expansion tend to be much easier than product value expansion. But, Pinterest did make a very successful pivot from direct network effects to data network effects and from Facebook to Google as the primary distribution channel. When you strip the failures out, our success looks like the following sequence:

Okay, for the last one, let’s do Eventbrite:

  • 2006: Eventbrite launches to allow event creators to accept payments online (+)
  • 2007: Event creators start putting $0 in the payment field to create free tickets, driving huge awareness (+)
  • 2008-2012: Eventbrite builds more features to help event creators run their business and includes them in ticket fee (-)
  • 2012: Eventbrite builds sales team to scale to more upmarket event creators (-)
    • Eventbrite launches new countries with sales-led strategy (-)
    • These countries never build the self-serve growth motion of the U.S.
  • 2016: Eventbrite launches consumer destination to help consumers find events (+)
    • SEO landing pages featuring events in different cities become large drivers of ticket sales (+)
    • Eventbrite begins scaling emails to consumers of events they might be interested in (+)
  • 2017: Eventbrite launches packages and acquires Ticketfly to move upmarket into the enterprise music segment (-)
    • Packages makes Eventbrite more money in the short turn, but drive churn and less acquisition over time (-)
    • Many Ticketfly customers are a poor fit for Eventbrite from a service / functionality perspective. Segment is low growth. (-)
  • 2018: Eventbrite acquires Picatic to build developer platform (-)
  • 2020: Pandemic hits, and Eventbrite rewrites strategy to focus on independent, frequent creators and help them grow
    • Focus on self-service and helping creators drive demand
    • Cancel separate music product and developer platform
  • 2021: Eventbrite launches Eventbrite Boost, a suite of tools to help creators improve their own marketing
  • 2022: Eventbrite launches Eventbrite Ads to help event creators reach more consumers searching for events on Eventbrite

Since this shift is happening in real time, I’ll describe the S-Curve sequencing Eventbrite was investing in as of the end of my full-time role. The value prop is shifting from payments and ticketing to helping event creators grow their ticket sales. Eventbrite has launched new pricing with tools like marketing tools that help event creators get better at their own email and performance marketing as well as let them get more distribution inside Eventbrite’s platform. The revenue from this will help drive more investment in the consumer product side of Eventbrite, which hopefully drives more consumers looking to Eventbrite to find things to do and buying more tickets from our creators.


Hopefully you see from these examples that sequencing S-Curves to drive growth of companies over the long term is not only quite difficult, but the craft of doing it is under-developed. All three of these companies made some critical successful moves as well as major mistakes that set them back years. I hope that by studying these and other examples startups can get smarter about how they sequence their S-Curves and drive long term success for their companies. In my next two posts, I’ll go deeper on how to think about how platform shifts like AI affect this and publish a lot more on when and how to invest in building your second product successfully.

Currently listening to my Rhythym & Bass playlist.

And don’t forget to get on my Substack list for future posts here.

Founder Intuition vs. Team Expertise vs. Customer Expertise

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.

Five Ways to Address Complexity In Your Product

In Crafting The First Mile of Product, Scott Belsky talks about the product lifecycle. In it, Scott states:

  • Users flock to simple product
  • Product takes users for granted and adds more features for power users
  • Users flock to simple product

Now, myself and others have written before about different ways you should attempt to defy this second step. Let’s say you’ve listened. How do you then keep your product simple while trying to grow, capture new audiences, and add new value props? Is the solution to… not do any of that, like a Craigslist? Seems like that doesn’t work too well given all of the companies that have attacked Craigslist from different angles and built bigger businesses than it. Is the solution to ignore Scott’s warning and rely on network effects or some other deep switching costs to retain users? This isn’t a bad idea, and why companies like Facebook continued to grow despite adding more and more complexity over time. During this time though, Facebook users also flocked to Instagram, Snapchat, TikTok, et al. Is the solution to rely on humans to help customers navigate the complexity? Sounds expensive.

This is one of the key challenges we faced at Eventbrite when we radically shifted our strategy in 2020. Eventbrite was historically a 50% sales and 50% self-service business. The optimal outcome for a business like that is a “good enough” user experience with account managers that can make up its flaws. This is a very common strategy for enterprise companies with large margins. The problem for Eventbrite is we weren’t an enterprise company with enterprise margins. We work with small businesses and independent creators. Talking to humans is a bug, not a feature of what to them should be an intuitive user experience. And these SMB’s and independent creators don’t pay us millions of dollars individually to profitably employ armies of human help.

So, as we decided to take a bet on building an intuitive, self-service experience instead of masking user experience issues with human support, we really had to confront Belsky’s product lifecycle for the first time. Eventbrite over the course of the last decade built out a multitude of different features for all different types of event creators, of all shapes and sizes. We did not have a simple product for event creators at all. It had become quite complex.

When people think of simple products, they typically think of consumer products. That is usually where one looks to find the current peak in user experience. There has been a renaissance of user experience and design in B2B use cases over the last decade, but those typically revolve around single use case products, like:

  • Syncing files in Dropbox
  • Sending emails in Mailchimp
  • Setting up a website in Wix or Squarespace

Creating an event on Eventbrite should feel like that; the problem is how vague the definition of event is. Eventbrite has small meetups, large conferences, niche networking events, merchandise drops, music festivals and everything in between. If you can think of it, we’ve ticketed it. There are only a few types of files to sync, emails to send, or website use cases. Our cases were myriad.

So, how do you solve this problem? At Eventbrite we have surveyed a few different approaches I‘ll showcase below as well as what we think works best for our use case. Our initial approach to solve this problem was to just put the creator first. We designed something we called the adaptive creator experience that learned what type of creator you were, what features you valued, and automatically customized the experience for the features you needed front and center. This made for a great vision, but was practically untenable from a data or scale perspective. So what are the practical approaches to solve this problem? Let’s cover each below.

Approach #1: Validate and Unbundle (Temporary Complexity)

When Eventbrite acquired Ticketfly, we originally attempted to separate the experience into something we called Eventbrite Music. There, music specific features wouldn’t complicate the experience for, say, someone doing their first event for ten people. The more we learned about the Music space, the more we learned it wasn’t the features that needed to be radically different, though that sometimes was the case. It was more that the aggregate user experience that music clients, especially more traditional ones, wanted was incompatible with a self-serve user experience. They wanted very detailed interfaces, dedicated training for dedicated employees that only worked on that part of their business. The concept of creating not different features, but different interfaces, felt like a much larger complication to support. Eventbrite now caters toward more modern music creators that share the need for intuitive and self-service experiences. With Eventbrite’s new strategy, we didn’t really see an unbundling approach based on functionality given our two products on the creator side (ticketing and marketing) are already so intertwined in creators’ workflows, and we no longer differentiate creators by vertical as it didn’t map to product needs well.

Facebook was a different story. One thing Facebook did very successfully as it scaled functionality was to prove out the value of features in its core app and then unbundle them into separate apps later on. This keeps their user interfaces, especially on mobile, more focused and easier to navigate. Facebook has now done this with multiple features across Facebook and Instagram. It hasn’t always worked, but that is usually because the product/market fit of the product isn’t always strong enough to survive on its own e.g Facebook Local (failure) vs. Facebook Messenger (success). Uber did the same exact thing with Uber Eats. I have written about this strategy before here.

The pros of this strategy seem pretty obvious. Leverage the scale of the initial product experience to expose people to the new value prop, confirm product/market fit, then move that new product experience elsewhere so the new value prop’s added complexity doesn’t deteriorate product/market fit for the initial product. The issue with this mentality is that once a product is unbundled, it no longer receives as much new user acquisition from the initial product it was built inside of, and sustainable acquisition loops are a key part of product/market fit. Facebook has notably not spun out Facebook Marketplace or Facebook Watch, likely for this reason, and sunset Facebook Local after initially spinning it out. Many app developers tried to launch multiple apps as part of a trend called app constellations, and pretty much all of them failed because user acquisition is really difficult, or they failed to create product value (read more about this here). 

Approach #2: Progressively Disclose (Temporary Simplicity)

One of the key strategies we took at Pinterest to solve the first mile problem was to remove functionality from the initial experience to make sure new users could learn the core concepts. Advanced features like group boards and messaging were not available to new users until we saw that they understood how to save content and access their boards. Once we confirmed the user activated, we started to give them access to the entire product, confident they could handle the increased complexity. This is a form of progressive disclosure to prevent new users from being overwhelmed, but only delays the complexity problem to beyond the activation period. To be clear, this was a very successful strategy for Pinterest, and a dominant approach to new user activation, which is why so many growth teams have dedicated activation or onboarding teams that leverage techniques like this. But it only delays the inevitable complex product in the hope that users are better prepared for it. This is a particularly ineffective strategy when there are more permanent differences between the complexity needs of different users, more common in business use cases like ours at Eventbrite.

The inspiration we were able to take from this approach is progressive disclosure work typically calls into question whether certain features should exist at all. Eventbrite had accrued many features of questionable value because a creator here or there used them. We started aggressively deleting such features in 2020, which helped make the product and code base less complex. We had much success with deleting features entirely at Pinterest as well, and I have written about both feature deletion and successful onboarding in the past. The next phase of leveraging this concept for Eventbrite is radically simplifying our onboarding flow to help creators understand what value we offer before they have to switch their entire business over to it. This is a big investment that will take multiple quarters to get to a great spot, but it is worth it. Still, it doesn’t fully solve Eventbrite’s complexity problem.

Approach #3: Train the User (Hacked Complexity)

Every designer strives for an ultimately intuitive user experience. And I’m sure we’ve all seen that quote that say if a design needs an explanation, it’s a bad design. I often think, has anyone who’s said that quote tried to design software before? This stuff is hard! My preferred saying is a design with education is better than a design that doesn’t educate. Having this aspirational north star of intuitiveness is important for any design team, but it’s okay to admit you’ve fallen short of that lofty goal and leverage other tools to set up users to be successful. Using people and or prompts in the experience to ensure users are successful is not shameful; it’s smart. Eventbrite is in the early stages of leveraging proactive communication and still learning, but we have found that contextual prompts or offering to get on the phone with creators that have demonstrated they intend to use the product at scale can be pretty impactful. People-based strategies do not scale, but they can at least be profitable if they are gated on the value of a customer.

Approach #4: Segment User Experiences (Optional Complexity)

In business use cases, it is less likely that the average user matters, and instead, there are different levels of complexity required for different users. This can be admins vs. normal users or small vs. large accounts to give a couple examples. The more standard approach today to dealing with the very differing needs by user type is to proactively set up user types as part of a complex team-based onboarding, as is common with enterprise products. For products that achieve bottoms-up adoption, this is more likely to be achieved by different packages that segment different types of users. For example, a base package may only have a few features and a low price, and a professional package may have more complex features that would only confuse base users, but are valued by professional users so much that they are willing to pay more than the base package for them. This can be pretty successful when segments are easily identifiable, but when segment needs diverge from clear product delineations, it can create issues. Also, managing separate user experiences by user segment can be hard for engineering and design teams to scale.

Eventbrite launched a more realized package framework in 2017, and found that it failed to map to the different types of creators as elegantly as they initially thought. It turns out features cannot be mapped that easily to different segments just by scale, and that package changes had implications on the entire Eventbrite growth model, not just monetization, since so many creators start initially as ticket buyers in the ecosystem. Segmentation is something that is mapping more neatly to Eventbrite’s marketing tools, which are frequently purchased in a subscription. They work less well for Eventbrite’s ticketing business that deals in transactional costs where features help drive extra sales.

Approach #5: Make Advanced Features Discoverable (Perceived Simplicity)

Segmenting user experiences addresses differing levels of complexity needs when there are easy to identify segments, but what if the same user needs the simple product most of the time, but more powerful features only occasionally? The package based approach will present the user the complicated product every time even though the base product would be a better experience for them most of the time. 

A solution many self-service products attempt is to preserve the simplicity of the core product, but make that additional complexity immediately available on the rare occasion it’s needed. WhatsApp is a great example of this in consumer products. The main interface of WhatsApp is optimized around text-based messaging. It is simple to view chats and reply, and to most users, they need no education to figure out how to do this for the first time. However, WhatsApp actually has a lot more powerful features than this. You can record messages, call people directly via audio or video, leverage emojis, attach images, and take pictures. When you need one of these advanced features, I bet it takes most users less than a second to find them in the interface, but these features don’t crowd the interface for the baseline use case of text messages.

It is very difficult to preserve this level of complexity while preserving a simple interface, and WhatsApp may be the best I’ve seen at it. But it’s important that designers strive for this level of intuitiveness in the face of product evolution, and not retreat to lazier methods that denigrate both the user experience and business performance. Square at one point redesigned their interface to make it a lot simpler, hiding most advanced features behind various settings. The new interface was simple, but users could no longer find a lot of the features they wanted to use, and business metrics suffered. That is not what success looks like. Britelings are probably tired of me using the WhatsApp example, but it is our north star for how we tried to build creator products. Simple for the 99%, surprising and intuitive power for the 1% use cases.

The higher the ARPU, the more you can use direct contact to train users. The lower the ARPU, the more scalable your solution to complexity needs to be.

–
There is no easy way out of the product lifecycle. Like scaling a culture, it requires a lot of intentionality to scale a product without losing the simplicity that drove so many people to it in the first place. At Eventbrite, we continually strive to make our user experience powerful, yet simple, and we frequently fail to achieve our own expectations. Hopefully, the approaches above help give you some options to manage complexity in the user experiences you own to improve the value for your customers.

Currently listening to my Uptempo Instrumental Hip-Hop playlist.

What Type of Job is This: My First Year as Chief Product Officer

I have written about the Chief Product Officer role in the past, and why the job is so hard. I also wrote about being a product leader during a crisis. But not much is written about starting as a new product leader. So, I thought I’d write a post about my first year as CPO, and share some general lessons. First, a reminder of the situation I started in. I had been an advisor for Eventbrite for about two years, so I had a lot of comfort with the CEO and many of the executives before ever starting the role. I believe this is an underrated way to start new roles for senior people because you can de-risk the culture fit and alignment issues that plague many new executives. When I started advising Eventbrite, the company had a business unit structure, so it didn’t even have a CPO role, but product leaders embedded into different business units. The company reorganized functionally, and created this role and asked me to consider it.

What Type of Job is This?
I believe the most important question a product leader needs to ask when they get started is what type of job it is they have to do. I wrote in the past that there is frequently a misalignment on vision vs. execution roles. There may also be a misconception of what type of product work is needed to help the company i.e what the product strategy should actually be. In the Reforge Product Strategy course, we teach that there are four different types of product work:

  • Feature development: adding new things to the product that improve value proposition e.g. Uber’s Split Fare
  • Product/market fit expansion: adding totally new products that create new value propositions e.g. Uber Eats
  • Growth: tuning the product experience so more people can connect to the current product’s value prop e.g. Uber improving driver onboarding
  • Scaling work: tuning the underlying technologies or process to help the product and team continue to be effective e.g. Uber rearchitecting its data pipelines

Old school product leaders would just do their preferred type of product work even if it wasn’t what the company needed, or adopt a primitive portfolio approach to the four types of work even if part of the portfolio was wasted work e.g. building a ton of features for a network effects business, or doing a lot of growth work for a pre-product/market fit product. As a modern product leader, it’s important to understand based on the company and its lifecycle, what type of product work has leverage, and these crude approaches are usually not the best approach.

Usually, the best place to start is looking at what the company is actually working on right now. In Eventbrite’s case, the company was:

  • Integrating the acquisition of Ticketfly to move up-market in a specific vertical and build an enterprise sales motion
  • Building a consumer marketplace to drive incremental ticket sales to event creators
  • Paying down technical debt with duplicate versions of Checkout and Create
  • Launching a developer platform so external developers can add more features for Eventbrite’s broad base of event creators
  • Launching new SaaS products with its incubation arm

Julia, our CEO, had told me she wanted me to focus on growing the self-service business faster. So, first off, what you should notice is that there are too many things going on for a company of Eventbrite’s size (sub one thousand people). In other words, the product strategy lacked focus. So, I had to spend my first few months understanding these different strategies to understand which ones to focus on. So I gathered as much information as I could about these different strategic initiatives, as well as digging into the core self-service business.

What Was Going On With the Core Business?
The core self-service business was growing steadily at significant scale and was profitable. Most of the sales clients we brought in stressed our product/market fit, which we compensated for with manual services at no charge, straining margins. We didn’t have a good sense of who our self-serve customers were, how we acquired them, or what retention looked like. As we dug into these questions, we found that while Eventbrite’s product/market fit was strongest with making it really easy to host a single event, but the bulk of our growth and profit was coming from frequent creators hosting small events very often. So, while the product roadmap was scaling for size of event, the market was scaling with frequency of event. The product did not handle this frequency very well, causing these event creators to hack the product to get what they needed, and a higher churn rate over time as those hacks proved problematic to execute. The gaps in our product to strengthen product/market fit for these creators didn’t seem insurmountable, but none of them were actually on the roadmap.

We also were able to get a clear picture of the core competencies and competitive advantages of the Eventbrite product. The fact that Eventbrite supported events of all types and wasn’t focused on one vertical e.g. conferences meant the company had a scale of data no other company had. Secondly, the self-service acquisition model meant the product had very low acquisition costs overall. That model was also a good fit for many different types of creators. Lastly, the company had leveraged its scale of events to drive consumer demand through channels like SEO, emails to previous ticket buyers, and distribution partnerships with companies like Facebook and Spotify.

What Did the Team Say?
As I talked with the team about the state of the product and what they were actually working on, let’s just say the team had a lot to say. Breaking it down by project:

Upmarket Music Vertical Expansion
We tried to integrate music customers too quickly into the Eventbrite platform, and we were much further away from product/market fit with the more traditional enterprise approach those customers were used to than we thought. The space is low growth and low margin, and relies on enterprise sales, relationships, and high touch human service, which doesn’t match our self-service capabilities well.

Consumer Marketplace
Frequent creators drive most of the inventory consumers are interested in, and if frequent creators’ efficiency tools on Eventbrite don’t work for them, they will leave the platform even if they sell extra tickets because of the platform. This is an interesting strategy, but needs to be sequenced after we have a great product experience for frequent creators.

Technical Scaling
Internal developer productivity was incredibly low due to low level of investment in developer tools. Our infrastructure was rickety and frequently had stability problems during big “on sales”. Multiple versions of every feature made it hard to build new things quickly and at high quality. We never deleted features because some sales clients use them and would complain. Everything we build is an MVP, and we rarely iterate.

Developer Platform
While the strategy of leveraging external developers to build specific features for a large array of customers with different needs makes sense at Eventbrite’s scale, we internally lacked the capability to service our own engineers well, much less external developers.

New SaaS Products
Many of these products are very far away from product/market fit and do not have a path to scalability. There is one partnership related to creator marketing tools being run out of this program which is doing well though, and it has been easier to talk with creators about that than our marketplace demand.

Developing A New Product Strategy
Strategy is about making choices among many options that optimize across a few key dimensions like:

  • Company Focus
  • Business Model
  • Target Customer & Market
  • Competition
  • Core Competencies & Competitive Advantages
  • Consequences & Risk
  • Sequencing

Eventbrite failed to make a lot of hard choices with its product strategy when I arrived, so it was time to make some tough calls on what to focus on. There are no simple answers here, but in evaluating the initial strategy, it became clear we should do the following:

  • Upmarket Music Vertical Expansion: We are too far away from product/market fit trying to rebuild the Ticketfly model, and there is little margin or growth to be had once we get there. There is a lot of competition, and the go-to market approach leans out of our core competencies. It felt like we were trying to win the music industry’s last war instead of building a more technology-forward experience many up and coming music venues would appreciate. We need to focus our music creators towards a self-service experience like the rest of our product, and if that means that some of the less tech savvy customers won’t come with us on that journey, that’s okay.
  • Consumer Marketplace: The product needs to have a good experience for frequent creators before they will value our demand, and we should probably help them improve their efforts to drive their own demand first. Sequence to this strategy when frequent creators are in a good state.
  • Technical Scaling: Developer velocity is the purest form of leverage in a software company. We should be investing more in this area so we can increase our strategic appetite over time.
  • Developer Platform: If we are not providing a great experience for our own developers to build great features, we are even less likely to provide a great experience for external developers. Pause until our technical infrastructure is in a much better place.
  • New SaaS Products: Creators drive the majority of ticket sales through their own marketing efforts, and they are not expert marketers. Our knowledge can help them improve and automate their efforts. Cancel everything else in this area.
  • Core Self-Service Growth: Make the product experience great for frequent creators of small events as they drive most of the profit for the core business. We are not far away from strong product/market fit here.

The new product strategy is remarkably simpler and more sequenced over time:

2021

 2022

2023

Frequent Creators

 Marketing Tools

Consumer Marketplace
Technical Scaling Technical Scaling

Technical Scaling

Frequent creator investment will be measured by improved frequent creator retention. Technical scaling will be measured by internal developer velocity and our say/do ratio. Marketing tools and consumer marketplace will both be measured by revenue from those sources. So, going back to what type of job this is, my initial directive would have made this product leadership role to be primarily about growth. Instead, the focus is on scaling with some product/market fit expansion. 

Your Product Strategy Probably Isn’t That innovative
One dirty secret behind the work of many executives and product leaders is that our strategies aren’t that innovative. There are a few playbooks we generally run to improve performance in companies depending on the business situation after we’ve gathered the right insight. You can run through them and rule most of them out like the con men strategies in Ocean’s 12:

Yes, product leaders also rule out strategies because we don’t have enough people or can’t train a cat that quickly.

The new Eventbrite strategy was a combo of two common strategic playbooks. The first part of the strategy is what Chris Zook calls “profiting from the core”:

“The greatest strategic error stems from an inaccurate understanding of the core and its full potential.”
-Chris Zook, Author of Profit from the Core

However, if you’re an Arrested Development fan, you might call it the “there’s always money in the banana stand” strategy. The idea behind this strategy is that many companies as they scale pursue too many expansion strategies and leave behind growth that is closer to their initial core business, plays more to their core competencies, and requires less work and less risk to execute. Eventbrite was pursuing expansions in verticals (music), business model expansion (SaaS), and value props (driving demand) while ignoring improvements that could help the growth of the core product (features for small, frequent creators). At Pinterest, VP Product Jack Chou ran a version of this he called “make the basics great”.

The other component of the strategy is probably most known from a blog post (and soon to be book) by current Snowflake and former ServiceNow CEO Frank Slootman. In Amp It Up, Frank Slootman basically divides up his strategy into three elements:

  • Improving velocity
  • Raising standards
  • Narrowing the focus

Personally, I would flip the order and revise the language to be more software specific:

  • Improve focus
  • Raise quality bar
  • Reduce tech and design debt (usually the biggest hurdle for velocity inside software companies)

By the way, if you’re a public market private equity investor, and you aren’t running this strategy on every sub-rule of 40 tech company, I have a question for you.

So, in Ocean’s 12 language, Eventbrite is running a banana stand combined with a Slootman Special. We… may need to work on these code names. Recently, Etsy has run this same strategy combo to grow its market cap from $2 billion to $25 billion in four years after many years of no market cap growth at all.

There is one other element to Eventbrite’s strategy, and that is presented by the table above: sequencing vs. parallelizing. There is a reason Eventbrite started to pursue a lot of these adjacent opportunities in the first place: fear the core business could not grow itself fast enough. But in trying to pursue multiple adjacencies at the same time, it not only failed to make the progress it wanted on any of them, but many were not set up for success because they would gain from other strategic elements of the plan already having been completed.

The goal of this post is not to geek out on all the generic strategies, though I could do that all day, but to give a sense of the work new product leaders need to do to understand strategy and make it explicit to the organization. Frequently, there is a mismatch between what the customer or business needs and what the team is working on today. Usually, by talking to the team, your customers, and looking at the data, you can identify the mismatch and position the team toward a more likely to be successful product strategy. Then, product leaders can move to the meat of the role, which is building and optimizing the structure and processes of the team to execute against that strategy more effectively over time, or adjusting to changing market dynamics *cough* pandemic *cough*.

Currently listening to the Housewerk EPs by Tusken Raiders.

Fire Every Bullet

In crisis situations, a new style or management and prioritization has to occur. Andy Grove famously called this “wartime”, and he and others like Ben Horowitz have described what it’s like to be a “wartime” CEO. I haven’t ever seen anything written about being a wartime CPO though. Being a wartime CPO means a lot has to change in how you approach building product. Most product leaders think about their team as the product, and they continue to iterate on their team through hiring, training, coaching, delegation, etc. In wartime, you’re not hiring, you don’t have time to train or coach, and you make more top down decisions. But there’s one big thing that needs to change for wartime CPOs I want to cover today, and that is prioritization and evaluation.

I hope you never have to be a wartime product leader. But as you might have surmised, Eventbrite has been in a wartime situation for over a year now. Let me give you some background. In February 2020, Eventbrite started to become aware of a big problem. While the company was off to a fantastic start to the year, we could see the tidal wave of a global pandemic coming. Neither the world, nor us, was ready for what our metrics were showing could happen: the global shutdown of the live events industry. We were about to go to war, but not against a competitor, instead against nature.

There were, of course, differing opinions about the severity of the situation. The media was making fun of VCs for banning handshakes and telling us to be more worried about the seasonal flu, but the media failed to take into account the true potential downside. When the downside is unknown and potentially disastrous, as Nassim Taleb would say, the only rational reaction is over-reaction.

We planned for our mission, to bring the world together through live events, to be tested like never before. We acted swiftly to ensure the longevity of our business and mission, and the wellbeing of our employees, creators and investors. We launched resources and tools, we increased communication to keep employees informed, engaged and connected, and we realigned cost structure and secured access to funding. We also re-wrote the strategy of the business to align to this new reality.

More specifically, on the product side, we shifted all of our focus to help our creators prepare for the reality of a global pandemic and what that meant for their businesses. As we got to work, I recalled a conversation I had with Luc Levesque years ago when we brought him on as an advisor to Pinterest. Luc was the VP of SEO at Tripadvisor at the time (now VP Growth at Shopify), which was the only American company I could find that had succeeded at international SEO. Pinterest’s biggest impediment to growth was international growth, and SEO had been our primary lever to get U.S. growth into good shape after our initial strategy of leveraging the Facebook Open Graph stopped working. I was asking Luc whether we should prioritize different tactics to make international SEO work like international link building, localizing our URL structure, or making sure only content in local languages showed up on a page. His response was basically, “Dude, you do ALL of it.” We could figure out which one mattered the most after we’re successful. This is the approach we took at Eventbrite when the pandemic went into effect.

We built every possible thing we could to help creators and the company. We helped creators pivot online through virtual events; we published information on how to apply for loans; we built a bulk refunds tool, introduced the ability for creators to pay-in or wire money to Eventbrite to refund consumers and a credits system, and an easy postponement tool. We fired every bullet we had at the pandemic problem. We did not prioritize. It didn’t matter how much effort each activity was. We were going to do it all, and do it fast. We released things that would not meet our normal quality bar, because the only thing better than releasing these features for creators today would have been releasing them yesterday. We later learned other companies were doing the same.

One thing I would say, maybe feeling somewhat self-conscious right now, we made a company wide decision to lower our minimum acceptable quality bar due to the pandemic. If you observe Shopify right now, we are launching a lot. Almost just because of this one change. So we are pulling a lot of our roadmap forward in time. Everything that can help businesses right now, just because, again, we are in a crazy world right now.
Tobi Lutke, CEO of Shopify, on Invest Like The Best (May 2020)

You never want to be on the other side of a catastrophic event having failed saying “we could have done more,” and that has been top-of-mind for us throughout the pandemic. What is interesting when you take the approach of doing everything is some of the tactics work really well, and some do not. There is a tendency to evaluate those tactics in isolation for their success and failure. This is a mistake. You have to evaluate success or failure via the aggregate of all the bullets you fired. Did we save the company? We did. Did we save a lot of our creators’ businesses? We did. You can’t do an experiment or results review on those tactics individually. You have to look at the portfolio.

When should you fire every bullet? Do you fire all the bullets only in near death situations? How about live events recovery? Is Eventbrite firing every bullet to maximize the success of that? Prospect theory states that humans dislike downside impact more than they like upside impact of the same level. Many people have called this irrational. In fact, it is not, because extreme downside effects are things like death and ruin. Extreme upside effects don’t have the same degree of effect. So, firing every bullet makes a lot more sense for extreme downside scenarios than extreme upside scenarios. Think of the two by two.

The difference between we could have grown a little faster and death vs. safety is not at all the same. That doesn’t mean firing every bullet in upside situations is wrong; it’s just not as clear of an answer as in the extreme downside scenario. Quibi did everything to grow for its launch and burned through $100 million. It might have been better to do a smaller launch and iterate on content to find stronger product/market fit. Uber burned through billions for many years to try to both accelerate the size of their market and their market share within it, and it’s almost a $100 billion company.

The important thing to remember here is in extreme circumstances a lot of the best practices are different. Decisiveness, waste, and measurement will trade off in very different ways. It’s important to register when in these extreme situations that a different rulebook may be required to do the right thing for your business or product when in normal operations. Wartime isn’t over at Eventbrite, but I like to think of the situation right now as we’re finally having peace talks. 

Currently listening to Primitive Arts by Ron Trent.

Sequencing Business Models: So You Want To Be A Platform?

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.

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.

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.

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.

Currently listening to my Ambient playlist.

Sequencing Business Models: The Types of Marketplaces

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.

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

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.

The Kindle and the Fire

Entrepreneurs ask me about how to grow all the time. They ask about SEO, about virality, and about increasing conversion, about onboarding. They ask about hiring local teams, building up new functions, and hiring executives. What almost all of them miss is that all of this is context specific on what stage of company they are in. There are two types of growth strategies: non-scalable strategies to get to scale and scalable strategies. I have come to call these kindle strategies and fire strategies. I’ll explain a little bit more about that, and how to think about them.

Kindle strategies can be very unsustainable. Their only goal is to get the company to a place where more sustainable strategies are available. The classic example is in marketplaces. Marketplaces only work when their cross side network effects kick in. Those network effects can only kick in once you get to liquidity. Once network effects do kick in, they can generally be optimized for very sustainable growth. When I left Grubhub, my former co-workers started complaining to me about how much Doordash, Uber Eats, and Postmates were spending on paid search and promotions. They were losing tons of money. There was no way any of those companies ever made this money back from consumer LTV. I told them that wasn’t their goal. Their goal was to get enough consumers so the cross-side network effect kicked in. Those companies were paying their drivers no matter what. Might as well spend money to make sure they’re actually delivering something. And these companies would be willing to almost spend an infinite amount to get the cross-side network effect going because of its value to the company.

I’ve never seen a company as aggressive with promotions as Postmates besides perhaps Homejoy.

This does not only exist in marketplaces however. Superhuman, for example, does live calls or meetings with most people who sign up. This will never scale if they have millions of users, but until either their LTV increases to make this strategy profitable, or they improve self-serve onboarding, they are doing it, because no one would retain without it. You’re willing to do anything it takes in kindle strategies no matter how silly it might seem long term. This is what Paul Graham is talking about when he says “do things that don’t scale.”

Airbnb sold politically themed cereal to raise money for the startup in the early days.

For kindle strategies, it’s more important they work quickly rather than sustainably or efficiently. A lot of early stage companies, for example, ask me about SEO. SEO, unless you have very clever hacks for content and authority, is a fire strategy. It takes too long to work. It might be a great fire strategy to sequence to, though. A lot of companies also ask me about local teams in each market they launch. This can be a great kindle strategy, but it’s generally a terrible fire strategy. Read more from me on this topic here.

Fire strategies by definition need to be sustainable. They need to be able to scale the company 100x and set up a long-term profitable business. So a question all entrepreneurs need to be asking when they pursue their kindle strategy is what fire strategy am I sequencing to. Pinterest used DIY meetups to sequence to influencer blog campaigns to sequence to virality to get enough content where it could scale via personalization on the retention side and SEO on the acquisition side. Most startups won’t go through that many sequences. I’ve seen many companies that have a successful kindle strategy, but it’s not sequencing them into any eventual fire strategy. For example, I spoke with an automotive startup that hacked SEO to get answer box results for their content to get initial users. That eventually caps on how many users it could drive, and it didn’t sequence them to something greater. They eventually shut down.

There aren’t that many fire strategies. Those that involve network effects are generally the best. Sales, paid acquisition, virality, and user generated content with a scalable distribution channel are the most common ways to create sustainable loops to either scale a network effect or scale a product that doesn’t have network effects. This is sobering when I tell entrepreneurs this. There just aren’t that many ways to scale, and almost all involve having extremely good retention as well. Otherwise, you won’t have the profit in the system to invest in sales or paid acquisition, or you won’t get enough users to invite or create content to attract more users.

There are many ways to sequence to a network effect or some other sustainable growth loops, but there are not that many ways to scalably grow without these loops. If you want to learn more about these strategies, it’s exactly what we cover in the Reforge Advanced Growth Strategy course.

Currently listening to Perception by Grant.

What Type of Company Are You and the Growth 2×2

At Reforge, we’ve written about how companies actually grow, and built an entire program around it. Most companies, when they talk about how they grow, will usually pick from one of the following terms:

  • Sales Driven e.g. Oracle, Workday
  • Marketing Driven e.g. Hubspot, Moz
  • Product Driven e.g. Atlassian, Github
  • Engineering Driven e.g. Google, Palantir
  • Product + Sales Driven e.g. Slack, Stripe
  • Marketing + Product Driven e.g Uber, Amazon
  • Sales + Marketing Driven e.g. Drift, Salesforce

Most people can’t reasonably answer why they are one of these types, but there are reasons. If people inside these companies have thought enough about it, they might understand the market to have attributes that force these styles:

  • Sales Driven: Custom value props and big customers
  • Marketing Driven: Need to make a “space” that doesn’t exist yet and convince people they need it
  • Product Driven: High viral quotients and/or word of mouth from product differentiation
  • Engineering Driven: Solving hard technical challenges creates markets
  • Product + Sales Driven: Large customer spread with bottoms up adoption
  • Marketing + Product Driven: Marketing fuels network effects
  • Sales + Marketing Driven: Custom value props and big customers and need to make a “space”

That was extremely simplistic, but hopefully you get the idea. The larger a company grows, the more likely singular definitions like this start to break down though. Companies launch multiple product lines that require different distribution models, and these product lines typically build on top of each other that gain from the intersection of them. In the Advanced Strategy course, we teach how to model these systems of loops that power such companies.

What growth teams sometimes miss is that optimization is not always the answer to a growth problem. It may require a new product or building a sales team. Modeling your loops to understand your constraints to pick tactics that alleviate those constraints takes some time to do well. A framework I’ve used for more quick and dirty decision making is using data companies usually have on hand: whether a tactic is reliable or not historically in driving growth i.e. you can predict the output from an investment or not, and how fast the payback period is.

For those who aren’t familiar, payback period is one of the most important metrics you can track for growth. It’s very simple. Given this investment today, how long will it take before I recoup that investment in profit from the customers it impacts. For example, a customer you acquire in Adwords for $10 might take you six months to make $10 in profit, subtracting all marginal costs. So our payback period would be six months.

Most executive teams can start to plot where in this 2×2 tactics seem to sit. For example, brand marketing at all but the most sophisticated marketing driven companies is something that has a slow payback and is not reliable. Similarly, innovative product development focused on entirely new products or value props usually sits in that category. For other tactics, where they sit in this 2×2 may vary. On Pinterest’s growth team, for a more specific example, efforts in product driven growth around UGC content distributed through SEO, conversion optimization, email marketing, and activation were very predictable and had quick payback periods, but viral growth was unreliable. At Uber, I imagine viral growth via incentivized referrals was very reliable, but SEO was not. Now, it’s important to remember that within reliability is a sense of scale that matters for the business. If a tactic gives you .1% growth, and only 10% improvements matter, it actually isn’t a reliable lever. An alternative is to make a three dimensional chart where reliability is separate from impact, and ain’t nobody got time for that.


A sample Growth 2×2 for just Pinterest’s growth team

In the long run, model your loops well and find the constraints. In the short term run, maximize efforts on reliable and quick payback activities until you hit diminishing returns. Then, think about moving excess resources into things that are reliable, but have longer payback periods. And think about how anything with short paybacks that are unreliable can become more reliable.

What you’ll quickly realize in the case where you have built a proper growth model or you’re short term optimizing based on this 2×2 above is the opportunities are rarely siloed to one function. You can’t even build this 2×2 if you don’t have many functions represented. So start talking to all the functions of your company to map the opportunities to grow better so that you can grow faster.

Currently listening to Simplicity is the Ultimate Sophistication by Matthieu Faubourg.

Sequencing Business Models: Can That SAAS Business Turn Into a Marketplace?

As someone who has spent a lot of time building marketplaces in my career, a curious thing has happened over the last couple years. Founders have started reaching out asking for help converting their SAAS or SAAS-like business into a marketplace. The approach sounds a bit like this:

  • I’ve amassed a large group of X type of professionals
  • I’ve helped their business, but they’re asking for help driving more customers
  • Since I already have the supply, it should be easy to build the demand side to have a successful marketplace
  • My customers will be happy, retain better, and I’ll be able to charge them more

So goes the story. Now, this story itself explains why many businesses fail to make the conversion to marketplace. If driving more customers was your customers’ #1 need, and that’s not what you helped them with, you probably didn’t build a very successful business, or the problem of solving customer acquisition for that market is very difficult.

What Types of Businesses Are We Talking About?

Before we go any further, we should talk about what these businesses look like, and what they mean when they ask about becoming a marketplace. Many of the terms we use to define businesses today are features of the business rather than an encompassing definition, like the words SAAS or platform, which makes them not very useful. Note: I am blatantly stealing Brandon Chu’s platform definitions for this. Let’s break down these definitions so we know where we’re at:

  • SAAS: software that businesses access online and purchase via a subscription e.g. Slack, Adobe, Atlassian
  • SAAS-like: any number of different models where a business sells software to businesses online, but does not charge via a subscription e.g. transactional or pre-revenue
  • Marketplace: a business where sellers (frequently businesses) provide their services on a platform to attract additional buyers, and buyers come to this marketplace to seek out these services and find new suppliers. Marketplaces commonly process the transaction and charge a commission to either the supplier or the demander. If not, they usually charge some sort of lead generation fee to the supplier.
  • Developer platform: a business where developers can build businesses on top of the business’s software and charge customers. The end customer is usually not aware this company even exists e.g. Stripe, Twilio, Amazon Web Services
  • Extension platform: 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 e.g. Shopify, WordPress, Salesforce
  • Networks: a type of platform where consumers interact with each other and/or content on the platform in a non-transactional way e.g. LinkedIn, Pinterest, Yelp

So, when we talk about businesses trying to become marketplaces, what we’re talking about usually is sellers of software to businesses trying to help those same businesses attract more buyers by aggregating buyers on their platform and aiding in the discovery of those buyers finding the businesses the company currently counts as customers.

The Weak Transition to Marketplace Arguments

Why is there a sudden demand of founders looking at this strategy? There are three fairly weak arguments I don’t like, but I’ll present them anyway.

#1 Saturated Growth in SAAS

Perhaps it is a natural extension of the SAAS explosion the last ten years. Kevin Kwok and I have often discussed that growth at some scale equals an adjacent business model:

  • Ecommerce businesses trend towards marketplaces over time e.g. Amazon
  • Marketplaces trend towards vertical integration over time e.g. Zillow
  • SAAS businesses trend towards extension platforms e.g. Salesforce

Perhaps as SAAS has moved into more niche verticals, the extension platform opportunities have dried up, so companies are looking at consumer marketplaces as a new potential growth lever. But SAAS companies continue to grow on the public markets. Perhaps as SAAS has expanded into industries where customer acquisition is difficult, they’ve found their businesses at best only solve the second most important problem for their customers.

#2 Desire for Market Networks

Perhaps it’s because of James Currier. He has blogged repeatedly about market networks being the companies of the future. These companies combine SAAS, marketplaces, and networks. But these founders are not using this term, and this supposed revolution looks no closer to happening five years after his original prediction. Some businesses attempting to build out market networks have become good SAAS businesses e.g. Outdoorsy with its Wheelbase product, but there is no evidence they’ve actually ended up building marketplaces or market networks. Honeybook has struggled, and Angellist and Houzz started as networks, not SAAS businesses. Angellist has never added a SAAS component. Houzz acquired IvyMark last year to launch a SAAS model after ecommerce, ads, and marketplace models for monetization disappointed, and it is too early to understand how well that is working. All evidence shows that if market networks are real, they are more likely to become them from starting as a marketplace or network first, then adding SAAS, not the other way around. Faire is a recent example of this.

#3 It Worked for OpenTable

Now this is a reason I actually hear. But it’s not a great one. The first reason is that OpenTable was a marketplace from day one. Customer acquisition was always a key value proposition, and they delivered on it. It wasn’t aspirational. Second, OpenTable is one of the largest public market disappointments of the last ten years. With an infinitely sized market, the company struggled, was acquired, and then written down significantly post-acquisition by Booking.com.

While these stories exist and do influence some founders, I do still think the main reason why is illustrated in the initial story above; it’s just the strange allure of ongoing customer development.

Why Changing Business Models and Customers is Always Hard

Ignoring the impetus for the rapid increase in desire for SAAS businesses to transform into marketplaces, let’s talk about why companies struggle to do this in practice, and how you fight these headwinds. Through my research and directly working with companies attempting these changes, I’ve identified some main barriers for this transition. If you can work through these barriers, your chances of making this mythical transition increase dramatically.

#1 Founders have to change the incentive structure for all or a significant percentage of the company

SAAS or SAAS-like businesses can grow very quickly. If you’ve spent a significant amount of years building a SAAS business and are considering the marketplace transition to drive additional growth and value to your customers, you’ve almost assuredly built a significantly large base of customers, still have growth targets on this core business, and are managing a lot of complexity already. What happens frequently is founders attempt to spin up a team to work on what’s usually a large, new addition to their current product offering. This initiative is considered a long term, strategic play. It’s important, but not urgent.

What happens to important, but not urgent, initiatives at fast growing companies? They usually get broken up by other important, but more urgent initiatives for the core business. Oh, our quarter was soft, and we need more resources to get back on track? Take them from the marketplace team. We’ll get back to it later. Have an initiative that could drive additional growth in the core business, but don’t have the resources? Take them from the marketplace team. We’ll get back to it later. And so on.

It’s always more attractive to take the more guaranteed optimization on the core business than risk those resources for the very long term, completely risky proposition that might drive a step change in growth for the business much later.

Fortunately, this issue is not new to fast growing companies, and there is a solution. In fact, we faced this very issue at Pinterest. Our largest strategic issue was international growth, but employees kept optimizing 1-2% changes in the U.S. business that moved the top line instead of international work that needed to begin from scratch. Founders usually have two tools to solve this problem. The first is to make the entire company’s growth revolve around this new initiative. That’s what Ben Silbermann did at Pinterest. The entire company was goaled on international growth at the expense of U.S. growth. And it worked.

The other tool is what usually happens at larger companies looking to expand into new product lines. They create a new team with separate goals and reporting lines. Frequently, they don’t even sit in the same building. This is what we did at Eventbrite. We created a Marketplace business unit with a GM reporting directly to the CEO. And while they sat in the same building, it had its own team and its own OKRs.

Changing the goals or creating an independent team with its own set of OKRs does not guarantee marketplace success, but they free you from the temptation of dismantling or impacting teams that frequently need to do years’ worth of work to find product/market fit for a second set of customers.

#2 Founders have to shepherd the right new and existing resources most likely to value the business model transition and change the company culture

Strong businesses usually build a culture of understanding their customers and their model very well and catering to those needs. What happens when you suddenly ask those employees to care about a second customer, or a new business model, and potentially trade off the needs? Old habits die hard. Employees still default to doing what’s best for the current customer/business model even at the expense of the new customer. And even if they do want to care about the new type of customer, they may not have the DNA. Consumer and B2B cultures tend to be very different, for example, attract different types of talent, and there are very few people who are great at both. 

Building B2B products can be very different from building consumer products, and many marketplaces (but not all) have consumers on the demand side. In this case, your customer is a less reliable narrator for their needs, so user research, while effective at identifying their problems, can be a lot less reliable at predicting what people will actually use. Consumer products require significantly more experimentation, and have the data to do it because there are so many more consumers than businesses. 

This cultural issue frequently requires new blood in the organization and careful recruitment of internal resources that are more passionate about the opportunity and usually have some background in consumer product development. Usually, leaders are brought in to lead teams like this with heavy consumer backgrounds, and they recruit more new people with consumer backgrounds. The use of advisors with that kind of experience (like myself) is also common—to suggest product development best practices that may be better suited for the task, to prevent common marketplace-building mistakes, and to more objectively monitor if progress is occurring at the appropriate rate.

How to Be Better Positioned to Build a Marketplace

While transitioning to new customers and/or business models and described above is hard, there are a few ways to make the transition to a marketplace more likely to be successful from a SAAS-like business.

#1 Founders need to confirm there is a demand side to this market, and the way you would engage with them aligns to you and your customers’ business models

One major reason marketplace transitions fail is that there isn’t actually a demand side to this theoretical marketplace to be added. These companies are selling to the supply side of a theoretical marketplace, and don’t understand if demand exists. There are two shades of this I have seen. One is that the SAAS customers make their revenue not by selling something people want to buy and find more, but that people feel compelled to support financially. Let’s take GoFundMe or Patreon as an example. These companies would love to have consumers come to their websites and find people and causes to support. Patreon even tried this. But are consumers searching for websites where they can donate more of their money to artists and local causes? No, not really. Do they support artists and local causes? Of course, that’s why those businesses have done well. But consumers generally aren’t searching for more causes.

The second shade is that the marketplace opportunity is only to find a vendor once on the demand side. In these markets, once a consumer finds a provider for a service, they tend to stick with them for long periods of time. Let’s say you are looking for a babysitter. If you find one that works for you, you stick with that person for a long time. This is in contrast to ordering food, where variety is a feature, not a bug, of the decision-making process. While successful marketplaces have been built in these areas, they are harder to build. SAAS companies struggle to transition in these markets because they have to build trust signals that may damage their relationships with their clients, and there are generally better platforms for researching these vendors than on the SAAS platform e.g. Yelp for local restaurants and services, Tripadvisor for hotels, and G2 Crowd for software. Also, how should the SAAS tool price these additional customers? Just once for the acquisition, or every time they use the product in the future? The clients and the company will usually be misaligned on this, creating leakage. In this case, the business model for the marketplace doesn’t align with the business model for the SAAS business or the SAAS customer. In a weird way, by trying to address the biggest problem you heard from your customers, you built a product that doesn’t work for that need, but for your own.

Again, this is a solvable issue. It can be mitigated through a lot of customer research on the demand side. Not only understanding the consumer your clients are targeting, but finding a critical pain point for them that isn’t solved on the market by another product that your company can actually solve due to its relationships with all of the suppliers in the market. Then, try to align revenue to the value you create in a way your SAAS customers will understand. And be prepared not to capture all of the value.

#2 Make sure the opportunity actually aligns to the characteristics of other successful marketplaces

Transitioning to a marketplace effectively requires founders to understand what makes a successful marketplace, and those characteristics are surprisingly opaque to people who haven’t worked on marketplaces. Rather than reinvent the wheel, I encourage founders to read Bill Gurley’s treatise on 10 factors to consider for marketplaces. One other factor Bill neglects to mention that is important is that normally marketplaces are built on top of under-utilized fixed assets:

  • Excess kitchen space for Grubhub
  • Idle cars for Uber/Lyft and Getaround/Turo
  • Empty bedrooms for Airbnb
  • Empty land for Hipcamp
  • Empty hotel rooms for Booking.com/Expedia
  • Excess SMB Inventory for Groupon

Do your current customers have this characteristic?

Can the Transition to Marketplace Ever Work?

It’s clear that evolving a SAAS business to a marketplace is an emerging strategy that more and more founders will research. What is important is to make sure you’re doing it for the right reasons, and that you’re prepared to fight the main barriers that prevent this transition from working. It’s also important to remember that even if you fight these barriers, this transition takes time. Marketplaces tend to take 2-3 years to find product/market fit. You need to be in a position where you can invest for that long before seeing a return.

In the Advanced Growth Strategy course, Kevin and I talk a lot about minimum scope. Minimum scope is the activation energy that makes a strategy viable. In the course, we talk about the minimum scope for cross side network effects to emerge. And in our examples, we do show that most cross side networks (but not all) emerge with the supply side first. But you have to remember that you do have to hit minimum scope for the demand side as well. And many businesses find they do not have a good answer for this.

Another existential issue for founders looking at this transition is that it inverts the typical company building model. When building a company (especially if you are raising venture), you typically have different assumptions you have to validate to receive funding rounds and eventually build a successful, long-term business. The harder the assumption you validate, the more likely you are to be successful, and the easier a fund raise will be. Ask any founder whether building a SAAS business or a marketplace business is harder. I bet you almost all will answer that a marketplace is harder. With the SAAS to marketplace strategy, you defer the hardest part of your strategy.

When looking for inspiration, it’s true there isn’t a cohort of companies to emulate, and that’s scary. In fact, almost every other business model transition related to this has more data to support. Flexport started as a SAAS business from the demand side (called ImportGenius), and built a marketplace on top of it, for example. Almost all marketplaces add a SAAS component eventually to their model. But don’t be too scared if this is your strategy. If you can answer positively:

  • Can I change the culture?
  • Can I change the structure?
  • Have I vetted a demand side exists?
  • Does the demand side actually exhibit great marketplace characteristics?

Then you are off to a great start in building a new scalable model of growth for your business.

Have transition to marketplace questions? If so, hit me up in the comments.

Thanks to Kevin Kwok and Gemma Pollard for giving feedback on this post. Also thanks for Brandon Chu for letting me use his platform definitions.

Currently listening to my 2010s Shortlist playlist.