Buffing, Nerfing, and OP: What Video Games Can Teach Us About Talent Management

Leave a reply

One of the more interesting, but less talked about, dynamics in the video games industry in the last few decades is that the product they initially ship to customers is no longer the final product. Because of online connections via mobile phones, PCs, and consoles alike, video game creators can push constant updates to their games to make them better over time in response to real-time player feedback and behavior. This makes their approach to development much more like other software in that it can be more agile and less like producing a film or a piece of hardware.

Like any change in the video game community, gamers notice, and a whole lexicon has been created based on these new abilities of game developers. One of the more common genres of video games that receive these changes over time are fighting games and shooters. If you grew up pre-internet like me, then examples include Street Fighter and Mortal Kombat and GoldenEye. If you’re, the youth, as they say, then you might be more familiar with Overwatch, Fortnite, and Call of Duty.

What these franchises do now is ship their initial products, watch the community play, and make adjustments over time. As the community plays, players and developers notice that certain characters or items are incredibly powerful, perhaps more so than the developers intended, or they change the game in some unexpected way. The community deems these OP for overpowered or OD for overdone/overdosed.

Before game developers could update their games over the air through the internet, that would mean certain characters would stay overpowered and make games lopsided if you didn’t use those characters. Players would create rules to adjust for these issues, like not allowing anyone to play as Oddjob in GoldenEye, or just blaming losses on your friend using a “cheap” character.


Oddjob was considered OP in GoldenEye because he was smaller than other characters, making him harder to hit.

What developers now do is notice these patterns and update the games over time to re-balance the game. When this occurs through over the air updates, serious gamers read through the patch notes to figure out who has been buffed and nerfed. Buffing is when a character or item is underpowered, and the developers do something to make it stronger. Nerfing is when a character or item is overpowered, and the developers do something to make it weaker. When these patches occur, the power dynamics change overnight in the game, leading to a lot of players trying new characters to see who they can gain an advantage with. This also can extend a game’s lifetime because it forces people to try new things in the game.


Cassie Cage was nerfed in the first major update to Mortal Kombat 11. Holy graphic improvements, Batman!

I find the concepts of buffing and nerfing fascinating and incredibly relevant to organizations, where employees are the players. All organizations are going to, intentionally or unintentionally, overpower people or areas of the company over time. Organizations need more tactful ways to adjust when these mistakes occur, and the buffing and nerfing of the video game industry is a concept I think can be applied successfully to organizations in this case.

So, how do founders and executives get good signal as to the current dynamics of their “players”? Video game developers watch play data and observe the community. Founders and other executives don’t usually have the same analytics video game developers have, so they need to rely on qualitative signals. Many organizations use business results and culture surveys as a signal into organizational success, and use performance reviews, 360’s, 1:1’s, calibrations, skip levels, Q&A’s, and all hands to build even more signal. If you’re not doing any of these today in your organization, start. Organizations usually know how to use these tools to identify who is doing well and needs to be buffed, and this can result in more scope, more resources, or official promotions. But our tools for nerfing are incredibly crude today, so I’m going to talk more about how to effectively nerf in an organization.

How To Execute a Nerf — Conditions for Play

One thing I want to call out about being overpowered. This is often the failure of an organization, not an individual or a team. We tend to treat OP situations in companies as a failure of the employee or team because it’s a lot easier, and we have mechanisms for those situations, such as demotions and firings. And this is typically the way organizations fix OP problems. To do a nerf effectively requires an organization to understand that it failed in structure or talent management, creating the OP situation. Talent management doesn’t just include performance management, but mentorship opportunities and career pathing. Only then, can it think about using these nerfing tactics effectively.

Nerf Tactic #1: Change the process

One way an employee or team becomes OP is because they manage a key process in some way that gives them undue influence over others. The easiest change then is to change the process to re-balance some of that power. In order to understand how to do this, you need to a) understand the process and b) understand the failings of it according to others. When members of your team that are OP manage a process, they seldom see the flaws in it because of how much control it gives them. So you have to seek out different people’s opinions in the organization as to what is going wrong. A signal that revisiting a process may be a good solution is when other senior team members complain, or if they have enough power, start opting out of certain other processes.

Nerf Tactic #2: Change the structure

Another way an employee or team becomes OP is the structure itself. This tends to happen when functions are grouped. For example, if a GM also has control of sales and marketing, they may become OP. Or if your CMO owns customer service, they may become OP. Neither of these are bad if they occur, but they may end up giving that executive too much power, so they can bully other teams, or they may not be as effective at managing either the scope or the function they’re less familiar with. In this case, the easiest path is to separate these functions or create more dotted line ownership to re-balance the teams.

Nerfing Mistakes to Avoid

#1: Don’t Wait Too Long to Nerf

The longer a power balance is allowed, the higher the chance that the organization will blame the strife on the person/team that is OP rather than the structure itself. Even when that person or team is nerfed, animosity will remain that may make the organization not want to work with the person or team, and continue to impair their performance. When you wait too long to nerf, you’re effectively destroying people’s careers in your organization, which may lead to them leaving. The worst situation is when you have to let go of someone who could have been great with a less powerful scope, but you waited too long to do it. In this case, firing or radically moving the person to something else is the only option.

