Transparent Optimism

When I started managing teams at Grubhub over a decade ago, I was pretty obsessed with high performance. I wanted my team to have very clear goals, remove any roadblocks they would face to being successful, and make a big impact on the success of the company. I was able to hire a strong team, and we got to work, 100xing the size of our customer base over four years. As part of this process, a lot of what I tried to do was reduce distractions for the team. Any time there was strategic misalignment or confusion at the top ranks of the company, I would hide that from the team so it didn’t affect their performance. In other words, I wouldn’t let confusion at the top level create confusion at their level.

As the team grew over time both in size and in scope, I started to see cracks in this strategy I didn’t immediately understand. The first symptom was people on my team saying that while they felt very supported by me and were growing in their skills and their career, they didn’t have much visibility in what other members of the team did or how their roles worked. So, I created a Friday meeting we called “Team Learn” where every week, one team member would deep dive on what they were working on so the rest of the team could learn more about it. Initially, these were topics like email marketing or Google Adwords, but we started expanding them to other topics the team wanted to learn about, like venture capital and emerging channels. This meeting was so successful other teams wanted to participate, so I eventually expanded the meeting to include other teams.

This didn’t solve the root problem though. As my team got more comfort or clarity in their feedback, I started to understand the root problem more. While I was shielding my team from any swirl related to top level strategic decisions or screw ups or whatever elsewhere in the company, I was not the only person they talked to at Grubhub. So, they would hear from peers about all of these other things going on I had deemed to be unimportant or distractions, and the fact that I didn’t ever mention them made it feel like I was hiding things from them. It made them feel as if they couldn’t handle that level of knowledge and weren’t being treated as senior as they should be. 

So I shifted my approach. I made a commitment to share what was going on, but also contextualize it so as not to create doubt or swirl in their minds about what was going on at the company. We were definitely winning, after all. I moved from extreme editorial filtering to complete transparency, followed by contextualizing how this will all work out and why we win. When we hire great employees, the push to focus them and not distract them, while good, can easily be used as an excuse to not share hard things, and that creates a belief that the team can’t handle unresolved conflict, work through confusion, or understand strategic fog or even help lift it, and creates the perception that you as a leader are hiding things. It’s like hiring a bunch of strong engineers, and then only feeding them tickets of what they need to code through Jira because if we actually got them involved in deciding the problem, “they couldn’t possibly understand the business!” It doesn’t make a lot of sense when you think about it.

At Eventbrite, I have come to call this style transparent optimism. I’m going to give you all the context, the good, the bad, and the ugly, and explain how I think we come out on top. I trust my team with being able to handle all of that context and ultimately help us work through some of the thornier issues together. This is a style of communication that will not work with all cultures. Company cultures have to decide where they exist on a spectrum of open vs. closed in their communication. If I tried to apply this style at Apple, for example, I would quickly be fired for sharing things they do not want shared. So I bias toward cultures that have a comfort with this level of transparency, which is not all companies! Many companies would not even let me write a blog like this while working there. At Eventbrite now, I host quarterly AMAs with the team, the CEO does them twice a month, and both the CTO and I wrote monthly internal blog posts on what is on our mind. 

Obviously, I am biased, and communication styles come with pros and cons. With transparent optimism, I create risks of more interpretations of what is happening, external leaks, and it just requires me to communicate a lot more. But ultimately, I think it creates a default trust and default respect with the team, and helps them contribute more to the success of the company.

Currently listening to Scurlage by µ-Ziq.

The Rise of Department Operations Roles, and How to Tackle Inefficiency

At every company, there are well defined roles you would expect to see. In software, they tend to be roles like engineering, product management, design, marketing, legal, finance, etc. But as companies scale, they tend to invest in more specialized roles over time. During that transition, operating in one of these roles can be confusing. One interesting trend emerging at many companies including Eventbrite is the creation of departmental operations roles. Oh, you’ve seen them: Marketing Operations, Sales Operations, Design Operations, Product Operations et al. My first instinct when I hear an “operations” title is “inefficiency.” Not that the operations person is inefficient, but that there is inefficiency at the company. It is okay to be inefficient at things at your company. At various times, it will make sense to be inefficient in tons of areas of the company. The danger is in accepting inefficiency for the long term. We should strive to eliminate inefficiency over time at companies, not embrace it. Thus, the goal of departmental operations teams can be somewhat paradoxical. By explicitly attempting to remove inefficiency, they are actually attempting to remove the need for their roles entirely. 

The Intercom Biz Ops team was the first to just come out and say it. This can create a remarkable conflict of interest though. By doing a good job, will I eliminate the need for my job? As a result of this conflict of interest, we have started to see people in these roles try to define them as long-term necessities in organization, which means employees are optimizing for themselves instead of the company. What is interesting about this trend is that this job security issue shouldn’t be a conflict of interest. The goal of every job inside an organization should be to eliminate the need for it so you can do more important things. This is a great way to get more responsibility and promotions. There would be no greater pride for me than feeling like I am no longer needed in my current role at Eventbrite, for example.

So, if you want to do a great job in a departmental operations role, how do you do that? Well, the real question is how do we solve inefficiencies at companies? It’s like solving any problem within your company. You use various tools. I have a very specific hierarchy I like to follow to solve these problems, and I wish more companies used it instead of defaulting to hiring people and creating roles. If you’re in a department operations role, you can consider this a playbook to helping the company be more successful.

#1 Software
Any problem or inefficiency we can solve with software is superior to other forms because it automates away the inefficiency in the future once it is built. Now, it may be the case that we cannot think of or do not have the resources to develop a software solution to the problem, permanently or temporarily, or that there is no software we can buy that helps. This is okay, even normal. Companies tend to under-invest in leveraging engineering to build solutions that help their companies become more efficient, largely because so many companies are engineering-constrained. But just like engineers have started to work more on business problems like growth or marketing, they will eventually start to work more on internal tooling that enables their and other teams.

#2 Process
My next goal would be to solve the problem or inefficiency with process. Process innovation is a remarkable thing. By understanding the issue and proposing a way of operating to solve the problem, the pain point can frequently be mitigated or disappear. Now, this is not as automatic as software because it requires people doing things to follow the process and usually more training than software. But processes can become hard-to-break habits, especially once employees see the benefits of them inside an organization. This is more of where departmental operations roles tend to thrive today. By understanding the strategy of the business and the day-to-day operations, operations team members can spot inefficiencies, test different process solutions and assume responsibility for scaling out ones that work. But these solutions can be led by anyone. The more this happens without dedicated operations people, the more efficient an organization is.

