I recently joined Lenny Rachitsky on his podcast for the second time. We covered a lot of interesting topics, such as why Grubhub ultimately lost to Doordash, over-reliance on frameworks and research in product management, and a deep dive on network effects, SaaS to marketplace transitions, and why consumer subscription is so hard. Listen on your favorite platform below.
Currently Listening to Raven by Kelela.
When founders of startups start to hire employees to work on various parts of the business, it tends to be uneasy for both the founder and the employee early on. The founder may have done that job in some capacity before they hired for it, but they are not an expert. The incoming employee may bring more expertise, but they don’t know the business yet. The founder is going to have a lot of opinions as is the employee, and they won’t necessarily match. In this essay, I’ll talk about how to think about balancing founder intuition vs. team expertise, and how that changes over time. I find that this same balance is true for customers vs. founders when they start businesses too, so we’ll cover that as well.
Generally, the biggest mistake founders can make when starting to hire a team is defer too many decisions too quickly to new employees. This is most painful with new executives, but can also be damaging when hiring new individual contributors. Founders frequently convince themselves that this new person they hired is an expert on this topic, and they should defer to them. The opposite actually tends to be true. The founders are experts on the business. And incoming employees should defer to them until they are confident they have become more of an expert on a certain aspect of the business.
The opposite mistake tends to happen later on as the business grows. The founders have now staffed the company with a lot of great talent who have had time to learn the business, have impact, build processes, know customers really well, etc. Meanwhile, the founders are scaling a bigger business and getting further away from the details. Founder intuition becomes less reliable because the founder(s)’ advantage of having spent more time on the problem goes away. Their thoughts become perhaps dated. And they won’t really know it. This degradation of founder intuition also happens at different times for different parts of the business.
Great founders start to back away from relying on founder intuition when they see the expertise developing on the team, or are proven wrong in a meaningful way by the team that makes them start to question their often blind faith in their own judgment. Moving forward, founders have to calibrate how their intuition stacks up against team expertise on every topic of the business to know how much to intervene vs. let the team drive. Think of this as a simple graph.
It’s incredibly hard to accurately graph where the founders and team are on this graphic for every topic within the company, and when they cross. Normally, founders tend to navigate this based on factors like personal interest, what areas of the company they perceive to be doing well or not, etc. Having worked with lots of founders myself as a leader, advisor, investor, or board member, I default to founders needing to operate differently at different stages. On a bunch of different axes, I have mapped how I think companies optimally behave as they grow (changes in italics).
| Phase 1: Starting | Phase 2: Scaling | Phase 3: Expanding |
| Founder makes decisions | Founder starts to delegate decisions | Founder empowers team completely |
| Speed > Precision | Speed with some precision | Precision > Speed |
| Generalist > Specialist | Specialist = Generalist | Specialist > Generalist |
| Done > Perfect | Done > Perfect | Done Perfect Trade Off |
| Focus > Breadth | Focus > Breadth | Breadth Focus Tradeoff |
| Execution > Strategy | Execution > Strategy | Strategy = Execution |
| Hungry > Seasoned | Hungry > Seasoned | Seasoned > Hungry |
| Cheap > Robust | Cheap Robust Trade Off | Robust > Cheap |
| Teamwork > Process | Some process | Process First |
| Doers > Managers | Doers with some doer-managers | Managers + Specialists |
Obviously, this table can be a bit crude, and understanding when the company is shifting between phases is not always apparent to everyone inside the company. But it provides a default guide on when to delegate and empower teams as a company grows. I find that just asking the question of what phase the company is in builds good awareness on how one might want to be operating at the moment.
If you are a startup employee or leader, you have to respect founder intuition greatly. The company would not have gotten to the point you could have even been hired had that intuition not served the company well. But when you’ve really spent the time to understand the business and you or your team can start to have better judgment than the founder, it’s important to signal that confidence and get alignment on the operating model shifting. It will not be an easy conversation, but worthwhile to have.
What can you gain from such a conversation? First, you make the above graph visible to the founder in a way they may not be aware. Second, you can calibrate where each of you think you are on this graph. If the founder believes their intuition still serves the business better on a topic than the expertise you have built, then you can have a conversation about what would signal those two lines crossing to change how decisions are made in that area? Keep in mind, in some cases, that answer may be that there will never be a signal that changes how much control the founder wants to exert in an area. Companies are not democracies, and founders have the right to run the company any way they want. If they want to drive decisions on what tech stack the company uses or which segments are interesting, they will. If you don’t like it, you should join another company. But most founders want to do what is best for the company, and giving them the signal on where it’s valuable for them to lean in vs. that potentially being unhelpful is worth figuring out.
On the flip side, if the founder is putting decisions on you or your team where the founder would be better fit to make the calls themselves, tell them! There is no shame in admitting you’re not yet equipped to make the calls and empowering the founder to make more direct decisions for a while. This is not an admittance of incompetence. It’s driving clarity on decision-making rights that are optimal for the business. If you’re still asking the founder to make those same calls a year later though, expect them to think you aren’t developing the expertise you should be.
What is ironic about founders and employees facing this split between intuition from expertise is both have to do that same analysis with the company’s customers. When startups are small, most founders and employees tend to think the customer knows best. This may be experienced by changing the product based on customer feedback, allowing customers to experiment with different ways to use the product that help them become successful, etc. But as a company scales, it starts to see every way customers use a product, and what works best. For a marketplace like Airbnb, it might be seeing that hosts that provide toiletries get higher ratings, or for Eventbrite it might be seeing that emailing past attendees of an event a certain time before the next event maximizes their chances of buying another ticket. Then, the company’s job switches from observing what customers are doing and adopting them to teaching customers what best practices the company is aware of that will make them more successful.
So, in summary, founder intuition is extremely valuable, and new employees and leaders should learn to leverage that vs. ignore it because they’ve seen things before. But founder intuition does ebb over time in most areas as founders scale up the company, and of course, teams get a lot smarter as they spend time on deep company problems. This also happens with your customers over time. Having a dialog about where teams are in this journey is important to helping startups scale, clearing a path for teams to have maximum impact, and for leveraging founders’ scarce time in the areas that are most highly leveraged.
Currently listening to my 2022 playlist.
I have written a lot about product/market fit in the past. Whether you are a founder, product or growth leader, being able to recognize and measure product/market fit is a critical tool to make the best decisions on driving success of a company. In the post I linked to above, I make a case on the two metrics you really need to understand about product/market fit: retention and acquisition, and that product/market fit is really about finding a level of satisfaction (usually measured through retention) that will drive scalable acquisition. If you apply this model to a SaaS business, the application is usually pretty straight forward. Measure the retention of your customer, and does either the virality or monetization unlock scalable acquisition loops like sales, performance marketing, referrals, or content. Many founders struggle to apply this same framework for network effect businesses though, and it’s easy to see why. Frankly, it is just much harder. In this post, I’ll break down the nuances of product/market fit for network effects businesses to understand if you’re on the right track.
When a network is a key component of the value prop you are trying to create, and things aren’t going well, it’s hard to understand which is the real issue preventing the product from reaching product/market fit:
I’ll break down some additional insights to product/market fit for different types of network effects to make the product/market fit mystery easier.
Cross-Side Network Effects (Marketplaces and Platforms)
Cross-side network effects can be painfully difficult to find product/market fit for because you are building out a product for two different types of customers that have to align. It can feel like building two companies at the same time. Fortunately, there are some easy ways to navigate this puzzle to make the journey to product/market fit less amorphous. The first is that for businesses like marketplaces, it tends to be easy to understand how to constrain the audience initially. The first thing to understand is that there a spectrum of network effects from global to local:
Based on whether you are pursuing a global or local network effect, you can usually either constrain the audience by category or geography to start: Grubhub started in one neighborhood in Chicago, for example. Amazon started with just books.
Assuming you pick the correct geographic or categorical limit, you can test the value prop and scaling of supply and demand to find liquidity, which is a synonymous term with product/market fit for marketplaces. There is almost always a quality and quantity element to liquidity. If you understand it, you can then measure product/market fit by just analyzing retention and acquisition for both sides of the market.
Platforms are more complicated in the beginning, but eventually follow the same logic as marketplaces; they are just less likely to have a geographical component at the core. Whereas marketplaces need supply to attract demand and are willing to do unscalable things to generate that initial supply like paying drivers to sit idle for Uber and Lyft or delivering from restaurants who are unaware they are on your platform like Postmates and Doordash, platforms tend to have to be the initial supply themselves. Let’s take a look at a couple of different examples. Nintendo has had some of the most successful hardware platforms in gaming across decades. One of their secret sauces is that they seed supply on their platform with games they build themselves that they guarantee are high quality. Now, they can afford to do that with games that are based on incredibly valued IP like Mario, Zelda, and Pokemon. This creates initial demand for a new hardware platform like, say, the Nintendo Switch, that then attracts third party developers to build games for the platform as well. Then, Nintendo can look at demand side retention through purchases of games, and supply side retention through creation of multiple games. This helped them understand that platforms such as the Wii and the Switch had strong product/market fit, whereas the Wii U and GameCube much less so.
The success of the Nintendo Switch was partially due to the console launching with one of the best reviewed games of all time from a beloved franchise: The Legend of Zelda: Breath of the Wild.
On the software side, Shopify and WordPress have spent decades building their own SaaS features to allow the platform to become stronger and stronger with other features built by external developers they would never consider in their roadmap. Now, the majority of the value may be generated by third party developers, but a lot of first party development was required to get them far enough along in customer acquisition to make it attractive for so many developers to build on top of their platforms. You can read more about building successful platforms here.
Data Network Effects (Personalization and Recommendations)
For products that expect to create a better experience through data, the journey to product/market fit is usually about collecting enough data to provide a compelling experience. For some products, this takes a massive amount of time. Pinterest, for example, started as more of a tool for individual users to collect cool things from the internet before it could become a real recommendation engine for things related to your interests based on the wisdom of the crowd. Tinder can recommend great matches after just a few swipes. After I joined Pinterest, we had to make a hard pivot to onboard new users based on topics instead of their friend graph as we realized there was stronger product/market fit as a content recommendation engine vs. a social network. This creates an issue for geographical expansion. By default, we would not have enough data to understand local tastes. To rectify this, we had to reconfigure our feeds to emphasize the local content we had, in the local language, and in the local way of measuring (no more imperial measurements!). And in some markets, the focus needed to be gathering content so we could even have enough local content to display.
Direct Network Effects (Communication Tools and Social Networks)
For many network driven businesses, especially in the social realm, there is a Goldilocks zone of user experience. Too few people or content, and there isn’t enough content to consume or people to communicate with. Too many people or too much content, and it becomes overwhelming, or generates too many notifications. When Yogi Berra said, “”Nobody goes there anymore. It’s too crowded.”, it’s easy to imagine he was talking about Clubhouse, not a local restaurant at the time.
Clubhouse downloads per month. This graph is not up and to the right.
For a marketplace, there is usually a clear way to constrain the audience to generate appropriate retention metrics to evaluate product / market fit. Geography or category is the dominant mode for this in marketplaces. For SaaS, it’s a specific target audience. But social or content driven networks eventually want to scale to everyone, and a lot of times founders or leaders can’t tell which should be the first audience that will hook onto it. The better your thesis, the easier it is to evaluate e.g. Harvard only with Facebook, midwestern moms with Pinterest, USC with Snapchat. So the dominant strategy for building direct networks effect business is to have a strong thesis for the target market, prepare to be surprised both who the target market and right features are, and shift to another type of network effect over time. Outside of communication tools, it’s usually my belief that direct network effect products are actually cross-side network effects products where it’s just too early to understand who the different sides are. So, founders have to understand the user data or have a strong vision for what type of cross-side network effect or data network effect can be created to scale product/market fit over time. Do this, or risk becoming like a lot of other flash in the pan social network fads that failed to scale.
–
My previous post on product/market fit mentioned the Ries vs. Rabois model on finding product/market fit, which you can think of as testing vs. vision. While both concepts have value, attempts at finding product/market fit with network effects businesses tend to reward more of the Rabois model, or else the testing you do will be inconclusive on the reasons why something isn’t working between the core value prop vs. the size of the network. Finding product/market fit for these types of businesses is much harder, but can be much more rewarding in terms of scale if successful.
Currently listening to my Hipster House / Lofi House playlist.
In Crafting The First Mile of Product, Scott Belsky talks about the product lifecycle. In it, Scott states:
Now, myself and others have written before about different ways you should attempt to defy this second step. Let’s say you’ve listened. How do you then keep your product simple while trying to grow, capture new audiences, and add new value props? Is the solution to… not do any of that, like a Craigslist? Seems like that doesn’t work too well given all of the companies that have attacked Craigslist from different angles and built bigger businesses than it. Is the solution to ignore Scott’s warning and rely on network effects or some other deep switching costs to retain users? This isn’t a bad idea, and why companies like Facebook continued to grow despite adding more and more complexity over time. During this time though, Facebook users also flocked to Instagram, Snapchat, TikTok, et al. Is the solution to rely on humans to help customers navigate the complexity? Sounds expensive.
This is one of the key challenges we faced at Eventbrite when we radically shifted our strategy in 2020. Eventbrite was historically a 50% sales and 50% self-service business. The optimal outcome for a business like that is a “good enough” user experience with account managers that can make up its flaws. This is a very common strategy for enterprise companies with large margins. The problem for Eventbrite is we weren’t an enterprise company with enterprise margins. We work with small businesses and independent creators. Talking to humans is a bug, not a feature of what to them should be an intuitive user experience. And these SMB’s and independent creators don’t pay us millions of dollars individually to profitably employ armies of human help.
So, as we decided to take a bet on building an intuitive, self-service experience instead of masking user experience issues with human support, we really had to confront Belsky’s product lifecycle for the first time. Eventbrite over the course of the last decade built out a multitude of different features for all different types of event creators, of all shapes and sizes. We did not have a simple product for event creators at all. It had become quite complex.
When people think of simple products, they typically think of consumer products. That is usually where one looks to find the current peak in user experience. There has been a renaissance of user experience and design in B2B use cases over the last decade, but those typically revolve around single use case products, like:
Creating an event on Eventbrite should feel like that; the problem is how vague the definition of event is. Eventbrite has small meetups, large conferences, niche networking events, merchandise drops, music festivals and everything in between. If you can think of it, we’ve ticketed it. There are only a few types of files to sync, emails to send, or website use cases. Our cases were myriad.
So, how do you solve this problem? At Eventbrite we have surveyed a few different approaches I‘ll showcase below as well as what we think works best for our use case. Our initial approach to solve this problem was to just put the creator first. We designed something we called the adaptive creator experience that learned what type of creator you were, what features you valued, and automatically customized the experience for the features you needed front and center. This made for a great vision, but was practically untenable from a data or scale perspective. So what are the practical approaches to solve this problem? Let’s cover each below.
Approach #1: Validate and Unbundle (Temporary Complexity)
When Eventbrite acquired Ticketfly, we originally attempted to separate the experience into something we called Eventbrite Music. There, music specific features wouldn’t complicate the experience for, say, someone doing their first event for ten people. The more we learned about the Music space, the more we learned it wasn’t the features that needed to be radically different, though that sometimes was the case. It was more that the aggregate user experience that music clients, especially more traditional ones, wanted was incompatible with a self-serve user experience. They wanted very detailed interfaces, dedicated training for dedicated employees that only worked on that part of their business. The concept of creating not different features, but different interfaces, felt like a much larger complication to support. Eventbrite now caters toward more modern music creators that share the need for intuitive and self-service experiences. With Eventbrite’s new strategy, we didn’t really see an unbundling approach based on functionality given our two products on the creator side (ticketing and marketing) are already so intertwined in creators’ workflows, and we no longer differentiate creators by vertical as it didn’t map to product needs well.
Facebook was a different story. One thing Facebook did very successfully as it scaled functionality was to prove out the value of features in its core app and then unbundle them into separate apps later on. This keeps their user interfaces, especially on mobile, more focused and easier to navigate. Facebook has now done this with multiple features across Facebook and Instagram. It hasn’t always worked, but that is usually because the product/market fit of the product isn’t always strong enough to survive on its own e.g Facebook Local (failure) vs. Facebook Messenger (success). Uber did the same exact thing with Uber Eats. I have written about this strategy before here.
The pros of this strategy seem pretty obvious. Leverage the scale of the initial product experience to expose people to the new value prop, confirm product/market fit, then move that new product experience elsewhere so the new value prop’s added complexity doesn’t deteriorate product/market fit for the initial product. The issue with this mentality is that once a product is unbundled, it no longer receives as much new user acquisition from the initial product it was built inside of, and sustainable acquisition loops are a key part of product/market fit. Facebook has notably not spun out Facebook Marketplace or Facebook Watch, likely for this reason, and sunset Facebook Local after initially spinning it out. Many app developers tried to launch multiple apps as part of a trend called app constellations, and pretty much all of them failed because user acquisition is really difficult, or they failed to create product value (read more about this here).
Approach #2: Progressively Disclose (Temporary Simplicity)
One of the key strategies we took at Pinterest to solve the first mile problem was to remove functionality from the initial experience to make sure new users could learn the core concepts. Advanced features like group boards and messaging were not available to new users until we saw that they understood how to save content and access their boards. Once we confirmed the user activated, we started to give them access to the entire product, confident they could handle the increased complexity. This is a form of progressive disclosure to prevent new users from being overwhelmed, but only delays the complexity problem to beyond the activation period. To be clear, this was a very successful strategy for Pinterest, and a dominant approach to new user activation, which is why so many growth teams have dedicated activation or onboarding teams that leverage techniques like this. But it only delays the inevitable complex product in the hope that users are better prepared for it. This is a particularly ineffective strategy when there are more permanent differences between the complexity needs of different users, more common in business use cases like ours at Eventbrite.
The inspiration we were able to take from this approach is progressive disclosure work typically calls into question whether certain features should exist at all. Eventbrite had accrued many features of questionable value because a creator here or there used them. We started aggressively deleting such features in 2020, which helped make the product and code base less complex. We had much success with deleting features entirely at Pinterest as well, and I have written about both feature deletion and successful onboarding in the past. The next phase of leveraging this concept for Eventbrite is radically simplifying our onboarding flow to help creators understand what value we offer before they have to switch their entire business over to it. This is a big investment that will take multiple quarters to get to a great spot, but it is worth it. Still, it doesn’t fully solve Eventbrite’s complexity problem.
Approach #3: Train the User (Hacked Complexity)
Every designer strives for an ultimately intuitive user experience. And I’m sure we’ve all seen that quote that say if a design needs an explanation, it’s a bad design. I often think, has anyone who’s said that quote tried to design software before? This stuff is hard! My preferred saying is a design with education is better than a design that doesn’t educate. Having this aspirational north star of intuitiveness is important for any design team, but it’s okay to admit you’ve fallen short of that lofty goal and leverage other tools to set up users to be successful. Using people and or prompts in the experience to ensure users are successful is not shameful; it’s smart. Eventbrite is in the early stages of leveraging proactive communication and still learning, but we have found that contextual prompts or offering to get on the phone with creators that have demonstrated they intend to use the product at scale can be pretty impactful. People-based strategies do not scale, but they can at least be profitable if they are gated on the value of a customer.
Approach #4: Segment User Experiences (Optional Complexity)
In business use cases, it is less likely that the average user matters, and instead, there are different levels of complexity required for different users. This can be admins vs. normal users or small vs. large accounts to give a couple examples. The more standard approach today to dealing with the very differing needs by user type is to proactively set up user types as part of a complex team-based onboarding, as is common with enterprise products. For products that achieve bottoms-up adoption, this is more likely to be achieved by different packages that segment different types of users. For example, a base package may only have a few features and a low price, and a professional package may have more complex features that would only confuse base users, but are valued by professional users so much that they are willing to pay more than the base package for them. This can be pretty successful when segments are easily identifiable, but when segment needs diverge from clear product delineations, it can create issues. Also, managing separate user experiences by user segment can be hard for engineering and design teams to scale.
Eventbrite launched a more realized package framework in 2017, and found that it failed to map to the different types of creators as elegantly as they initially thought. It turns out features cannot be mapped that easily to different segments just by scale, and that package changes had implications on the entire Eventbrite growth model, not just monetization, since so many creators start initially as ticket buyers in the ecosystem. Segmentation is something that is mapping more neatly to Eventbrite’s marketing tools, which are frequently purchased in a subscription. They work less well for Eventbrite’s ticketing business that deals in transactional costs where features help drive extra sales.
Approach #5: Make Advanced Features Discoverable (Perceived Simplicity)
Segmenting user experiences addresses differing levels of complexity needs when there are easy to identify segments, but what if the same user needs the simple product most of the time, but more powerful features only occasionally? The package based approach will present the user the complicated product every time even though the base product would be a better experience for them most of the time.
A solution many self-service products attempt is to preserve the simplicity of the core product, but make that additional complexity immediately available on the rare occasion it’s needed. WhatsApp is a great example of this in consumer products. The main interface of WhatsApp is optimized around text-based messaging. It is simple to view chats and reply, and to most users, they need no education to figure out how to do this for the first time. However, WhatsApp actually has a lot more powerful features than this. You can record messages, call people directly via audio or video, leverage emojis, attach images, and take pictures. When you need one of these advanced features, I bet it takes most users less than a second to find them in the interface, but these features don’t crowd the interface for the baseline use case of text messages.
It is very difficult to preserve this level of complexity while preserving a simple interface, and WhatsApp may be the best I’ve seen at it. But it’s important that designers strive for this level of intuitiveness in the face of product evolution, and not retreat to lazier methods that denigrate both the user experience and business performance. Square at one point redesigned their interface to make it a lot simpler, hiding most advanced features behind various settings. The new interface was simple, but users could no longer find a lot of the features they wanted to use, and business metrics suffered. That is not what success looks like. Britelings are probably tired of me using the WhatsApp example, but it is our north star for how we tried to build creator products. Simple for the 99%, surprising and intuitive power for the 1% use cases.
The higher the ARPU, the more you can use direct contact to train users. The lower the ARPU, the more scalable your solution to complexity needs to be.
–
There is no easy way out of the product lifecycle. Like scaling a culture, it requires a lot of intentionality to scale a product without losing the simplicity that drove so many people to it in the first place. At Eventbrite, we continually strive to make our user experience powerful, yet simple, and we frequently fail to achieve our own expectations. Hopefully, the approaches above help give you some options to manage complexity in the user experiences you own to improve the value for your customers.
Currently listening to my Uptempo Instrumental Hip-Hop playlist.
Lenny Rachitsky recently launched Lenny’s Podcast, and I was happy to be a guest. We talk about how to communicate upward, different product design strategies for complex products, what it means to be a product leader, and much more. I’ll expand on some of these in upcoming posts. You can listen to the podcast here or on Spotify below.
Currently listening to my Downtempo House playlist.
A common issue leaders in product management, design, or engineering face is justifying investment in the “non-sexy” stuff. What is not sexy can differ by company, but usually the sexy things are new products and few features. Non-sexy things include general user experience improvements, performance, developer velocity, infrastructure, technical debt, and, fortunately less than it used to be, growth. I’ll walk through some frameworks and examples from my career on how to drive excitement and investment in these critical areas that may not be properly valued or staffed currently in your organization. But I urge everyone I can in product to develop the intuition to support these initiatives without making teams jump through hoops to justify these investments.
User Experience
The most common path product teams are on today is that they go from feature to feature trying to add new functionality, never confirming their feature actually adds value, and never improving features over time or updating experiences to be more modern as the world evolves. Designers complain about how stale certain experiences get over time, but improvements never make the roadmap. Product managers think designers are whining about things that aren’t important versus their current OKRs.
Why are the designers right in this instance? Well, they aren’t always. It is possible to over-design and do things that feel good and look excellent, but don’t materially help your customers or the business. Polishing too often can be just as bad polishing too little as you don’t deliver enough new value for customers. While over-polish does happen, why designers are mostly right is they intuit something about product/market fit that is hard to measure on a metrics dashboard: that expectations of customers increase over time. Another way to say that is product/market fit has a positive slope. If you do not consistently improve your product or feature, and customer expectations continue to increase, your product or feature can fall out of product/market fit over time. Many business strategists talk about companies being in a Red Queen effect with their competitors. This means they have to run really hard to stay in the same place competitively over time. But what many product teams misunderstand is that they are in a Red Queen effect with their customers to maintain product/market fit as well. Consistently improving the user experience helps products stay above that positive sloping curve of product/market fit. Let’s visualize this by borrowing a graphic from my product/market fit essay.
In the above graphic, the customer expectations line is the point at which customers stop complaining about elements of a product. That is not the target for product/market fit. The target for product/market fit is the purple line where customers stop leaving a product. Teams invest in products and features to get them above the purple line, but failing to continue to invest in them beyond that point means expectations for product/market fit will eventually exceed what has been built without continued investment.
The dotted line is a worst case scenario as it happens in a way that is not measurable, but once those hard to define lines cross, every metric gets worse. So, in prioritizing user experience improvements that scale with customer expectations, the net effect you see is no impact in business metrics. But the effect of not doing these investments means business metrics will decrease over time. This practically means that teams that make investments feel like the investment didn’t “pay off”, but in reality it prevents the possibility of dramatic issues for the product down the line.
On the growth team at Pinterest, Kaisha Hom and Lindsay Norman on the growth design team intuited this, but had trouble convincing a very metric-oriented team on the value of this investment. Eventually, we decided that one of our key results would be a quarterly audit (and refresh if needed) of our top five user flows. The expectation was no material impact on growth, but instead prevented potential growth issues down the road.
At Eventbrite, we have gotten a little more sophisticated in how we manage this. Adele Maynes, who leads our research team, helped craft a survey that measured different components of our product/market fit, including:
We also created this survey for some of our key features inside the product so we can understand their feature/product fit better. Our new strategy is to be a fantastic self-service experience that rivals the best SMB tools on the market, but we know we have a long way to go to get there. Investing in user experience is a key driver of this strategy, and these scores help us know if our overall product and specific features are on the right track. CRPX is now one of the top level key results for the product team.
Sample analysis of Eventbrite’s Creator Product Experience Score (CRPX)
Performance
Performance, roughly meaning how long it takes for software products to become usable to customers who load them, tends to become a problem at scale without concrete investment. Products become bloated, the number of different types of users and use cases multiply across countries and categories, and the number of frameworks engineers are leveraging to deliver experiences rises exponentially. We actually have pretty good data externally on the impact of performance. There are many studies that show additional milliseconds of load time impact things like conversion to purchase and engagement on many websites and apps.
A big problem is actually addressing performance issues at the start tends to be measuring it well, across different pages, apps, countries, use cases, etc. Obviously, this is normally the place to start. But sometimes even shockingly high metrics in certain countries or at the edges can’t motivate teams to scrap their current OKRs for performance work.
On the growth team at Pinterest, we were struggling with some performance issues of our home grown frontend framework. After trying to rally the company around this work and failing, we decided to leverage our skills to prove out the value of this work. A small team of engineers led by Sam Meder decided to work part-time on a performance initiative just for our logged out experiences, migrating to React, server side rendering, lazy loading, spriting – all the usual suspects from a frontend performance perspective. They ran these changes as AB tests to show the impact on user engagement and key business metrics. The result was a 30% decrease in user-perceived wait time, which resulted in double digit= increases in traffic from Google and conversion rate to signup. The impact was enough to get our CEO to push this as an organization-wide initiative the following quarter.
Developer Velocity
Shortly after I joined Eventbrite, I ran into Omar Seyal on the street. Omar was the Head of Core Product at Pinterest at the time. As I said hello and asked him how things were going, Omar, always to the point, remarked, “Pinterest doesn’t understand leverage!”. He then went on to say how he was struggling to get Pinterest to invest in its infrastructure so that engineers could move faster. In my head, I thought, he doesn’t know how good he has it compared to Eventbrite. Startups, or companies that emerge from startups, tend to prioritize new customer value and growth at all costs. This not only can create a lot of technical and design debt that will slow companies down for years to come, but it also prevents them from seeing “what got you here won’t get you there.” At a certain point in a startup’s lifecycle, it has to shift from growth at all costs to balancing growth and long-term scalability. Yes, you could spend 90% of your time building new things when you were small, but that won’t work when you’re big and have dozens of things to maintain.
A belief Omar and I share is that developer velocity is the purest form of leverage in a software company. So, it follows, investments in things that make developers more productive are the highest leverage investments a company can make. Sure, those investments don’t translate into customer value directly, but they enable each developer to build more customer value. That can mean more features, more experiments for a growth team, whatever the company needs to maximize long term growth. The key question I think non-developers fear is that these are just quality of life investments and don’t actually meaningfully improve the amount of value to customers. After all, you’re spending less resources on value to customers in the short-term whenever you look inward at internal tools.
What we did at Eventbrite to confront this narrative is we built a measurement plan and a goal. First, we measured the amount of downtime our developers experience on a quarterly basis for various issues. We then stated that with investment we could decrease that downtime, freeing up more capacity to build value for customers. We then set a goal. By making these investments, James Reichardt and Dan Peterson, our leaders in platform engineering and product, argued we could free up the equivalent of 15 new engineers’ worth of capacity at the company. In the end, those investments freed up 18 engineers’ worth of capacity. We confirmed this with “end of sprint” reporting on different teams on the amount of what they were able to deliver. If those numbers aren’t improving over time, you’re probably under-investing in projects related to developer velocity.
Engineering downtime was actually trending upward, but by working on our tooling we were able to save hours per engineer per week.
Growth
As much as I’ve written about the rise of growth teams and how growth teams work, the concept of investing in things that help connect customers to value instead of building new value is still pretty nascent in the software world. I speak to product managers and leaders all the time that are struggling to get investment in areas that could help inflect their growth. We definitely faced some of these same issues when I started at Pinterest. While we had a dedicated growth team, many parts of our growth model felt under-optimized, but also hard to measure or justify investment for.
One of these areas was search engine optimization. A few months before I got to Pinterest, Pinterest had “no indexed” the entire site, leading Google to email us to confirm that was what we wanted (it wasn’t). Anna Majkowska jumped onto the problem, but was only able to secure a few part-time engineers to help her. I joined shortly after as the PM, and we worked together on a plan to improve SEO for Pinterest as we believed that to be a large growth opportunity. The problem was we were on a growth team that ran every change as an AB test to show the improvement in growth. With SEO, you can’t run AB tests because it’s one Googlebot instead of millions of separate users. Julie Trier, a part-time engineer on the team at the time, said we had to develop an SEO experiment framework like we use for other parts of the growth team, and set out to build it. With this initial version, instead of showing different users different experiences, we changed parts of the experiences on some pages and not on others and measured the traffic change from SEO. The framework worked, and helped us justify SEO investments by showing how much extra traffic we received from making changes.
More traffic was great, but the issue was that users from Google would just look at all our cool content and leave. Conversion rates were very low. Conversion was managed by another team. So I went to them and explained the opportunity. They said they were busy working on a home page overhaul and couldn’t look at it. So I said we’ll take on the work ourselves. By then Jean Yang had joined the SEO team and ran an experiment that increased traffic, but decreased sign ups. How that was possible was by making a new page available to Google, we removed a signup modal blocking logged out users from accessing it. It turns out people signed up when they saw that modal, so we hypothesized maybe we could trigger that modal when you clicked on an image when you didn’t have an account. Also, we thought the other thing that indicates you like what you’re seeing and should sign up besides a click on an image is scrolling down and viewing more images. We already restricted Google from seeing more than 25 images on a page, so we decided to make the same change with users, with a modal coming up from the bottom saying to sign up to see more.
It took Jean two days to implement the experiment, and the result was a 50% increase in conversion rate to sign up. Every graph at the company kinked up as a result. I got a message from Tim Kendall, our Head of Product, asking “What did you do??”. I thought he might fire me, but instead he used the data to go raise more money at a higher valuation showing investors we could inflect our growth. Don’t under-estimate the power of proving it by going rogue or making the measurement investment others think isn’t worth it. It can turn subjective conversations into objective ones very quickly. The team grew dramatically after this with Julie eventually leading a platform team for growth tools.
–
These are just a few examples of how teams were able to make the investment case and prove the value of “non-sexy” projects to make a big impact. Of course, what tactics work for you will depend a lot on your company’s culture, but one thing that will likely mimic these stories is teams working together to make both the case and execute on the investment. Building products is a team sport, and the more cross-functional the support you achieve, the more likely you are to succeed.
As I relay these types of stories, it’s easy for people to say something to the effect of “sure, that worked at Pinterest or Eventbrite, but it could never work here” without realizing the point of the story is that almost all companies have these types of issues. The question is whether you are willing to put in the work to try to change the narrative to help your company grow. Those that do typically are rewarded and reward their customers in the process.
Currently listening to my Trip-hop playlist on Spotify.
Hey everyone,
It’s that time of year again – applications for Reforge’s Spring 2022 Cohort are now open. Over the past four years, I’ve worked closely with the Reforge team to create three of the 16 programs it currently offers including:
Created with Fareed Mosavat (Chief Development Officer at Reforge, formerly Slack, Instacart)
Build, communicate, and execute a cohesive product strategy across feature, growth, scaling and innovation product work.
Created with Kevin Kwok (Formerly Greylock Partners) and Fareed Mosavat (Chief Development Officer at Reforge, formerly Slack, Instacart)
A step-by-step system to create, analyze, and communicate a growth strategy of compounding growth loops.
Created with Shaun Clowes (SVP Product Mulesoft, formerly Metromile, Atlassian)
A deep dive on how to understand, measure, and improve retention through activation, engagement, and resurrection.
If you’re unfamiliar with Reforge, it’s the world’s leading career development platform for top-tier tech talent. Membership combines cohort-based programs, with a year-round experience to help you learn, execute, and scale your career and your company.
The Spring 2022 Cohort begins the week of March 21. I’ve included details about all the programs below. If you have any questions, please send them to hello@reforge.com.
Each program is built and led by experienced executives from the world’s fastest-growing companies.
Reforge membership combines cohort-based programs with a year-round experience to help you learn, grow and drive meaningful impact in your career.
Live Cohort-Based Programs to Level Up Quickly
Real problems require real depth. Membership includes participation in 3 cohort-based programs per year where you will learn how to solve a key business challenge. Programs are 4-6 weeks in length, part-time, and held in a virtual format, guided by an executive.
Each week in a program, you can expect:
Year-Round Access to Tech’s Best Content & Curated Community
Your personal growth doesn’t stop with the program, it just begins. As a Reforge member you can:
Product Management Foundations
By Jiaona Zhang (VP of Product at Webflow, formerly WeWork, Airbnb, and Dropbox) & Anand Subramani (VP of Product at Path, formerly Pilot, Gusto, and Stanford Professor for Product Management)
Build a foundational understanding of the product manager role, and learn the tools and strategies needed to succeed as a product manager.
By Sachin Rekhi (Founder and CEO of Notejoy)
Level up your product management abilities by mastering critical product management tools. Learn to identify and execute on high leverage work that generates disproportionate product returns.
By Fareed Mosavat (Chief Development Officer at Reforge, formerly Slack, Instacart) & Casey Winters (CPO at Eventbrite, formerly Pinterest, Grubhub)
Build, communicate, and execute a cohesive product strategy across feature, growth, scaling and innovation product work.
By: Ravi Mehta (ex-CPO at Tinder, FB, TripAdvisor)
The methods of building high-performance product teams, managing up/down/across, and creating cross-functional influence.
(New!) Data for Product Managers
By Shaun Clowes (SVP Product at Mulesoft, formerly Metromile, Atlassian) and Crystal Widjaja (CPO at Kumu, formerly Gojek)
Unlock your full potential as a Product Manager by learning to drive impact for the metrics that matter most for your product.
User Insights For Product Decisions
By Behzod Sijani (Founder at Yet Another Studio, former Research Leader at Slack, Meta)
Learn to make key product decisions based on a deeper understanding of customers.
(NEW!) Engineering Management
By Nick Caldwell (GM for Core Technologies at Twitter, formerly Looker, Reddit, and Microsoft) and Heidi Williams (Head of Engineering for B2B & Platform at Grammarly, Founder of WEST Diversity and Inclusion)
From managing your team and stakeholders to engineering work, learn the skills of successful engineering leaders who deliver reliable output.
By Harsh Sinha (CTO of Wise, formerly PayPal, eBay) and Bryan Dove (CEO at Commercehub, formerly Skyscanner, Amazon, Skype, and Microsoft)
Learn how to go beyond executing strategy and gain the tools to shape strategy, educate peers on what is possible, and guide the product roadmap to deliver significant business impact.
By Andy Johns (Advisor and Investor at Unusual Ventures) and Matt Greenberg (CTO at Reforge, former VP Engineering at Credit Karma)
A methodology for product and engineering leaders to ship innovative products at scale.
(NEW!) Growth Marketing
By Mark Fiske (Operating Partner, Digital & Marketing Strategies at H.I.G. Partners, former VP Marketing at Credit Karma) and Brittany Bingham (VP Marketing at Guru, formerly SurveyMonkey)
Create and evolve a growth marketing strategy across a diverse portfolio of channels, strategies, and tactics to drive meaningful outcomes in your growth model.
(UPDATED!) Marketing Strategy
By John Russ (Former Global Head of Marketing at Coinbase, formerly Zapier, Nerdwallet) and Martina Tam (COO at brightwheel, formerly Masterclass, Eventbrite)
Build and execute an integrated marketing strategy across the marketing domains of brand, product, and growth to drive compounding results for your organization.
By Brian Balfour (Founder and CEO of Reforge, former VP Growth at Hubspot) and Andrew Chen (GP at A16Z, former Growth at Uber)
The most comprehensive overview on the systems and frameworks that form the foundation of a successful career in growth.
By Casey Winters (CPO at Eventbrite, formerly Pinterest, Grubhub) and Kevin Kwok (Formerly Greylock Partners)
A step-by-step system to create, analyze, and communicate a growth strategy of compounding growth loops.
By Shaun Clowes (SVP Product Mulesoft, formerly Metromile, Atlassian) and Casey Winters (CPO at Eventbrite, formerly Pinterest, Grubhub)
A deep dive on how to understand, measure and improve retention through activation, engagement, and resurrection.
By Elena Varna (Growth Advisor at HP, Netlify, MongoDB, formerly Miro, SurveyMonkey) and Dan Hockenmaier (Head of Strategy and Analytics at Faire)
A deep dive into the strategies top tech companies use to improve monetization and pricing.
By Elena Varna (Growth Advisor at HP, Netlify, MongoDB, formerly Miro, SurveyMonkey)
A deep dive into creating and executing a strategic experimentation system for breakthrough ideas.
I have written about the Chief Product Officer role in the past, and why the job is so hard. I also wrote about being a product leader during a crisis. But not much is written about starting as a new product leader. So, I thought I’d write a post about my first year as CPO, and share some general lessons. First, a reminder of the situation I started in. I had been an advisor for Eventbrite for about two years, so I had a lot of comfort with the CEO and many of the executives before ever starting the role. I believe this is an underrated way to start new roles for senior people because you can de-risk the culture fit and alignment issues that plague many new executives. When I started advising Eventbrite, the company had a business unit structure, so it didn’t even have a CPO role, but product leaders embedded into different business units. The company reorganized functionally, and created this role and asked me to consider it.
What Type of Job is This?
I believe the most important question a product leader needs to ask when they get started is what type of job it is they have to do. I wrote in the past that there is frequently a misalignment on vision vs. execution roles. There may also be a misconception of what type of product work is needed to help the company i.e what the product strategy should actually be. In the Reforge Product Strategy course, we teach that there are four different types of product work:
Old school product leaders would just do their preferred type of product work even if it wasn’t what the company needed, or adopt a primitive portfolio approach to the four types of work even if part of the portfolio was wasted work e.g. building a ton of features for a network effects business, or doing a lot of growth work for a pre-product/market fit product. As a modern product leader, it’s important to understand based on the company and its lifecycle, what type of product work has leverage, and these crude approaches are usually not the best approach.
Usually, the best place to start is looking at what the company is actually working on right now. In Eventbrite’s case, the company was:
Julia, our CEO, had told me she wanted me to focus on growing the self-service business faster. So, first off, what you should notice is that there are too many things going on for a company of Eventbrite’s size (sub one thousand people). In other words, the product strategy lacked focus. So, I had to spend my first few months understanding these different strategies to understand which ones to focus on. So I gathered as much information as I could about these different strategic initiatives, as well as digging into the core self-service business.
What Was Going On With the Core Business?
The core self-service business was growing steadily at significant scale and was profitable. Most of the sales clients we brought in stressed our product/market fit, which we compensated for with manual services at no charge, straining margins. We didn’t have a good sense of who our self-serve customers were, how we acquired them, or what retention looked like. As we dug into these questions, we found that while Eventbrite’s product/market fit was strongest with making it really easy to host a single event, but the bulk of our growth and profit was coming from frequent creators hosting small events very often. So, while the product roadmap was scaling for size of event, the market was scaling with frequency of event. The product did not handle this frequency very well, causing these event creators to hack the product to get what they needed, and a higher churn rate over time as those hacks proved problematic to execute. The gaps in our product to strengthen product/market fit for these creators didn’t seem insurmountable, but none of them were actually on the roadmap.
We also were able to get a clear picture of the core competencies and competitive advantages of the Eventbrite product. The fact that Eventbrite supported events of all types and wasn’t focused on one vertical e.g. conferences meant the company had a scale of data no other company had. Secondly, the self-service acquisition model meant the product had very low acquisition costs overall. That model was also a good fit for many different types of creators. Lastly, the company had leveraged its scale of events to drive consumer demand through channels like SEO, emails to previous ticket buyers, and distribution partnerships with companies like Facebook and Spotify.
What Did the Team Say?
As I talked with the team about the state of the product and what they were actually working on, let’s just say the team had a lot to say. Breaking it down by project:
Upmarket Music Vertical Expansion
We tried to integrate music customers too quickly into the Eventbrite platform, and we were much further away from product/market fit with the more traditional enterprise approach those customers were used to than we thought. The space is low growth and low margin, and relies on enterprise sales, relationships, and high touch human service, which doesn’t match our self-service capabilities well.
Consumer Marketplace
Frequent creators drive most of the inventory consumers are interested in, and if frequent creators’ efficiency tools on Eventbrite don’t work for them, they will leave the platform even if they sell extra tickets because of the platform. This is an interesting strategy, but needs to be sequenced after we have a great product experience for frequent creators.
Technical Scaling
Internal developer productivity was incredibly low due to low level of investment in developer tools. Our infrastructure was rickety and frequently had stability problems during big “on sales”. Multiple versions of every feature made it hard to build new things quickly and at high quality. We never deleted features because some sales clients use them and would complain. Everything we build is an MVP, and we rarely iterate.
Developer Platform
While the strategy of leveraging external developers to build specific features for a large array of customers with different needs makes sense at Eventbrite’s scale, we internally lacked the capability to service our own engineers well, much less external developers.
New SaaS Products
Many of these products are very far away from product/market fit and do not have a path to scalability. There is one partnership related to creator marketing tools being run out of this program which is doing well though, and it has been easier to talk with creators about that than our marketplace demand.
Developing A New Product Strategy
Strategy is about making choices among many options that optimize across a few key dimensions like:
Eventbrite failed to make a lot of hard choices with its product strategy when I arrived, so it was time to make some tough calls on what to focus on. There are no simple answers here, but in evaluating the initial strategy, it became clear we should do the following:
The new product strategy is remarkably simpler and more sequenced over time:
|
2021 |
2022 |
2023 |
|
Frequent Creators |
Marketing Tools |
Consumer Marketplace |
| Technical Scaling | Technical Scaling |
Technical Scaling |
Frequent creator investment will be measured by improved frequent creator retention. Technical scaling will be measured by internal developer velocity and our say/do ratio. Marketing tools and consumer marketplace will both be measured by revenue from those sources. So, going back to what type of job this is, my initial directive would have made this product leadership role to be primarily about growth. Instead, the focus is on scaling with some product/market fit expansion.
Your Product Strategy Probably Isn’t That innovative
One dirty secret behind the work of many executives and product leaders is that our strategies aren’t that innovative. There are a few playbooks we generally run to improve performance in companies depending on the business situation after we’ve gathered the right insight. You can run through them and rule most of them out like the con men strategies in Ocean’s 12:
Yes, product leaders also rule out strategies because we don’t have enough people or can’t train a cat that quickly.
The new Eventbrite strategy was a combo of two common strategic playbooks. The first part of the strategy is what Chris Zook calls “profiting from the core”:
“The greatest strategic error stems from an inaccurate understanding of the core and its full potential.”
-Chris Zook, Author of Profit from the Core
However, if you’re an Arrested Development fan, you might call it the “there’s always money in the banana stand” strategy. The idea behind this strategy is that many companies as they scale pursue too many expansion strategies and leave behind growth that is closer to their initial core business, plays more to their core competencies, and requires less work and less risk to execute. Eventbrite was pursuing expansions in verticals (music), business model expansion (SaaS), and value props (driving demand) while ignoring improvements that could help the growth of the core product (features for small, frequent creators). At Pinterest, VP Product Jack Chou ran a version of this he called “make the basics great”.
The other component of the strategy is probably most known from a blog post (and soon to be book) by current Snowflake and former ServiceNow CEO Frank Slootman. In Amp It Up, Frank Slootman basically divides up his strategy into three elements:
Personally, I would flip the order and revise the language to be more software specific:
By the way, if you’re a public market private equity investor, and you aren’t running this strategy on every sub-rule of 40 tech company, I have a question for you.
So, in Ocean’s 12 language, Eventbrite is running a banana stand combined with a Slootman Special. We… may need to work on these code names. Recently, Etsy has run this same strategy combo to grow its market cap from $2 billion to $25 billion in four years after many years of no market cap growth at all.
There is one other element to Eventbrite’s strategy, and that is presented by the table above: sequencing vs. parallelizing. There is a reason Eventbrite started to pursue a lot of these adjacent opportunities in the first place: fear the core business could not grow itself fast enough. But in trying to pursue multiple adjacencies at the same time, it not only failed to make the progress it wanted on any of them, but many were not set up for success because they would gain from other strategic elements of the plan already having been completed.
The goal of this post is not to geek out on all the generic strategies, though I could do that all day, but to give a sense of the work new product leaders need to do to understand strategy and make it explicit to the organization. Frequently, there is a mismatch between what the customer or business needs and what the team is working on today. Usually, by talking to the team, your customers, and looking at the data, you can identify the mismatch and position the team toward a more likely to be successful product strategy. Then, product leaders can move to the meat of the role, which is building and optimizing the structure and processes of the team to execute against that strategy more effectively over time, or adjusting to changing market dynamics *cough* pandemic *cough*.
Currently listening to the Housewerk EPs by Tusken Raiders.
Harry Stebbings of 20VC fame is launching a new podcast series focused on growth. I was happy to be his first guest. We talk about growth inside startups, how to hire for growth, and many other topics. You can listen to the podcast here or on Spotify below.
Currently listening to Mana Pool by VAPERROR.
I’m excited to announce that public applications are open for the Fall 2021 cohort of Reforge. I’ll be participating alongside leaders from Tinder, Facebook, HubSpot, SurveyMonkey, Instagram, and more.
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.
I’ve worked closely with Brian Balfour (CEO at Reforge) and the Reforge team for the past 3 years to develop and host four different programs. Onboarding for the Fall 21 cohort begins Oct 4th and programs run between 4 to 6 weeks long.
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), Ravi Mehta (Ex CPO at Tinder, Facebook, Tripadvisor)
A step-by-step system to create, analyze, and communicate a growth strategy of compounding growth loops.
With Casey Winters (CPO at Eventbrite, Ex Pinterest, Grubhub), Kevin Kwok (Ex Greylock Partners), and Fareed Mosavat (GP at Reforge, Ex Slack, Instacart, Zynga)
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)
Gain critical growth tools to help your company traverse the next leg of its growth journey.
With Brian Balfour (CEO @ Reforge, Ex VP Growth @ HubSpot), Elena Verna (Growth Advisor to Miro, Netlify, MongoDB and Ex SVP at SurveyMonkey), Fareed Mosavat (GP at Reforge, Ex Slack, Instacart, Zynga), Ravi Mehta (Ex CPO at Tinder, Facebook, Tripadvisor)
In the Fall cohort there will be 14 total programs across Product, Growth, Engineering, Founders, and Marketing all built and led by experienced executives. Here is the full slate:
Reforge is the first-ever career development membership focused on high-growth tech practitioners, and is built entirely around the idea of driving impact for your business and for your career. The Reforge membership combines cohort-based programs, with a year-round experience to help you learn, grow and drive meaningful impact in your career.
Real problems require real depth. Membership includes participation in two cohort-based programs per year where you will go deep on how to solve a key problem in a 4-6 week, part-time, virtual format, guided by an executive.
Each week in a program, you can expect:
Your personal growth doesn’t stop with the program, it just begins. As a Reforge member you can:
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.
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:
To join the Fall cohort, you must apply before September 10th. 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!