#2: Don’t Change Titles When You Nerf, Especially Downward

As I said earlier, the most common way organizations nerf today is through demotions, which implies the employee failed instead of the organizational structure. If you absolutely have to change titles because the scope change is that significant, I prefer keeping the level the same, just changing the functional name of the role. Say, for example, you have a Director of Strategy, and they became OP, but you want to retain them. Changing their title to Director of Competitive Research is better than changing their title to Manager, Strategy. Why is this? The demotion indicates failure not only to them, but the rest of the organization. These people usually exit their organizations shortly after the demotion.

Organizational Mistakes That Prevent Effective Nerfs

#1: Inflate Titles

I was talking with a startup recently who hired someone to be their first product manager. They had made a mistake that happens commonly in startups — to make the role attractive or to reward performance once in the role, startups inflate the role title (to be more senior than what that role means on the market). One common example is calling your initial Product Manager a VP Product, or worse, a Chief Product Officer. When the company grows 3x and you’re now asking that product manager to manage people for the first time, these people frequently aren’t ready. Then, in order to fix your organizational mistake, you either have to change their title, which will look like a demotion to them and the organization to hire someone more senior, or try to seek out on the market effective mentorship for them to scale up their career progression faster than is normal.


In the words of Keith Rabois: Wrong.

It’s enticing to inflate titles to make people happy or to attract talent, but it removes your ability to nerf without demoting. In practice, I like to reserve C level titles for public companies and VP titles for managers of managers, though I will be the first to admit that impact is not defined by the number of direct reports. This is not always possible with companies that need their employees to do a lot of external to company work. “Head of” is a happy medium startups are starting to use, but it can still feel like somewhat of a demotion when that title is converted to, say, a Director, when a VP is hired.

#2: Confuse Being OP and Poor Performance

I want to be perfectly clear: do not nerf for poor performance! You nerf when someone was performing well, and a process or scope changed to unintentionally give them too much scope. If you have a good CMO, and you ask them to take Customer Service, and they don’t manage it well, you still have a good CMO. Change the scope, not your performance management strategy for the CMO.

What if you promoted someone to a new level, and they are not meeting it? Well, that is not following performance management best practices. You should be promoting someone when they are already performing at the next level for some time, which eliminates the risk of overpowering them. This is why you want to have career guides with clear levels and expectations for them, so you promote only when it is appropriate. Hired someone at too high a level? Do not nerf; demote or fire. Yes, they will most likely leave, which is why you want to be careful about the titles you give just based on interviews and not actual job performance. What if you have a big hole to fill in the organization and have to do it internally with someone who hasn’t demonstrated all the skills necessary? It happens, but recognize this should be more of a last resort situation.

What about people who move into new roles where they are not effective? This is also a situation I prefer not to have happen. I much prefer creating apprenticeship programs within organizations where individuals try the role for a while before they are permanently placed in that role. Apprenticeship is therefore the evaluation of whether the person can meet the expectations of the role. I recognize this is not always possible, but it’s a sound strategy nonetheless. We do this in product management at Eventbrite today. Those in other parts of the organization in good standing with their manager can work with a product manager on a project to see if they like it, and for the organization to see if they would be good at it.

Nerfing Best Practices

#1 Take the Blame

If you are nerfing an individual, it’s important to make sure they don’t feel like it’s a demotion. When announcing the nerf to your employee, make sure they know the reason for the nerf to occur, and that it is your fault, not theirs. You gave them too demanding a scope, and you’re fixing it. If you’re nerfing a team, this is usually less of an issue. Also, make sure that others in the organization that were affected by the OP individual or team know that you believe this to be your fault, and they should not hold animosity toward the individual going forward.

#2 Thank the Individual You’re Nerfing

Whether the change that made the individual or team OP was intentional or not, thank them for their effort to help the company, and say that the nerf is a way to make sure they can create a positive impact for the company with the right scope. People should not be penalized for trying to step up for the organization.

—
I think it’s incredibly important to manage performance of people and organizations. The gaming community has created a vocabulary that provides a solid analogy with corporations, allowing us to separate performance issues from structural mistakes. The more companies can separate those issues from each other and use different tactics to manage them, the stronger those organizations will be.

Currently listening to my 2019 playlist.

Thinking Outside the Job Title Box: How to Thrive in Undefined Roles

Leave a reply

As a leader of a large team, the members of my team tend to have pretty well-defined roles, like designer, or product manager, or researcher. They also tend to interface with other employees of the company with pretty well-defined roles like engineers, analysts, data scientists, etc. Now, most of the time, these well-defined roles operate in cross-functional teams. But, what if you don’t operate within one of those roles, or don’t want to fit the mold of these well-defined roles? How do you work with teams? To answer that, it may first be helpful to understand how these teams form.

“In the beginning, there was an engineer.”

Most startups begin with an engineer building something from scratch. As the company scales, usually a designer is added next. Then, as keeping track of projects between the designer(s) and engineer(s) becomes onerous, a product manager is added. Then, as the team scales and problems become harder, the product manager and engineer(s) don’t have enough time to fulfill the analytical needs of the team, so they hire an analyst. Then, keeping up with users becomes too time consuming for the designer or product manager, so they add a researcher, etc. This is an overly simple example, but all cross-functional teams grow larger as the company scales, with more specialized roles over time. One issue you may have if you don’t fit into this model is that you want to perform a more specialized role than the company has scaled into needing yet.