#3 People
My next best option after process is to solve a problem with a person. Hiring is expensive, so it should be considered carefully. I definitely prefer hiring for concrete roles that have well defined value inside companies. Engineer, designer, analyst, etc. If you need to hire an Operations role because the problem is nebulous, temporary, or today can’t fit into one of those roles, you can do it. But you should have a career plan for those roles to evolve into a more well-defined role. Fortunately, team members that showcase generic problem solving skills are great fits for many other types of roles inside companies, so they rarely have to worry about their next internal career move. Still, it may be more efficient to actually look at one of the other solutions below.

#4 Advisors or Consultants
Sometimes the right person isn’t available, or the problem is well time-boxed. In this situation, I prefer to find consultants or advisors. Subject matter expertise exists out there in the world for almost anything. Working with individuals that have specific experience makes it easy to align incentives even if this subject matter expertise isn’t hireable full-time. If the issue is temporary, you may not want to hire full-time anyway.

#5 Agencies and Firms
Lastly, I look at agencies or firms. With these companies, it is hard to prevent misaligned incentives. But they do have expertise and bodies that you can throw at a problem with less risk of being stuck with them full-time. 

Where Operations Wins
I am not against Operations roles; I just want companies to understand how to use them well and to scale out of them whenever possible. Early stage companies can absolutely crush with Operations. Smart people Swiss Army Knifing problems is many times the fastest way to scale in the early stage. Operations roles can also thrive in larger companies, if they root out inefficiency with the tools above and don’t succumb to empire building. We can’t yet automate transportation needed for the delivery of the business? Call that the Operations team. We can’t automate training for our customers yet? Call that the Operations team. 

The COO role is very common, though its definition is ambiguous because it tends to be a grab bag of executive inefficiency. Usually, the COO manages what the CEO is inefficient at. That can be management in general, or parts of the company the CEO is less capable of adding value to. The COO role can also be a roll up of certain executive functions when the CEO has too many direct reports as well. 

This is all fine and even optimal. But every operations role you add you should also add to a list of inefficiencies you hope your company can solve one day, and always be thinking towards software or processes that make these current roles unnecessary so those people can take on even more important roles over time.

Currently listening to Good Times by Moire.

Reducing Product Risk and Removing the MVP Mindset

I originally wrote this piece internally at Eventbrite and thought it might be valuable to folks who do not work at Eventbrite as well. Slightly edited to remove Eventbrite jargon.

What is the right way to build products? Earlier in my career, I would have told you everything should be AB tested, and that you should build only as little as you need to validate a hypothesis. Every problem should have user research involved at the beginning, aligned on the problem instead of just validating or invalidating solutions. Every key result should be outcome based. Every engineer, designer and product manager on the team should be involved in defining the problem and the solution. These are all good ideas. However, once you add enough of these “best practices” up, it reads kind of like those articles talking about the morning habits of the most successful people in the world. If you actually try to follow all of those habits, it would take you six hours a day and cost a lot of money. I was once reading an article about what a futurist at Google eats for breakfast every morning to live longer. The article added up that his diet of food and pills cost him $1 million per year. My morning ain’t that long, and I ain’t got that much money.

So if the documented “best practices” take too long or are too expensive, how do you approach different product situations? I want to share a few frameworks that I think can help, but there is no substitute for judgment here. Eventbrite has lots of different product problems. One of the things we are trying to get better at is defining the type of product problem we are working on,  and outlining how we build based on who we are building for, whether it’s consumers or the many different types of event creators we support.

RULE #1 OF PRODUCT WORK: IT IS NEVER DONE

We should all know that products and features need to continually improve to stay relevant for our users over time. And it should come as no surprise that no product or feature is perfect on initial release. They need to be refined over time to get better, incorporating feedback from actual users. Many companies just launch new features and forget they exist, rarely improving them. This is not how great products are built. What this means though is that initial releases will never have everything teams want. But if you continue to iterate, this is not a problem. As long as we’re getting value to users as they become available.

If you’re going to continue to iterate on features, supporting them takes effort to maintain and improve over time. The much bigger question then becomes whether product work should be started, and when progress should be shared with users over time. If you start the work, you’re implicitly saying the company should expect to support it for years. That’s a big commitment. So, at Eventbrite we try to do work to de-risk that commitment up front. And if you have a long amount of work mapped out, figuring out what chunks can be released independently so that incrementally more value is being experienced by users is tricky. I’ll dive into how at Eventbrite we are trying to improve our approach to reduce risk and ship releases incrementally.  

A FRAMEWORK FOR REDUCING RISK IN WHAT WE BUILD

Product development projects always have very high opportunity cost. So, no matter who we are building for, we try to de-risk investments into projects by learning more about the problems before we invest time in solutions. How do you de-risk projects? An obvious answer may be to talk to customers, right? But it’s not that simple. Users of products are generally unreliable narrators of their own behaviors and preferences. How unreliable depends on who the customer is. For our consumer products, asking our consumers what they want is usually a lost cause. Sure, we can and should regularly talk to them about their problems, but we have to infer solutions ourselves. We can’t expect our consumers to be excellent product thinkers. If we did build what they asked for, they probably wouldn’t end up using it. As Henry Ford allegedly said, “If I’d asked customers what they wanted, they would have said a faster horse.” 

For event creators, it depends on how sophisticated they are. Eventbrite is a broad, horizontal platform used for many different types of events, from small meetups to large festivals and conferences and everything in between. For our most sophisticated customers (and most enterprise businesses), it’s not a bad approach to ask customers what they want, ask them to prioritize how bad they want it, and build and charge for things in that order. For less sophisticated customers, it’s still likely a bad idea. This ends up creating two spectrums to help you understand what to do by level of sophistication of the user vs. how much data users generate. Each of these quadrants tends to have a different approach to de-risking projects.

So what this implies is that our approach to de-risking projects should be very different depending on the type of customer we’re building for. Eventbrite isn’t Instagram, but we do have a lot of consumers compared to most companies. So, attendee experience projects are going to bias toward a data-first approach with research to back up the why when needed. They will also be the most likely to AB test. The self-service creator side of our business is more towards the middle of these axes. So we’ll blend some data and some research needed in addition to direct or proxy customer feedback. We also have segments of frequent creators that are smaller in number, but more sophisticated than the average self-service creator, so direct feedback plays more of a role in what we build, but it also has to be supported by data and user research. When we expanded our sales team into enterprise segments in the past, we were much more likely to build what they asked for.

A FRAMEWORK FOR DIFFERENT PRODUCT APPROACHES WITH DIFFERENT LEVELS OF AMBIGUITY

Cody Evol, a Director of Product Design at Eventbrite, helped develop one of our more useful frameworks to help us understand how much time we devote to a project. When I joined Eventbrite almost two years ago, every team was describing their project as an MVP, which is quite strange, as the Minimum Viable Product framework was built for launching new products, which is not what most teams were doing.

Product teams using inappropriate frameworks off the internet to justify their approach? Inconceivable!