The opposite can also be true. You may want to do bits and pieces of a well-defined role, but not all of it, or may want to combine some elements of a few different roles into your job. Either of these situations can be totally fine. But each require a more tactical, subtle approach to working with teams than fitting within well-defined roles. When people outside of the cross-functional teams want to work with these cross-functional teams, they frequently perceive friction. They interpret this as political, when in fact, it is structural.

By definition, when you don’t have a clearly defined role to others, they do not know how to work with you. The onus is on you to prove value so that they want to work with you, because they don’t have to. Usually, my advice when people come to me with these problems is to switch to a more defined role. There may be a valid reason to leave your role less defined though, and in this case, I propose a framework for finding a valuable fit within a cross-functional team.

While all cross-functional teams have well-defined roles on paper, in reality, for all the needs of a team, people within the cross-functional team trade off responsibilities based on skill set and interest. You may have a PM who’s better at execution, so the designer takes on strategic duties, for example. What you’re trying to find with a less defined role is a team that has a need for a skill set, and wants someone to fulfill that need.

What happens in each of these boxes? Well, if your role is not needed or wanted, then you don’t get an opportunity to help. If your role is wanted, but not needed, you tend to be superfluous and lowly leveraged. If your role is needed, but not wanted, you experience rejection. If your role is wanted and needed, that’s where the magic happens. You integrate into the cross-functional team well, help them achieve their goals, and likely are happy in what you’re doing.

Two Tips to Make These Roles Work

#1 Get a senior leader to sponsor your effort
It’s almost impossible to make this type of role if your manager and ideally someone very senior in the organization support it. If senior leaders are very strict about team formation, it just might not be the company where you can be successful in a non-uniform role. Also, if your manager doesn’t support the direction you’re targeting, there will be a big mismatch come review time that will stifle your career.

One way to be more successful with managers and senior leaders is to be very clear why you want to work this way and what value it adds to the company. I would not recommend going to managers and senior leaders suggesting you not fit a typical role in the organization, and then ask how you can be effective. You are not giving them two problems: 1) someone who won’t fit into the traditional organizational structure and 2) someone who doesn’t know how to help the company. For many managers, this would trigger them to ask why you’re at the company in the first place if you don’t know how to help.

#2 Approach teams with humility
Your approach to talking to managers and senior leaders about your role should be very different from how you approach teams. While with managers and senior leaders, you want to make a clear case of the value you can add and what you want to do, that can not work so well for approaching teams. A better approach gets across a few key points:

  • You’re interested in the problem they’re working on
  • You think they are doing interesting work
  • You’re just here to help in whatever way you can
  • These are the skill sets you have that may be valuable
  • Finally, the ask: What can I help with?

Whether you have a traditional or non-traditional role in a team, the first step is building trust, and that is usually earned by doing smaller tasks the team is not getting to and would like help on. From there, you earn the right to work on more critical tasks. It may take some time to get to the role you’re most interested in playing on the team, and that is normal.

—
At Eventbrite, we have multiple people who sit outside the traditional paradigm of well-defined roles who are thriving. They all found a way to add value to a team that was wanted and not competitive, and the team operates better for it. But this all happens on an opt-in basis. The teams chose to accept them. If you want to play outside the lines, you have to understand that other teams playing with you is entirely opt-in on their part. This is the risk of not participating in the structure the company operates in; you may find opportunities to help that the team isn’t welcoming to, and there’s nothing you can do about it.

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

Leave a reply

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.

On The Spectrum: Thoughts on Zuckerberg, Tradeoffs, and Cultural Values

Leave a reply

Many founders spend a lot of time trying to codify their culture and get culture right for their company. Yet many companies end up with serious cultural issues as they scale. Frequently, this is due to a forest for the trees approach to culture. Companies think they maybe they can hide lack of alignment and political strife with pool tables and company offsites, and are surprised when they still have employee attrition problems. Most founders get past that and try to codify strong cultural values that instill how they want to work to get things done at their company. But these values are frequently some mythical view of how things could work vs. how things actually do work. The average response of an employee to a complete set of these values is slightly better than an eye roll. I can’t tell you how many times I’ve seen goals like “Be aggressive” at a company, but everyone is the opposite, or something is set as a cultural value that is just a thing all people should do anyway, like “Think like a founder,” when the problem is people don’t know how.

Mark Zuckerberg has taken a lot of flack for some of his management at Facebook over the years, but I believe it was he who most clearly defined what a cultural value is and isn’t.  Company values (among many other parts of building a company) are about asking, “What are you willing to give up?”. When Facebook chose “Move fast and break things” as a cultural value, they put speed and quality on a spectrum, and said they biased toward speed.

Screenshot 2019-08-18 16.45.52.png

Compare that to Slack. On Slack’s website, they list a few cultural values, including: Craftsmanship, Courtesy, and Solidarity. They too are picking a place on the speed vs. quality spectrum, and I bet with those words it’s a lot closer to quality.

Screenshot 2019-08-18 16.45.38

Neither of these is wrong in isolation. It depends on your market, your competition, your value prop, etc. In all cases, it’s important to pick where you are though. More recently, Facebook switched its core value to “Move fast with stable infrastructure.” It doesn’t have quite the same ring to it, but it’s a signal to the company that at their scale, they need to prioritize quality a little more.

Screenshot 2019-08-18 16.45.16

There are other spectrums to consider when managing culture for a company. One is around openness. Again, here, Facebook has a value that mentions specifically how they think about it, with “Be open,” where they say “We work hard to make sure everyone at Facebook has access to as much information as possible about every part of the company so they can make the best decisions and have the greatest impact.” Stripe is another company famous for swinging to the open side of the spectrum. Most of the email at Stripe is available for anyone at the company to read, for example. Compare this to Apple, where most projects are handled in secret, and information is given on a need-to-know basis.

Screenshot 2019-08-18 16.39.22

Another classic tradeoff is good for company vs. good for world. Take a company like Netflix that ruthlessly measures performance, and focuses on time spent on the platform. It very much biases towards good for company on this spectrum. But take a company like Etsy or Warby Parker that is certified as a B corporation. That’s an explicit signal that they are trading off some company performance for social responsibility. Then there’s of course companies like Kiva, which are non-profits.

Screenshot 2019-08-18 16.39.06

There are others like data vs. intuition, but you get the point. Plotting your company values on a spectrum is important to setting values that actually matter and driving decision-making at scale. Most that make “company value” level should be ones where you are taking a more extreme position. 

What’s really interesting is if you spend time working at companies is many companies don’t appear to be on the spectrum for some of these company company trade-offs. Now, for direct opposites like open and closed, that’s impossible, except for being inconsistent. But some companies are neither fast, nor do they deliver quality products. Some companies are not providing great financial returns or social returns. In this case, our spectrum becomes a 2×2.

Screenshot 2019-08-18 16.38.21

For illustration purposes only. I do not purport to know where Slack and Facebook actually sit on this 2×2.

As in all 2×2’s, it’s the worst to be in the bottom left. If you find this to be the case, the first step is to get on the spectrum. Make a decision about where you want to be, and work to get there. Then, once you’ve landed on the spectrum, you can try to optimize toward getting to the top right of the 2×2. Even though Facebook changed its value, I bet it’s still faster at building and higher quality than a lot of other companies. The same can be said for Slack. Except for Slack Threads. They definitely drifted into the bottom left on that one. I… really hate Slack Threads.

Whether you update your company values to reflect these spectrums is not the point of this post. The point is to be intentional about the tradeoffs you’re making, and revisit them over time to make sure they still make sense, like Zuckerberg did. You may find you’re not making a tradeoff at all; you’re just performing poorly on both axes, or you may find that the value you picked five years ago no longer matches the needs of your company.

Thanks to Brian Balfour for reading through an early draft of this and providing his feedback.

Currently listening to Flamagra by Flying Lotus.

Create Milestones for Your New Job

Leave a reply

People are afraid of taking new jobs. There is a risk of failure of the company you’re joining and potentially of yourself in the role you are accepting. But we all need to accept new jobs at some point. What you should think about is how to cap the downside risk of the two potential situations above. This is indeed possible. I will walk you through my approach.

When you accept a new job, a very healthy practice is to project out the opportunity over a period of time. I like to use increments of six months. What I recommend is you create a document for your job that predicts how the company has evolved, and you yourself have evolved over that time period. This document should ask the following questions:

#1 What should the trajectory of the company be at this time?

This can be represented by numbers, strategic initiatives, funding rounds, whatever makes sense for your mind. Actually, the more the better.

#2 What should my trajectory be at this time?

This can be represented in terms of what you accomplished, what responsibility you accumulated, how much you’re making, what you’ve learned. Again, the more the better.

Okay, so when you join the company, you write this document for let’s say six months, 12 months, and 18 months into the job. When those milestones occur, reflect back on this document and ask the following questions:

#1 Is the company on track?

Predictions are hard, of course, but being on track is great, being ahead of track is awesome, and being off track may be a cause for concern.

#2 Am I on track?

It’s almost as important to ask if your trajectory is on track. Are you learning what you thought you would, accomplishing what you thought you would, making as much as you thought, accumulating the responsibility you hoped for? All of that should be addressed.

If the answer to both of these questions is on track or ahead of track, amazing. You should feel confident continuing to work at the company. If either of these questions is no, however, you need to ask yourself two additional questions.

#1 Can it get back on track?

Let’s say the company is off track. Do you believe in a reasonable plan to get back on track. Was it a one time setback, or are we too far off course to hit the objectives you initially wrote? Similarly for yourself. If only one of the answers above was no, it creates different implications. A fast growing company, but not growing yourself creates a free rider problem for your career. A company where you’re growing yourself, but the company is off target may mean all you’re learning won’t be valued by the market if the company doesn’t end up doing well.

#2 If not, am I comfortable with the new track?

If you’re not on track and don’t feel you can get back on track, you have to ask if you’re comfortable with the new track. This is common. You may have set to high a goal, but things are still objectively going well. That’s fine. You do want to make sure you’re not justifying a mediocre or bad situation because it makes you uncomfortable.

—