The key thesis of Cody’s design quality framework is that the level of investment before something reaches a customer is tied to how confident we are that we understand both the problem and viability of the solution.

Your development approach should change based on how ambiguous the problem and ideal solution are.

When there is a lot of ambiguity about the problem or the solution, we should generally try to de-risk the project before investing a lot of time into it by using the approaches above. And we have many tools at our disposal to do this. With enough validation, teams should invest in building minimum viable products or features. Minimum viable product is probably the best known product development framework outside of perhaps Agile. It is about delivering value to users by building the smallest product you can to test your hypothesis. You ship to learn, which influences future product development. However, most things we build aren’t minimum viable products. It’s a product development framework for brand new products, and we rarely build brand new products. More likely, we are building features. These can be even more lightweight because you are building something on top of an existing product (you can think of a product as a bundle of features). The “Follow This Creator” feature was a great example of a minimum viable feature on the consumer side of our product. We didn’t know if consumers would adopt it, so we launched it just on Android without even building the push notification functionality. As we saw consumers adopt it, we built it for iOS and web and with email and push functionality.

The goal is usually to reduce the ambiguity around the product problem and solution so that you are not building an MVP/MVF, but instead doing phased delivery. This is a type of development where you have a strong vision and the problem and solution are validated, so the goal is to build toward that desired vision, and release incrementally as valuable pieces of that vision are complete.

MVP’s and MVF’s are to prove that our ideas actually solve a problem. If we prove that, we typically need to invest a lot more to reach the potential of the product or feature idea. Rarely do MVP’s or MVF’s crush expectations out the gate.

OUR APPROACH MOVING FORWARD

When projects are de-risked, we start building the desired product directly in phases. No shortcuts on design quality. No accumulation of technical debt to “get something out”. These are features we intend to be very valuable and support for a long time, so they should be built the right way. But how do you break up the product vision into phases when you have such a clear vision of the whole you want to build? Shouldn’t you just build it all upfront? There are a few reasons this is a bad idea. One is that if you wait to deliver some value to customers until all of the value you envisioned is completed, customers are dealing with sub-par experiences that do not improve for a long time. It is better to deliver some improvement over time than no improvement for a long time, and then a big reveal. Otherwise, you are holding back things that could add value to them today unnecessarily. Secondly, even with strong visions backed by data, usage of products can surprise you. It’s better to get the learning from usage incrementally over time to make micro-adjustments to the vision. Getting no feedback from customers on what you’re building for a long time is dangerous as customer preferences evolve. Lastly, releasing regularly allows you to de-risk your vision technically as well. You get to see how what you’ve built scales or breaks incrementally instead of all at once.

What if there is no way to break up the value delivered to the customer in phases, meaning it’s literally not valuable until all of the work is complete? It is generally still a good idea to release the code incrementally to de-risk the technical aspects of the project even if the customer doesn’t see it. One of my favorite recent examples of this is Apple. Hardware is usually very expensive to iterate on compared to software. Apple was working on a multi-year effort to launch Apple Pay using a customer’s fingerprint as the verification. Instead of launching a new way to authenticate and the credit card payment at the same time, it launched TouchID on the iPhone 5S to see if fingerprint authentication would be a successful interaction. That de-risked the launch of Apple Pay on the iPhone 6 using fingerprint for payment.

To bring it all home, product development is hard. You can’t read one article on the internet and all of sudden build great products, just like you can’t talk to one customer and know exactly what to build. We create frameworks not so that we can shut our brains off and follow an exact guide to building our product, but so that we can focus our brain power on the thousands of other very confusing and ambiguous questions we will undoubtedly face in trying to build this product over time. I hope these frameworks can help you understand how Eventbrite approaches situations it comes across, and gives you some things to think about as you build products.

Thanks to Cody Evol for his help on these frameworks.

Currently listening to Pool by Skee Mask.

Why Product Leaders Fail

I’ve yet to meet a fellow Chief Product Officer or Head of Product say, “yeah, I’m crushing it right now.” In my conversations with fellow product leaders, there’s even a meme that’s started to form around product leadership roles. Effectively:

“Yeah, you just try to put some points on the board before you inevitably get fired.”

So, if a typical CPO feels their role is about trying to survive a couple of years i.e. long enough to help the business a little bit, what is causing that? Why is it so hard to endure as a product leader?

I would say there are three common failure modes depending on how far along the company is. The earlier stage of a company it is, the more likely the answer is going to be misalignment with the founder/CEO. What no one tells product leaders when they accept product leadership roles is that nine times out ten the founder and CEO still wants to drive the product vision. They want you to help execute that vision. And as founders scale, their founder intuition ebbs in effectiveness in comparison to product expertise in-house, but it takes a long time for founders to accept that. That transition period can be very rocky.

For later stage companies, the more likely answer is that the CPO is really only good at one type of product work, and the type of product work needed for the business changes over time. This can manifest in two ways: The product leader has skills that don’t match the type of job needed today, or as they execute, the skills needed change, and the leader cannot adapt. Not only is the product leader not good at that new job, they are also less likely to be interested in it.

Let’s talk about each of these failure modes and what both product leaders and CEOs can do to make them less likely to happen.

Failure Mode #1: Who Owns Product Vision?

Founders tend to have insanely good intuition about their customers and products because, let’s face it, no one has spent near as much time thinking about them and their problems. When startups tend to hire product leadership, it’s their first time hiring this type of leader. Interview processes can be clumsy or unoptimized, with the founder still figuring out how to articulate the real need. Commonly, what happens during this process is both the founder and prospective product leader end up jamming together on the future product vision. Both sides love this engagement, but for the founder, it’s not an effective test on how much the prospective product leader will help the founder, and for the product leader, it can give a false impression that they will have a ton of say in the product vision.

If at all possible, founders should leverage outside expertise to structure the recruiting and interview process for this type of role. One of the key questions to get explicit on before the process begins is what role will this leader play in setting the product vision? For non-product/eng/design founders, they may be asked to define it. For founders with product, eng, or design backgrounds, that is typically not the case until the company becomes much larger. Product executives usually play a consulting or execution role in a vision that is founder led. Founders need to tell candidates which one it is, and candidates need to ask. Neither of these happen as often as they should. 

Once founders understand their answer to this question, they need to vet for the appropriate skills. If what you really need is help executing on the vision, don’t spend much of the interview process jamming on the vision. Sure, candidates need to understand the vision, but what you really need to learn is are they comfortable receiving a vision from you and bringing it to life in the myriad ways that are difficult. 

Failure Mode #2: Does the Expertise Match the Type of Product Work Needed?