If you follow this process, it should let you know if the opportunity you initially thought was worthwhile isn’t there. The key is when you learn this that you don’t continue to stay. If the company and/or yourself on not on track, you don’t expect to get it on track, and you’re not comfortable with the track, you should find a new job. As long as you change jobs when when you reflect every six months and see this, the risk is mitigated. The real risk is staying with a company a long time that is off track for itself and your career, with no way of getting back on, and it’s sacrificing your potential. Those are the only real career mistakes. So, go ahead and take that new job. But use this framework to be honest with yourself about whether it’s working out or not. And if it’s not, find a new one.

Currently listening to Between Two Selves by Octa Octa.

Centralization Vs. Decentralization in Marketplaces and Scaling Companies

Leave a reply

First off, no, this is not a post about blockchain. Sorry to disappoint you. This is a post about structuring your teams, and structuring your business. A common problem I work with entrepreneurs on is where power should be held both inside and outside organizations. These entrepreneurs have heard the stories of how instrumental Uber’s local teams were in their success. They have also heard about marketplaces that have given all of the power to the supply, and also marketplaces where supply has no power. They struggle to understand for their particular business, how much power am I centralizing in HQ, or how much power am I centralizing inside the company vs. outside it.

These issues usually arise in two areas, which particularly, but not exclusively, affect marketplaces. One is around local expansion. When I enter a city or country, who is in charge of that market’s success? Is it a local GM or someone in HQ? The same questions emerge for satellite development offices and going international. Do I hire local managers? Or do people report into managers in HQ? Who owns a country’s growth? The second issue is around who controls the quality of the service. Do we let the supply side determine their level of service, or do we standardize it across all of our supply? Is there value in standardization or variety of service level?

Advice on these topics usually misses the main factors a company should be considering when making these decisions. That main factor is where does the expertise lie, and what enables the best execution. And both of these can change over time. Uber is a great example. Because of training and car inspections, supply side onboarding had to be decentralized to a GM in each market. And because each market needs to boot from scratch, it generally made sense to give the GM responsibility for the entire market. They could do scrappy things to drive supply and demand acquisition and brute force initial liquidity. Once Uber had initial liquidity in these markets though, it ran into decentralization problems. Uber started to build up world class acquisition teams in HQ that didn’t have full control on how to scale customer acquisition. Local teams were still doing scrappy tests that didn’t scale, and not managing budgets as efficiently. Uber eventually centralized a lot of this work, but most people will probably tell you they did it too late, causing a lot of political strife.

On level of service, however, Uber has always strictly standardized their level of service across markets. Uber is not interested in drivers creating their own style of service. Consistency is a key part of Uber’s offering to passengers. Uber decides if they want to introduce varying levels of service in markets in a standardized way, with Black, X, Pool, etc.

At Grubhub, we started with local responsibility for supply with outside salespeople and HQ (read: me) responsible for demand. The playbooks my team developed to drive demand with SEO, SEM, and offline marketing scaled equally well to new markets as long as we reached enough supply. For supply, we had to build knowledge of the local market, and the best way to do that was boots on the ground. Over time, as we refined our process to determine quality restaurant leads and which neighborhoods mattered, we started centralizing supply with an inside sales team in HQ as well. For market launches, we would paratroop salespeople into a market to get to a certain amount of liquidity, then retreat to inside sales to scale.

For level of service, variety matters a lot for a business like Grubhub because not everyone wants to order the same type of food. There is also demand across different price points, time of day, day of week, etc. Variability in the food from restaurant to restaurant is a feature, not a bug. Grubhub uses ratings from the demand side to determine if a restaurant is below a certain floor of quality it is willing to accept, and if it drops below that, they will remove the restaurant from the service. Where Grubhub has standardized more over time is the delivery experience. Grubhub used to outsource 100% of its deliveries to the restaurant, and now over 20% of orders are delivered by Grubhub couriers. I previously explored the variables in the food delivery space here.

Airbnb has evolved similar to Grubhub. At first, Airbnb let hosts define their level of service and encouraged them to express themselves and figure out their own pricing. As Airbnb grew, it developed a deeper understanding of what Airbnb guests want and what prices will be successful. It is now standardizing those pricing levels and amenities hosts are expected to give. Now, they are not booting hosts off the platform who choose not to adopt these strategies. Instead, they are promoting more aggressively the hosts who have specific designations (at first Instant Book and now Airbnb Plus) with higher rankings in search results and special filters. They expect most hosts will conform over time due to these incentives.

It is unclear if this is the right strategy for Airbnb. While baseline expectations for service are a good thing in hospitality, there is a possibility the service could lose some of the uniqueness that partially made it desirable as an alternative to hotels in the first place. Airbnb’s value propositions that made them grow so quickly were lower cost and more unique inventory (both more unique places to stay as well as in more unique locations like local neighborhoods). It will be interesting to see how professionalizing supply works for them in the long term.

Eventbrite is an interesting example of approaching decentralization. Eventbrite works with event creators, commonly known as promoters. What do event promoters know how to do: promote their event! So Eventbrite partially outsourced demand acquisition to its supply of event creators. Event creators knew how to attract ticket buyers better than Eventbrite did in many cases. As Eventbrite has grown though, it has gotten significantly better at helping event creators sell more tickets. It now has proprietary distribution channels the event creators do not have like its app and website, a strong SEO presence, and distribution partnerships.

Eventbrite also has development offices in many different countries now. When you hire a PM for a particular business unit, do they report to the local office leader, who may not have a product background, but knows what is going on in the office really well and knows how to hire locally? Or does the PM report to a product leader that may not even live in the same country but knows how to develop product managers and understands the product strategy? This was a recent problem we worked on. What we decided is that the PM would have a local leader that is in charge of making sure that PM is a happy and productive member of that local office and a functional leader that is in charge of making sure that PM is a happy and productive member of the business unit and product team.

General Best Practices

Out of these examples some best practices emerge. If you’re thinking about these questions for your business, I would ask the following questions:

Am I launching a new market? If so, how much of a replicable playbook do I have on how to launch successfully?

The earlier the stage of the market you are expanding into and the less of a playbook you have for this, the more likely you want a local owner in charge of figuring out how to make the market work. Their job, however, is not to own the market long term. It is to get to liquidity as fast as possible so that subject matter experts in HQ can take over parts of the growth of the market.

If you have a refined playbook like Grubhub eventually did, you may find you don’t need local expertise for supply or demand.

Once a market has launched, who is in charge of the growth of the market?

Once a market has found liquidity, or product/market fit, it depends on how much of what drives that market’s success is shared with the rest of the company. If the market is fairly unique, a GM with control may make sense. However, most markets have a fairly similar growth playbook once the market finds liquidity. Usually, this means, if a GM exists, they should not own the growth of the market. Instead, they control growth levers that cannot be managed effectively from HQ, such as training and local partnerships and local feedback to HQ teams. They also frequently are an execution layer for HQ strategies such a PR, content marketing, etc. A lot of companies make the mistake of keeping the onus of growth on a local person even after it is revealed most of the levers for growth are controlled by HQ, creating a very frustrating role for that GM.

Is supply variability a feature or a bug?

Does the demand side of your marketplace have homogeneous needs? If so, can you standardize that into different products or not? If not, you will allow your supply more control over what services they provide until needs become more homogenized or are cleanly separated into different products that can be standardized.

Who manages local team members?

If they are operations focused on local needs, they are usually best managed by some sort of operational team. At Pinterest, these team members were managed by a Head of International in HQ. At Grubhub, since all of our local people were salespeople, they were managed by a VP of Sales in HQ. If, however, you have local development teams, those teams have different management needs that typically need to be managed by different people. They need a functional manager that can tie them into the HQ’s strategy. Because of the size of the team though, they also need a local manager that can recruit them and make sure they are a happy and effective local employee that an HQ manager won’t have visibility into. As teams scale, they usually add local management layers that report into functional managers in HQ. For product, for example, that might be a Product Lead in a satellite office reporting into a Director or VP of Product in HQ. If you don’t have enough product managers to have a local manager, they usually dually report into the HQ Head of Product and the satellite office manager.

—

Most companies centralize decision-making over time in their main office. They do this not because they are hungry for control, but because they start to build up more expertise than either their local offices or their suppliers. It is not actually the leadership team centralizing the decision-making, but the subject matter experts in HQ. The real question to ask when you are managing these problems yourself is where is the expertise for this problem, and is it changing, and how does execution need to occur for this problem.

An Alternative Approach to Re-Orgs At Your Company

Leave a reply

Re-orgs are an essential part of scaling a team at a company. The organizational structure of the company six months ago may no longer align to the needs of the company or its customers today. While most people would agree with the statement above that insists re-orgs are necessary, everyone hates them. They almost always make some people unhappy, cause employee departures, and stifle productivity both before and after they are executed.

I’ll start with a story of how this works in practice. Grubhub had a fairly stable structure for most of the time I worked there. While it was stable, it certainly wasn’t traditional. While we had crafted large sales, marketing, and customer service teams, we had a very small engineering team for our size and no official product and design teams. The latter two we de facto managed by marketing and a combination of executive leadership. While most companies at the time had a clear product manager role, Grubhub did not. We had product strategy led by marketing and the co-founders, and project managers within engineering that worked with those stakeholders to build effective software. I hired a member of my team to build a loyalty program. This meant that they would do user research, build models that project impact and costs, and work with engineering to launch experiments that would increase frequency of ordering on Grubhub. The person we hired was, in short, awesome. She did a bunch of great research partnering with our UX researcher, built detailed financial models that projected impact, brainstormed many ideas with our designers, and built good rapport with our project managers and engineers when it came time to finally build something.

Around this time, we started discussing as a leadership team if it made sense to start building a product management function for Grubhub. Being privy to those conversations, as I was having my quarterly review with this member of my team, I suggested product management would be a good avenue for her if we create that function, but she would probably need to leave my team to do it. We talked through the details of why I felt that made sense given what she was doing, and she was very open to it.

Fast forward three months, and as I’m on my way to work, I receive an email from my manager the VP Marketing asking to meet when I get in (she always got in super early). When I did, she announced that we were creating a product management function, and that as they thought about what the members of that team should look like, they felt like this member of my team was a perfect model of what a product manager should be at Grubhub. So, effective immediately, they were moving her off my team to be the first consumer product manager. The co-founder of the company was meeting with her when she got in to explain the move, and email would go out right after, and my 1:1 was with her later in the day.