Different companies require very different approaches to their product strategy to be successful over time. Most of us understand there are different types of product work. There is tech and process scaling, there is building new products to find new product/market fit, there’s building new features and iterating on the user experience to strengthen current product/market fit, and there is growth work to get the maximum number of users to experience the product/market fit that exists. Traditionally, product leaders lean toward being experts in one or another. For example, I am definitely most known for my expertise in growth.

Founders often lack the understanding of what type of product challenge they are actually facing when they attempt to hire a product leader. Network effects businesses tend to focus more on growth because more users make the product stronger in a much more meaningful way than new features. DTC ecommerce companies / brands are always launching new products. SaaS businesses tend to need to launch lots of new features over time. Hiring a product leader that wants to build new features all the time into a network effects business likely isn’t going to work that well.

Failure Mode #3: Can the Product Leader Adapt as Needs Change?
Even if founders hire the leader with the right skills at the right time, as companies scale, how much weight they put on these will need to change over time. Today, the product leader’s job is to be what the business needs them to be. So while the old school product leader is a specialist, the new school product leader needs to be a chameleon, who can balance a portfolio across scaling, new product work, feature work, and growth weighted toward the needs of the business, and re-weight it considerably over time as business needs change rather than leave once business needs change. That’s hard, but inevitably how product leaders have to evolve to be successful over the long term within a company.

As a growth oriented leader, I am actually spending more of my time at Eventbrite on scaling, features, and new product expansion work, because that is what the business needs right now.

—

Product leadership is incredibly hard. Both founders and product leaders can eliminate some of what makes it so difficult by aligning on expectations before hiring roles, and on aligning which problems the organization is focused on right now. It is then up to product leaders to be able to evolve as the product needs change over time. They are both the best equipped to understand when needs change and help the organization change with them.

Currently listening to Rare, Forever by Leon Vynehall.

Career Paths, Personal Missions, and Concentric Circles of Impact

Often, people ask me for career advice or how I got to where I am, or more tactically if they should advise companies, invest in companies, start a company or become an executive or whatever. My first instinct is to say, “Why would you ask me? You certainly don’t want to follow any of the steps I took!” To try to make my advice more actionable than that, I thought I’d document some of the key decisions I went through to make a signal out of my career noise.

My career choices have been somewhat unconventional from the outside. I graduated summa cum laude in undergrad to just take an internship at Apartments.com. I joined a 15 person startup to start a marketing team at 25. To say I was unprepared is an understatement. After building up a team and growing Grubhub over five and a half years into a public company, I took an IC role at Pinterest, instead of many executive offers. After three years there, where we tripled the user base and unlocked international, I then decided to… hang out at a venture capital firm. Then started an advising business. Now, I’m a Chief Product Officer at Eventbrite, a public company.

No one would draw up a career path this way, but I focused on learning potential at pretty much the cost of anything else, and it’s served me well. What a lot of young people don’t understand is that if you bet on increasing your learning potential, your earning potential compounds over time. The money will be there if you gather differentiated skills the market values (my knowledge of obscure electronic music, for some reason, is not one of those skills the market values).

This advice is fairly easy applicable and, I think, well understood by a lot of people. If you are making a choice between learning and earning, the former will almost always make sense not only from a happiness perspective, but also from a financial perspective long-term. I want to talk about what happens after you self-actualize in this direction.

Let’s say you’ve spent a decade plus collecting valuable skills, applying them in interesting ways, and you are differentiated on the market. Problem solved, right? You’ll never have to worry about a job. You’ll have all these opportunities. Well, not really. They say in startups the problems never get easier; they just change to different problems. I think optimizing your career is the same way. What people don’t tell you is if you optimize for learning, there are fewer and fewer jobs where you can mix all that you’ve learned together. And that you actually have to pick amongst many competitive opportunities. Not picking or not leveraging all your skills can leave you unfulfilled, like you’re not at peak potential, or lead to some of your skills atrophying from lack of use.

As someone who went through this issue after Pinterest, I did some deep reflection on what makes me feel fulfilled on a path to a personal mission. I’ll share that mission as perhaps a useful example, but yours will almost certainly be very different, or even optimize on different attributes like industry, problem type, relationships, etc. After reflecting on what I liked and didn’t like at all the different companies I worked for or with, I realized I really enjoy problem solving. Specifically, figuring out problems related to building businesses and ensuring those solutions can be shared with others. Now, those solutions aren’t growth hacks or tips and tricks, but generalizable frameworks that can be wielded in the appropriate situations. I eventually landed on a personal mission of discovering and scaling the best practices of building companies.

What I found from my advising work is that the best practices of building companies are very unevenly distributed. And it isn’t that one company has all of them and isn’t sharing. It’s that companies are good at different things, and there isn’t even cross-pollination of these best practices so that every company gets better at operating. In fact, I’d say most companies in Silicon Valley in aggregate operate poorly. It’s a weird paradox that the best performing companies are some of the most poorly run, because they can be. As Rick James might say, product/market fit is a hell of a drug.

Like finding product/market fit for a company implies a product people value and a way to make money at it and scalably distribute it, the next question comes in how to deploy this personal mission. I played around with almost every model: full-time employment, advising a handful of companies in-depth, investing and helping the companies I invest in, creating courses with Reforge that anyone can take, and blogging for anyone who wants to read. There is an implied breadth and depth of impact and learning from this model. Focusing all your time on one company has the most impact on how it operates, but that scales the least of any model. Blogging reaches the most amount of people in aggregate, but with no customized learning.

What I have found interesting about my personal mission is that while there are clear trade-offs, there are also win-wins. The blog creates advising opportunities. Operating full-time at one company makes me a better advisor, course creator, and blogger by the depth of problems I get to work on. Advising allows me to see fresh perspectives that broaden my problem solving at my current company. I have not found a perfect formula to optimize the ratio of time spent between these different avenues to deploy against my mission, but what I did learn is that it is likely best to vacillate between the different circles, which is part of the reason why I am not a full-time advisor like I was in the past. This is basically a form of optimizing for different steps in my learning loops to continue to unconstrain my personal growth, much in the same way I optimize for unconstraining growth in the companies I work with.

Finding a personal mission and thinking about how to deploy against it is something I would recommend more people spend time exploring for themselves. I think it helps optimize for personal happiness and growth in an environment where there are seemingly competing opportunities all the time that are hard to judge against each other.

The Types of Product Team Organizational Structures

There is no one perfect way to structure a product organization within a company. Like most things in a company, organization structures only make sense for given moments in time, and as changes happen with the business, so does the organizational structure to match. Product teams are no different, but they tend to vacillate between four different types of structures over time, which I’ll explain along with their pros and cons. These structures tend to work best when aligned with how engineering, design, and other partner functions are structured, so there are 1:1 relationships between leadership roles in those functions.

Alignment of Structure