That 1:1 was awkward. While this was ultimately what I wanted for her, and she was nervously happy about it (it’s nice having the co-founder of the company say your behavior is a model of behavior they want at the company), things still felt off. What is supposed to happen to her current projects? What new projects is she picking up? She at one point during the meeting said “oh, you seem sad”. And I wasn’t, just more caught off-guard, and thinking even though we’re making the right decision, are we making it in the right way?

This I find is usually the best case scenario for re-orgs. VPs and C level execs are attuned enough to make the right calls, but execute it top down without director, middle management or IC involvement or feedback on their ideas, leading to a change that is good on paper and may be good in practice too, but seems to strip the team of control. And far more common is the flip side of this scenario: when VPs and C level execs think they know what is good for the people and the team, don’t seek out necessary feedback, and make the wrong call for both the organization and people’s careers who are affected by the re-orgs.

For one of my the companies I advise, going into 2019, for one our business units we knew we likely had to change our organizational structure. Trying not to repeat re-org mistakes, we started working on a structure that would make the re-org act like a feedback-fueled progress driven by the teams instead of by people above them. The first thing we worked on as a leadership team was the objectives for 2019. What did we need to achieve next year to be successful? We then went to the product managers, designers, and engineering managers and explained the objectives. We then tasked them to propose the organizational structure that would help them with these objectives.

They worked directly with their teams to make sure everyone understood the objectives, everyone’s interests and career aspirations, and then they proposed the structure to the leadership team. After this presentation, we worked more to understand the constraints that led to this recommendation, worked through some of those constraints so the team didn’t need to make as many compromises on what they wanted, and then solidified the structure. The product managers, engineering managers, and designers talked through the changes with the rest of the teams, and organically the teams started planning with the new structure in mind. They then set their own team objectives to the align to the business units, as well as their roadmap and key results.

By involving the team members that would be effected from the beginning and making it their decision, we avoided a lot of the awkwardness or bad calls of many re-orgs I have participated in. The teams are happy and working on the new objectives seamlessly. Now, there will certainly be re-orgs that can’t be this inclusive, such as those that involve the transitioning out of an executive, or with teams that would not be capable of tying the objectives to an effective team structure. The former will never be seamless when people’s managers leave. The latter indicates a separate problem of lack of team responsibility that needs to be addressed first. But if you are not facing one of these scenarios, here are some things I have learned you may want to incorporate into your next re-org.

  1. Start with making sure the objectives of the company/team/business unit, etc. are clear, and that the executive team is aligned on them.
  2. Inform the teams affected that the new objectives create an opportunity for them to re-organize to be more effective at achieving these objectives.
  3. Empower the teams to propose a new structure that would better allow them to achieve the objectives
  4. When these teams present their proposals, make sure they focus on talking through the constraints that led to their proposal. These are frequently resourcing e.g. not enough Android engineers, cross-department collaboration or lack thereof e.g. no SRE support next quarter, technical or design debt, et al., They can be relationship based or based on location for distributed teams.
  5. Resist the urge to edit the choices directly as a leadership team. Instead, focusing on editing their constraints.

The Problems With Martech, and Why Martech is Actually for Engineers

Leave a reply

Since I spent some time in VC land and have a background in marketing, a lot of people ask me about martech, or technology built for the marketers. Are these good businesses? Which tools should they use/are on the rise?

In short, I hate martech, and think martech will decline as a category, and most martech businesses will not be very successful. I think there are a few reasons for this that are not well understood, but if you understand them, it can unlock some martech opportunities that are still quite large for entrepreneurs, and help marketers understand which technologies to bet on vs. bring in house. The main misunderstanding is that successful martech is actually for engineers, not marketers. Let’s talk about why that’s the case.

Martech is a Response to Engineering Constraints
A controversial opinion I have stated before is that the marketing function in technology companies is usually a response to engineering constraints. If you don’t have enough engineers to build a system to manage bidding for performance marketing, you hire a marketer. If you don’t have engineers that can work on SEO, you hire a marketer. If you can’t build a great email system, you hire a marketer. Most key marketing roles are manual tasks that can better be solved with engineering. The smartest marketers, realizing this, started automating a lot of their work through third party tools, and if they could, even better, first party tools. This is how martech exploded over the last decade. Marketers actually had important, if not critically under-weighted, responsibilities for the company. For example, I was in charge of getting new people to try ordering online at Grubhub, and to keep them coming back once they did. My team used a lot of martech tools to do that.

Engineering Constraints Are Being Laxed
While hiring engineers inside companies to solve these problems is still extremely competitive, engineering constraints are (slowly) being laxed across every technology company I meet. Startups and technology companies today have many more engineers working on more functions (due to improvements on engineering technology) than we had at Grubhub during similar stages of our company.

These engineering constraints being laxed means martech companies have to compete with the engineers at the company for the best way to solve a marketing problem. And besides there being more engineers in a company to work on these problems, engineers are now more likely to want to work on these problems or reject these tools as best practices. Growth teams have emerged to work on a lot of the traditional marketing problems marketing teams bought software for: email, SEO, landing page optimization, onboarding, etc.