By far the most important rules of product organizational structures is that they should closely mirror the partner functions. So engineering, product management, and design should tend to have structures that match each other whenever possible. This can’t always be 1:1 as engineering teams tend to be much larger, but if engineering is organized in a very different way from, say, design or product management, it can cause many problems. It can create misaligned incentives as well extra coordination between managers as one director may have to interface with four different peers to align their work instead of one. Assuming the company tries to align all of the development functions, let’s talk about a few ways they can be aligned.

Organization by Type of Product Work

In the Reforge Product Strategy program, we talk about the different types of product work. A common organization structure is to separate teams based on the type of work they are doing. One pillar is the innovation pillar working on new products. One pillar is the core pillar trying to strengthen the core product with additional features and maintaining the core. One pillar is the growth pillar trying to grow overall usage of the current product. One pillar is the platform pillar working on internal features that support other product and engineering teams to allow them to scale. 

The organizational structures can be quite stable, but the level of investment in them can change quite dramatically over time. Product leaders need to consistently be thinking about the right allocation between these different types of work and changing resourcing among them based on the needs of the business. This reshuffling can create change fatigue of individuals that have to move around teams.

Organization by Customer

If a product has different types of customers, a common structure is to separate product teams by the customers they build for. This is very common in marketplaces that have supply and demand teams, or in subscription companies that have self-serve and enterprise, or free customers and paid customers. This allows product people to become experts in understanding their customer well to deliver them value. 

These organizational structures tend to be very stable in marketplaces, but less so in subscription companies if the contracts between those teams are not written correctly. For example, I’ve seen companies that have split into free and paid where the free team is penalized when a person upgrades, which should be the very goal of a free plan. But, since the free plan was goaled on usage, whenever someone upgraded, their usage was removed from the free pillar’s metrics. Even in marketplaces, there can be issues with this model as great products are things that benefit both supply and demand, and it’s hard to build a great product if you only know one side well.

Organization by Value Proposition

If a product has different value propositions, a common structure is to separate product teams by those different value props. For example, at Pinterest, we thought about our value props as Discover, Save, and Do, and had different product pillars for each of those value props. This makes it easy to align OKRs or goals to the value you’re trying to provide your users.

This organizational structure can last for quite a while as value propositions do not change dramatically over time in most companies, but some necessary product functions don’t easily fit into this structure. Great product goals tend to be focused around value created for the customer that, in the long run, create value for the business. Value prop structures are more likely to ignore or de-prioritize that second part of long run value for the business. These structures can also overly focus on the product engineering part of the engineering stack as their goal is to deliver more value. If not handled correctly, this structure can lead to an under-investment in important maintenance, scaling, or growth work as the desire is always for new features that aid in delivering this value prop.

Organization by Initiative

Companies tend to have strategic initiatives that emerge from annual planning, so a common organizational structure is to align product and engineering around those initiatives. This process can work well when initiatives are new, and the organization isn’t sure what types of product work will be most important to succeed in an initiative yet. The initiative structure allows PM’s and engineers to flex between innovation, growth, scaling, etc. as needed to support the ultimate outcome for the business. This requires product folks to be more agile in their planning and in the skill sets they are leveraging. We organized this way at Eventbrite when I started as Chief Product Officer.

This organizational structure tends to be the least stable because initiatives change frequently or at least on an annual basis. Once the type of work that is required to be successful for an initiative becomes clear, many times teams like to specialize by switching into one of the other structures above.

Mixing and Matching 

What a lot of companies end up doing is mixing and matching a couple of these approaches to fit their needs. For example, while Pinterest used the value prop structure for the core product team, it also had growth and monetization teams to balance the business needs of the company. That combination proved fairly stable for a while. No organizational structure is perfect, and emerging trends in product, like having product managers work deeper into the technical stack on platform, infrastructure, and DevOps, will continue to shape changes in how product leaders structure their teams to drive effectiveness. Nevertheless, it’s important to think through the tradeoffs of different organizational structures to make sure they match best to the needs of the company at the specific point in time. What is most important is aligning this structure between engineering, product, and design as much as possible to the teams work in unison.

Currently listening to Hand Cranked by Bibio.

Should You Pay Attention To Competitors? It Depends On Your Company’s Conflict.

I don’t remember much from high school literature classes, but one of the key frameworks I do remember is the different types of conflicts in storytelling. Now, the internet is confused over how many types of conflicts there are. Much like the 4P’s of Marketing are now 7, scholars are adding more types of conflict in storytelling over time. When I was taught this, however, there were three we focused on; whether the protagonist was fighting against:

  • nature
  • another person
  • themselves

Why am I talking about high school literature frameworks? Because every company has a conflict as well. The type of conflict a company is in will determine how you think about competition. I’ll describe these conflicts in more detail, how they apply to companies, and how to think about what to do in each situation.

Company Vs. Nature

Every founder I speak with can name dozens of competitors. That does not mean they are in conflict with another company. Take Grubhub, for example. When I joined, we had raised $1 million in venture capital, and had three competitors all about the same size, but with different strengths and strategies. But this was not a competition about who would become the leader in online ordering for food delivery. This was a competition against nature and to make food delivery more attractive to consumers, and if they were ordering delivery, competing against calling restaurants on the phone. At the time, 99% of people were not ordering food online.

Most startups are in a conflict against nature. There is a status quo in the market – or some other type of barrier to adoption like, say, a global pandemic (“too soon!” shouts my co-workers) that has to be overcome for any type of company in the space to be successful. Normally, startups engage in trench warfare to grind against the status quo over time. Online ordering for food delivery went from a very fringe thing to a completely normal thing that everyone does. Mike Evans, Grubhub co-founder, famously said, “we were an overnight success ten years in the making.” Occasionally, nature provides catalysts to growth as well. Just talk to any telemedicine startup, grocery delivery service, or remote work tool about what happened to them when the pandemic started. The technology already existed for all those companies, but consumers needed a forcing function to accelerate adoption.

If your main goal is to grow the category and make people want its value prop in general, obsessing over competition isn’t very helpful. This is how we felt at Grubhub. We didn’t care too much about competitors at all and focused on our customers. This prevented us from wasting precious time analyzing our competitors instead of our customers, which is what would really help us be successful. Eventually, Grubhub acquired those initial competitors or made them irrelevant. When we acquired those companies, we found they spent a lot of time thinking about us. Now, one can make the counter-argument that that is because we were winning. This is a very important point. If any competitor working to grow a category is being materially more successful than another, you may shift into another type of conflict.

Company Vs. Another Company