Martech now finds itself in a more competitive environment since “build” in the “build or buy” equation is more likely than it used to be. Also, if engineers inside a company do decide to build instead of buy a solution, a lot of times what they build is more effective than what the martech provider can offer. This is not to say engineers inside tech companies are better than engineers inside martech companies; engineers inside tech companies simply have unfair advantages. Not only can engineers building the solution for their company build directly to the needs of their company instead of adapt some generic solution; they can also more easily integrate with the data needed for these tools to make the right decisions. It is notoriously difficult, for example, for many martech tools to integrate conversion data, and certainly much harder for lifetime value data. This is much more easily done with an in-house built tool.

Platforms Also Limit Martech’s Reach
Martech companies face the squeeze from the other side of the integration as well. Usually, martech companies integrate into some other system: advertising companies like Google and Facebook, adtech companies like exchanges and demand side platforms, email service providers and email clients, etc. What happened is these martech companies built value added features on top of a platform to deliver extra value to customers. What is happening now is those platforms are either integrating those best features themselves, so you don’t need the martech company for it anymore, or deleting the access that enables it, because the platform doesn’t actually want that level of transparency.

Where Can Martech Be Successful?
So these companies have the platforms stealing their features or cutting off the access that makes them possible on one side, and engineers at the companies of their clients building deeper integrations themselves. So, if most martech solutions have a disadvantage to competing with in-house engineering solutions, or the platforms starts competing with them, what type of martech tools have an advantage?

Option 1: Leverage Data Network Effects
One key example where martech thrives is when the external data becomes more important than the internal data. If a martech tool can be gathering data from multiple companies, and create a data network effect from this aggregation, thereby helping all companies improve in a way they could not on their own, they are very defensible. Sift Science is a great example of this. By being used as a fraud provider across thousands of companies, they have data any individual company won’t have in determining if a transaction is fraudulent or not.

Option 2: Manage Pain
Similarly, integrations with a bunch of key operators or vendors are very defensible in martech. Litmus is a classic example historically. Email providers have notoriously finicky rules around what renders in their systems and how, and they are not very transparent. Engineers and designers hate coding for email, and it’s hard for them to remember all the rules for all the different types of email clients. Litmus allowed you to preview what your emails looked like across all major clients to spot errors before you send the email, and generally became an all-encompassing email QA tool. No engineer internally wants to build that, and they will never be as good as Litmus at doing it because Litmus has been doing it for billions of emails, so it has seen many more cases, and has better integrations with email providers. Another example of removing engineering pain is Heap Analytics, which auto-tags events, removing one of the most painful parts of setting up a new analytics vendor.

Option 3: Leverage Cross Side Network Effects
A more modern example is the customer data platform companies Segment and mParticle. These companies integrate with hundreds of other companies marketers use for various purposes: web analytics, conversion tracking for performance marketing, crash reporting, et al. Integrating these companies saves engineers time because they integrate once, and any other solutions they need can now be enabled instantly. These integrations not only help marketing, but product, and engineering as well. These companies have created a cross side network effect between customers and other technology providers. Data platform companies are hard to rip out once you integrate because they are so integrated in all of your processes.

The Real Answer: Change the Target Customer
Okay, so all of these are great options, but they actually share one thing in common: they have really shifted the target customer to the engineer instead of the marketer. Sure, the marketer may be the person requesting the solution, but the solution is chosen because the engineers like it. Many things an engineer has to do are painful, and as much as engineers like to solve their own problems, if you show value to them, they will appreciate it. So I am very bullish on engtech companies masquerading as martech. Other examples of this besides the ones above are data visualization platforms like Mode and Periscope.

Bonus Option: Pick the Right Marketing Customer
One other strategy that is very successful for martech companies is to build targeted solutions for the types of companies where marketing is more central to the organization’s success. While marketing is ebbing in importance in most tech companies, one area it is thriving is in ecommerce companies, whose main playbooks are logistical on product delivery, and where brand + performance marketing drive all sales. The product is something delivered offline, so the product and engineering teams are more subservient to marketing than in other functions, and because the product is delivered offline, these teams usually have less engineers than other companies. Narvar is a great example for ecommerce tracking. Buffer is a great example for social media marketing. Canva is a great tool to help design creative for marketing campaigns and social media posts.

—

Martech is a very challenging space for an entrepreneur. If you are going to tackle it, there are distinct strategies like data network effects, pain management and maintenance, and cross side network effects that make it more possible to build a sustainable business. Approaching the right customers, either in role (engineering) or space (ecommerce) also make the road easier.  If you have any other tips on building a great martech business, feel free to leave them in the comments.

Currently listening to Slide by George Clanton.

Q&A with Elena Verna at Amplitude Amplify Conference

Leave a reply

I recently gave a presentation at the Amplitude Amplify Conference on Growth Models. I then had the pleasure of interviewing one of my favorite leaders, Elena Verna, GM of the Consumer Business at MalwareBytes and previous SVP of Growth at SurveyMonkey. The video is now online. We talk about how MalwareBytes and SurveyMonkey grow, the different types of word of mouth, how to think about freemium as a strategy, the content loops of SurveyMonkey and Eventbrite, building network effects, and much more.