In many markets, companies fight vehemently against competitors. Companies are embroiled in a Red Queen effect, where each company is trying to out-innovate or outwork others in the market to gain market share. Think of Uber vs. Lyft as a recent example. Startups frequently think they are in this type of conflict when they are not. I have seen quite a few startups emphatically compete before they are even sure the category will be successful. In many of those cases, it would be better to cooperate and grow the category faster by being coordinated. Stripe and Shopify are an interesting example of this. The categories of ecommerce and online payments are growing so fast that instead of competing with each other, they have tightened their partnership to make sure the category continues to grow quickly. Uber and Lyft however tracked each other’s moves, and responded in kind to new product launches, pricing changes, and market launches. Both of these moves look correct in hindsight. Uber and Lyft’s market, while growing fast, would ultimately be capped by consumer transportation needs, and lean toward a winning take most model due to the strength of the local network effects involved in the model. While Uber and Lyft have been competitive, they ultimately saw value in presenting a unified position on local regulations and working together to ensure its services would remain available throughout cities worldwide. So company vs. company can change depending on the fight back to vs. nature.

Company Vs. Self

The third type of conflict within a company is one many founders and employees seem to forget: competing with themselves. In this type of conflict, the primary fear of the company is not that the market doesn’t unlock or that a competitor will take your opportunity; it’s that the opportunity isn’t realized because the company cannot execute on the strategic vision. This type of conflict can be dominant for many reasons:

  • Internal politics
  • Lack of focus
  • Execution issues e.g. technical and process debt

Investors frequently call this “execution risk.” A company in conflict with itself means the vision is definitely technically possible (hence, not technical risk), but the company struggles to build toward it either due to being unfocused, people internally competing vs. cooperating, or building is very difficult due to technical or process issues. These types of companies can be appealing to certain types of executives who think they can fix the underlying execution issues. The reason for this is that if these companies do everything right, they win. This is certainly true. But it is not easy. Evernote is a recent example. Technical debt slowed their progress to a crawl, so the new CEO spent two years rebuilding everything. During this time, growth was slow, and more competitive risk emerged with companies like Notion, Coda, and Roam Research. If the company is finished with its conflict with itself, it likely finds itself in conflict with other companies now.

It is tempting to say in this example that Evernote should have paid a lot of attention to these competitors early on, but I think that would have been a mistake. The entire issue with Evernote seemed to be that they spent too long building new things on top of a technology stack that became unbearable to maintain. Movements in the market have no impact on fixing that core problem.

—

The type of conflict you are facing affects a lot of how you build and what you focus on as a company. Spending some time to think through where the real conflict is can help focus the company on the right activities to win. This can affect how much you invest in marketing, the focus of the product roadmap, and even organizational structure. Tackling the appropriate conflict is where the real leverage is in growing a company.

Currently listening to my Vocal Tones playlist.

Casey’s Guide to Finding Product/Market Fit

As a product leader with a background in growth, it’s surprising how much what I actually end up working on is product/market fit. Product people should only be focused on growth i.e. connecting people to the value of a product once they’ve confirmed the product is delivering value. So it’s important to have a strong understanding of what product/market fit looks like before investing in growth. Founders and product leaders struggle with answering this question however, and advice and blog posts on the internet frequently espouse that you’ll know product/market fit when you see it, and that all of a sudden everything will start working. It’s not very actionable advice. I don’t claim to be the world’s foremost expert, but this is what I learned through scaling multiple startups, launching new products, and advising and investing in dozens of companies.

The Quantitative Approach to Product/Market Fit

I define product/market fit as satisfaction that allows for sustained growth. Satisfaction is tricky to understand because, well, customers are rarely truly satisfied. Jeff Bezos frequently drops pearls of wisdom in his shareholder letters, and my favorite of them is the following:

One thing I love about customers is that they are divinely discontent. Their expectations are never static – they go up. It’s human nature. We didn’t ascend from our hunter-gatherer days by being satisfied. People have a voracious appetite for a better way, and yesterday’s ‘wow’ quickly becomes today’s ‘ordinary’.

To put that in product/market fit parlance, product/market fit has a positive slope. The expectations of the customer continue to increase over time, and in fact, total satisfaction is likely an asymptote impossible to achieve. So what is product/market fit then? Product/market fit is not when customers stop complaining and are fully satisfied. They’ll never stop complaining. They’ll never be fully satisfied. Product/market fit is when they stop leaving. Represented visually, customer expectations are an asymptote a product experience can rarely hope to achieve, but product/market fit is a line a product can jump over and try to maintain a higher slope than over time.

All products start below a theoretical product/market fit line and some cross that line and work to stay above it over time.

So, for most businesses, instead of measuring satisfaction, measuring retention is the best signal of product/market fit. Measuring retention is pretty easy. Perform a cohort analysis, graph the curve over time and see if there is a flattening of the retention curve. As I’ve discussed before, what you measure for your retention curve matters quite a bit though. For your product, there is usually a key action the customer takes in a product that best represents product value. For Pinterest, it was saving a piece of content. For Grubhub, it was ordering food online. For your product, there is also a natural frequency to product use. For Pinterest, we eventually determined that people would browse sites for topics of interest on a weekly basis. For Grubhub, people usually ordered food once or twice a month. Once you have a key action and a designated frequency, the cohort graph should have the key action as the y axis and the designated frequency as the x axis. This does not mean companies should ignore other measurements of satisfaction, but to understand definitively what product/market fit looks like, this is the best start.

This graph measures a group of users and how many of them perform the key action of your product over time. There will usually be a stark drop at the beginning, but for products with product/market fit, a percentage continue to find value consistently.

If you’ve been around startups long enough, you’ve undoubtedly seen startups with retention of customers that struggle to grow. If you’re not growing, you definitely do not have product/market fit. So product/market fit cannot be measured by retention alone. That retention has to create sustainable growth, which means the rate of retention matters. Why does the rate of retention matter? Well, most acquisitions of new customers come directly from retained customers through a few key acquisition loops. Either retained customers: 

  • talk about the product to others to attract them to the product
  • invite people directly to the product to attract them to the product
  • create content that they or the company can share to others to attract them to the product
  • make the company enough money that the company can invest that money into paid acquisition or sales loops with a healthy payback period to attract them to the product

I’ve seen many founders misunderstand this, looking for growth hacks to drive growth or a PR bump. These types of tactics are only useful if they help you sequence to a sustainable growth strategy, but they rarely are sustainable growth strategies directly. This is why other measurements of satisfaction can still be important. If it doesn’t exist, the first two of these loops are impossible to drive growth from.

Sustainable growth is measured by one or more of these loops growing the size of your monthly acquisition cohorts month over month with a flattened retention curve. A flattened retention curve of your key action at the designated frequency plus month over month growth in new customers is the best way I have found to measure true product/market fit. If the rate of retention can’t support acquisition loops that continue to scale new users, retention needs to be improved to find product/market fit. Some companies can scale with 10% retained users, and some may need 40%, all depending on the strength of the acquisition loop. The graph below represents one month’s cohort retention over time vs. monthly growth in new users.

Consistent flattening of a month’s retention curve over time plus growth in new users every month is true product/market fit.

What if satisfaction of your product cannot be measured by retention? This happens. Some products are one time use or extremely infrequent in nature. In that case, I like to use custom surveys to measure the level of satisfaction depending on the nature of the product. Rahul Vohra describes the process they used at Superhuman for this, and it is excellent. Don’t forget to measure new user cohorts month over month though. Acquisition becomes even more important in these scenarios.

The Paths to Product/Market Fit

It takes most products a couple of years to find product/market fit. If you are not there yet by the above measurement framework, don’t be alarmed. The first step is to understand how far along you are and the approach to improve. There are two stages of the push toward product/market fit:

  • Building enough of the product vision so that the product is valuable and ready for customers
  • Getting customers to understand and receive the value you’re targeting for them

If you are in the first phase, you generally aren’t allowing customers to use the product anyway to measure product/market fit. There are two main schools of thought for how long you should stay in the first phase, which I will oversimplify into calling the Eric Ries model and the Keith Rabois model (unfair to both of them), and they are diametrically opposed on many axes including how long you build before you allow customer access. Thinking about these axes will help you understand what to do next and what successful companies did in this phase. I will outline some of the main differences below.

This is certainly oversimplified, but should help give an idea of the spectrum of things to consider with a new product. Let’s break these down in a little more detail.

Time To Market

The Ries model emphasizes talking to customers early and often to understand what to build, and whether what you have built is actually solving problems for them. The Rabois model is so driven by the vision of the founders of the company that customer feedback is less important than building what the founders have envisioned before any customers interact with it.

Success can be achieved by both modes. In the food delivery space, Tony Xu and the founders of Doordash and Arram Sabeti, the founder of Zerocater, famously used spreadsheets and founder manual labor to prove out their early models before investing in a lot of technology to scale. Shishir Mehrotra, the founder and CEO of Coda, spent four years building the product before any public launch, and now the company is growing quickly. In reality, companies that take longer to reach the market usually have alpha or beta customers that are still driving a feedback loop into the product. Coda used employees at Uber, for example. 

Focus

The Ries model tends to target a customer segment and attempt to find out their pain points to build something valuable. The Rabois model starts with a strong vision of both a problem and a target solution and works to build that from the start. The Ries model is common in enterprise business where customers just want to deeply understand data scientists or general contractors or some other segment, identify a problem they deal with a product solution could solve, then build and test with that segment. Here, you’re more likely to see some early pivots as companies try out different solutions to the same problems or target different problems of the same type of customer. We incubated a few of these types of companies while I was at Greylock with success, but it was rarely the first iteration that was successful.

One issue with the Ries model here is successful product/market fit rarely avoids all speed bumps. Without a strong vision and motivation by the founders and being “in love with the problem”, those speed bumps can instead appear to be roadblocks causing companies to change direction too early, causing a lot of “failing fast”, which is just a more acceptable way to say failing. The Thumbtack founders are a good example of grinding through these moments and not giving up on eventual product/market fit.

Many founders with vision put out a product experience and eventually find a market interested in that product solution. TikTok and Houseparty didn’t initially set out to build a product for children. Clubhouse started blowing up in Atlanta, and its founders are both in Silicon Valley. Square and Faire, however, had pretty strong ideas of their initial target markets and did find product/market fit with those markets.

Initial Launch Goals

The only goal of launching a product in the Eric Ries model is to generate feedback from the target customer. These launches are generally limited in size to receive enough signal from the target customers to know if something is working or not. The goal of a launch in the Rabois model is to achieve the initial vision that sparked the creation of the product. Launches are usually broader in this model, because the product may be looking broadly for a market that will be attracted to the product solution being launched. Even if there is a strong thesis for a target market, launches are more likely to go big to try to reach the maximum amount of the market possible, because the product should be ready to provide them value day one. In network driven businesses, a bigger effort out the gate may be required to reach the liquidity necessary for people to experience the product/market fit. In marketplaces, this may be sequenced by targeting supply or demand first, but with direct network effects, it is more driven by volume. Twitter and foursquare both launched at SXSW to get initial liquidity correctly. At Grubhub, whenever launching a new market, we would target to sign up 50 restaurants in the first two weeks to have a good selection to show consumers. 

Changes to Vision

The Eric Ries model is very flexible on vision, and companies on this side of the spectrum frequently pivot around customer needs quite a bit. Instagram, Twitter, Groupon, Slack, Pinterest, GOAT and many other successes started in one direction, and through either failure, seeing only part of their initial idea work, or fresh thinking altered their product and mission dramatically to find product/market fit. In the Rabois model, a singular vision drives the company from the start. Opendoor started with a mission to remake real estate through data science and instant sales, and has not strayed much from that vision. 

I think this is an area where despite all the news we hear about successful pivots that leaning more towards the Rabois model is a dominant strategy. Blindly trying out a bunch of startup ideas is like being in a dark room and feeling around for a door. A successful vision can turn on a light to that room so everyone can see the door and run toward it. Even many of those major pivots were guided by a strong, albeit new, vision from their founders.

Growth Strategy

The Eric Ries model thinks about product change as the main way to unlock growth in the early stages. This requires a tight feedback loop between customers and the team so the team can tweak and adapt and potentially built totally new things to please potential customers. You’ll typically see these types of companies leverage growth hacks that are long-term unscalable, but could get the initial product to more people efficiently. The Rabois model implies product changes will be more difficult. The product vision is usually taxing, so relying on product change to grow is very expensive. Rabois prefers to leverage a strong go to market model and heavy marketing muscle to scale usage of the product. Neither of these models go particularly in depth on scalable growth loops, and of course I believe thinking in terms of the scalable loops you’re unlocking is a dominant strategy.


Risks

It’s weird to talk about failure modes in starting companies as most companies do fail. But there are tendencies of failure types in each model that founders should be familiar with as they are avoidable. The Eric Ries model tends to lead to either iteration to no eventual destination or a lot of “failing fast” that feels like progress and isn’t. We saw a lot of this with startup studios five or so years ago. I can’t recall one of them creating an enduring company. The Rabois model has entirely different risks. This is where you can find solutions looking for a problem, like many crypto pitches you hear these days (how many ICO’s found product/market fit? Is there even one?). Some memorable failures in this area in the past are Color Labs and Clinkle. These companies can spend so much effort selling what they have really hard without ever confirming people want it. Startups in this area can also become so consumed in their vision they fail to actually launch. Magic Leap is a recent example of this in the AR space. The Rabois model can also hide some of the key insights to unlock the market if not careful. Instagram and Pinterest only had a small part of their original visions work, so they pivoted to focus on just that element to build massive businesses.

Applicable Company Types

While these models can be used for any type of business, they tend to lean towards certain models. The Eric Ries model is very common in enterprise businesses because founders are confident certain segments have day-to-day problems that aren’t solved and money to pay to create a reliable business model, so they learn all about that segment to find that problem with the willingness to pay to solve. The quick to launch elements are common in marketplaces where matching can be done manually to validate liquidity before investing in a lot of technology. The Rabois model is more common for hardware because iteration has such long timelines, and consumer models where typically founders have new habits or interactions they need to convince a broad market to try.

So Which Should You Use?

Hopefully, you see from these examples that either extreme is pretty dangerous, and even those that vehemently believe in one of these models over the other seems to have selective memory as to when companies veered away from their approach when appropriate. Founders should build a strong opinion over which parts of which model they need to apply to maximize the chance of finding product/market fit for their business. My personal belief is a strong vision combined with market feedback is a pretty dominant combination of these two approaches whereas many of the other axes depend on the product you are building. I actually find both models fairly weak on the growth strategy side. “Sell tickets” ignores how the product is frequently the most effective way to unlock growth through strong acquisition loops. Assuming new products equals new growth is a “build it and they will come” fantasy unless you get lucky.

—
The reason to understand what product/market fit looks like is of course important for founders of companies. While measuring the product/market fit line directly is impossible, measuring whether a company is above it or not is possible by measuring retention curves and new user growth. If the retention curves every month flatten and new user numbers increase at a healthy payback period, you can feel confident you have product/market fit. If you can’t say this for your product, I hope I’ve been able to give you some axes to understand what you need to work on and how to apply it to your specific product. The next problem is to scale it and keep as customer expectations continue to grow. If you want to learn more about these concepts, we expand on them dramatically in the Reforge Product Strategy program.

Currently listening to my Scrambled Eggs playlist.

Thanks to Kevin Kwok and Emily Yuhas for feedback on drafts of this post.

Announcing the next cohort of Product Strategy, Advanced Growth Strategy, and more…

I’m excited to announce that public applications are open for the Spring 2021 cohort of Reforge. I’ll be participating along side leaders from Tinder, Facebook, HubSpot, SurveyMonkey, Instagram, and more.

Apply to Join Reforge

Reforge Membership includes participation in a cohort-based program and ongoing access to content from all programs, weekly releases, deep-dive sessions, and a community of vetted peers to help you execute what you learn.

Spring programs run from March 22nd – May 13th

I’ve worked closely with Brian Balfour (CEO at Reforge) and the Reforge team for the past 3 years to develop and host three different programs. Onboarding for the Spring 21 cohort begins March 22nd, the first week of content is March 28th, the first week of live cases is the week of April 5th, and the last week of live cases is the week of May 10th.

Product Strategy

Build, communicate, and execute a cohesive product strategy across feature, growth, scaling and innovation product work.

With Fareed Mosavat (GP at Reforge, Ex Slack, Instacart, Zynga) and Ravi Mehta (Ex CPO at Tinder, Facebook, Tripadvisor)

Advanced Growth Strategy

A step-by-step system to create, analyze, and communicate a growth strategy of compounding growth loops.

With Kevin Kwok (Ex Greylock Partners), and Fareed Mosavat (GP at Reforge, Ex Slack, Instacart, Zynga)

Retention + Engagement Deep Dive

A deep dive on how to understand, measure, and improve retention through activation, engagement, and resurrection.

With Shaun Clowes (SVP Product at Mulesoft, Ex Metromile, Atlassian) and Adam Grenier (Ex Lambda School, Uber)

Other Programs

In the Spring cohort there will be 10 total programs across Product, Growth, and Marketing all built and led by experienced executives. Here is the full slate:

What you get as a Reforge member

Reforge membership combines cohort-based programs, with a year round experience to help you learn, execute, and scale yourself and your company.

Cohort Based Programs

  • 6-weeks, part-time, virtual and intense
  • Built and led by executives
  • Application focused
  • Live case studies with a cohort of peers

Year Round Execution

  • Access content from all programs
  • Step-by-step projects to help you execute
  • Weekly releases, events, and updates
  • Connect w/ peers solving similar problems

Apply To Join Reforge

Scaling your career with top operators

You’ll be joining other top operators from companies like Airbnb, Spotify, Stripe, Dropbox, Zoom, HubSpot, Reddit, and LinkedIn who consider Reforge one of the best professional investments they’ve made.

  • “Even for experienced practitioners, Reforge crystalizes a practical and easily explained series of handy frameworks and immediately gives you a way to approach almost any product in any industry.” – Scott Worthington, Dir of Product Marketing at Peloton
  • “Reforge has the best content of any educational resource that I’ve encountered. It’s the best way to accelerate your career in tech.” – Bangaly Kaba, Former Head of Growth at Instagram, Instacart
  • “Reforge helped me better understand of how my company’s products grow and provided insight into what initiatives can have the biggest impact. Like with any system, the Reforge frameworks are often easy to learn and hard to master. That’s why I like the community aspect of it as well, which helps us learn the challenges others face in implementing the new learnings.” – Sam Beek, Lead Product Manager at WeTransfer
  • “Reforge gave me an understanding of Growth across multiple channels and business goals, and as a new member on Segment’s Growth team, this provided a crucial impact on my day-to-day work.” – Mallika Sahay, Product Manager at Segment
  • More reviews here…

Unlocking the earned insights of leaders

In addition to the experienced executives that build and lead our programs, you’ll hear examples from the industry’s best. Past featured guests have included:

  • Bangaly Kaba, ex-Head of Growth @ Instagram, Instacart
  • Dun Wang, CPO at Calm
  • Melissa Tan, ex-VP Product at Ro, ex-Head of Growth at Dropbox
  • Darius Contractor, Head of Growth at Airtable
  • Jiaona Zhang, VP Product at Webflow
  • Kelly Mayes, Sr Dir Product at Roblox
  • Adam Fishman, CPO at Imperfect Foods, ex-Patreon and Lyft
  • Crystal Widjaja, ex-SVP Growth at GoJek
  • Vaibhav Sahgal, VP Consumer Product at Reddit
  • Justin Bauer, EVP Product at Amplitude
  • Bela Stepanova, VP Product at Iterable
  • Angel Steger, Dir Product Design at Facebook, ex-Dropbox and Pinterest
  • David Bakey, ex-VP Consumer at Harry’s
  • Zindzi McCormick, Head of Activation at Slack
  • Kieran Flanagan, VP Growth/Marketing at HubSpot
  • And many more…

Apply To Join Reforge

To join the Spring cohort, you must apply before February 19th. Once accepted, seats are first come, first serve. If you have questions, contact hello@reforge.com. I hope to see you in the Reforge community!

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.