This was an exercise the entire executive team went through right before the pandemic hit. Eventbrite had recently gone public and brought in a lot of new execs, including me, for the next phase of Eventbrite's evolution.

Because there were so many new execs, we lacked knowledge of each other's functions and each leader's philosophy towards other functions.

We decided to do a deep dive into each functional strategy. The way it worked was:


We worked with an exec coach who gave us this template.

Each exec took some time to create their own.

We spent an hour every couple of weeks in the regular exec meeting going deep on one function.


The process as both a consumer of others and creator was very valuable as I discuss in other comments.

I'd now recommend doing this in a few situations:

Teams that have done a big reorg that changes how people interact with each other.

Whenever there are large new leadership changes.

A huge value of this exercise is helping the other execs how I see where we are today, where I want to go, and the timeframe of closing that gap.

This gave the other execs a roadmap for all the things I wanted to invest in to get the product team to level I wanted it.

These principles need to match the season that you are in. Shortly after writing this doc the pandemic hit and Eventbrite moved into war time mode. As a result, some of the principles needed to change to match war time.

The first was level of autonomy. In peace time, I prefer to give more autonomy to the team but in war time more of the decision making moved to exec.

Speed and quality was another thing that changed. We moved closer to just getting things shipped. Especially anything that had a chance of saving the business we didn't do estimates, we just built it.

This is one of the principles I find most important. 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!

Before I joined, the Eventbrite product team did not go talk to other companies about the problems we had to see if we those companies already solved it. So part of what I did was everytime we had a problem I didn't know how to go solve, I'd setup conversations with other companies like Fair, Instacart, or whoever we thought might have faced something similar.

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.

Of course, what gets measured gets improved. So we developed a metric to measure this. I talk about in detail here: 

https://caseyaccidental.com/non-sexy-projects

One of the most helpful things in this exercise was understanding how other Execs perceived the performance of their leadership team. That doesn't normally come up in conversation but is super helpful in understanding another function.

So this section helps others understand who you think your potential successor is, the strengths/weaknesses of each leader, and which leadership roles you need to fill.

Strengths/Weaknesses could be things like communicating a vision, working with certain functions (design, eng, sales, etc), technical acumen, product sense, growth work, scaling work, metrics, strategy, and more.

When I joined Eventbrite, I had a lot of upleveling to do amongst the product team. I knew had 3 to 5 years of work to do.

A false assumption I made was that a lot of other functions were the same. So early on in my exec interactions I didn't push a lot on the other functions like sales, marketing, finance because I wanted to be respectful to other new execs who I thought had a lot of things to improve like I did.

But in my 360 feedback that was perceived as me not caring enough about the business and being too focused on the product which definitely wasn't true! It was just me not wanting to poke the bear of other functions, because I knew they could poke the bear in 15 different areas of product.

I realized I wasn't doing a good job of explaining all of the things I wanted to do for product. So this document became a way for me to synthesize the North Sar for product as a function and helping my peers understand what I knew needed to be improved and where we're going.

Creating this helped me realize how much I think about operating a product team and the principles and processes that I've never explained to my peers. It was this realization there's all this stuff I'm doing. All these core beliefs I have that I've battle-tested but never tried to explain it to any of my peers!

How the hell are they supposed to understand anything I'm doing? So it was a rude awakening in terms of I can't believe I've never written this down and tried to explain this to my boss, the head of marketing, the head of sales, and others. No wonder they're confused as to why some things work the way they work.

Casey Winters

I used this strategy doc with the Executive Team at Eventbrite to build a shared understanding of each leader's roles, responsibilities, and philosophies. I recommend doing this for any new exec hire or whenever there are major org or leadership changes.

As CPO I am responsible for leading and facilitating the development of products and features that deliver value for Eventbrite’s customers that translate into value for the business. The roles I actively lead in driving this value are:

 Make sure the right product decisions are made with follow-through. Focus on why and when whereas engineering will focus on how to implement.

 Make sure the user experience and look and feel of the product help our customers be successful and is cohesive. Focus on what it looks/feels like and how it works from the customer's perspective.

 Make sure we understand who our customers are and why they do what they do.

 Make sure that development efforts are properly coordinated with cross-functional teams that deliver value directly with customers such as Sales, CX, and Marketing.

 Utilize techniques outside of the product (market research, partnerships, prototypes, manual work) to validate opportunities so they can be considered for future product development.

Make sure Eventbrite chooses the best possible product strategy based on the information we have and adjusts as we learn

Define and consistently improve the process through which we set strategy, prioritize projects, and execute on them so they deliver value to customers and tangible business results that the rest of the company understands and is able to participate in. This includes:

Identifying bottlenecks that prevent us from delivering value, quality, or those two at the detriment of speed and working with cross-functional leaders on removing those bottlenecks

Making sure the company outside of development is aware of and participating in the development as well as the delivery of projects

Train the team on what it means to be an effective product manager, product designer, user researcher, et al. at Eventbrite, and hire people who can augment our existing team in the first two roles

Some examples: Product Manager role, Product Problems, MVP/Design Quality, Problem Definition

I am accountable for what we build driving value for the business. There will be many times where what we build doesn’t end up driving value for the business. This is hard, but it’s my job to improve that conversion rate and magnitude of impact over time.

Lanny Baker, Eventbrite’s CFO has this concept of the different functions and the financial returns they should drive. Sales should act like bonds, giving you a predictable, positive return, but not an incredibly high one. Marketing should act like stocks, with more uncertainty as to what will work and not work, but overall generating a higher positive return. Product is more like venture capital, where most things we invest in do not work, but some have amazing returns that make up for the things that don’t work, and overall provide the biggest return. I would like product to retain the returns of venture with predictability that looks more like stocks and bonds. An extreme movement from activity (dates we miss and decks we update) to results (metrics we move and products we upgrade). How do we do that? It’s not something I can do alone, but it is possible. We need to do this in partnership foremost with engineering. But 

some outcomes I’d like to see in 2-3 years

We understand exactly how the business grows, what we can do to inflect that growth, and where we should be investing in new growth opportunities to create new ways for us to grow.

Product teams are accountable for key metrics for which we understand exactly how they drive value for the business. Product teams commit to driving increases in these metrics they can be confident in due to a deep understanding of the metrics of their area and the users they are building for

That accountability for outcomes creates less stress over dates as you can be confident product teams will make the right tradeoffs on what they build and when they deliver value to hit the metrics they are accountable for, and keep cross-functional teams informed so changes in dates do not stress sales or marketing related outcomes

Product builds a great system to measure what we ship, understand and improve the quality of what ship, and better understand how long it takes to ship quality products

We do not see product as just building features for customers, but building value for the business. This may include a lot more of a focus on internal tools that allow our teams inside and outside of development to scale.

A lot more of a participatory approach to product development, with product specialists from outside of development helping to contribute ideas to our roadmap, refine ideas so they are more likely to be successful. Engineers, analysts, designers are as likely to come up with ideas we work on as product managers.

I practice situational leadership with my directs, and am learning the clues as to when I miscalibrate either confidence or competence

 where we are trying to get to the top right. We will do that by improving quality first.

I am radically transparent, but optimistic in tone with my team

Focus on the problem, and assume it is solvable

The feedback loop of learning is the most important thing for my organization to build

I tend to “open source” what we solve, and 

use open source components wherever possible to solve our problems vs. feel the need to invent solutions ourselves

I care about collaboration, not ownership, and most things in product development require a cross-functional team to align and execute together to have an impact

Process should only be introduced to solve problems, and when introduced, I should be prepared for those I introduce it to to come up with a better process to solve the problem. (My team is pretty good at this)

More and more should be able to be solved without me. Otherwise, I am failing as a manager.

Improve the product experience for our most valuable creators, increasing their retention, satisfaction, and lifetime value. Success looks like a X% increase in Creator retention.

Increase platform reliability and product quality as well as improve product development and engineering efficiency. Success looks like an improvement to [redacted], and an improved developer enablement score, which measures how easy it to ship code as an engineer at Eventbrite

Improve product functionality and training for our most valuable creators. Measurement: Creator Usage Retention, Activation, NPS

Substantially increase platform reliability and product quality as well as radically improve product development and engineering efficiency. Measurement: Error Free Traffic, % Traffic off Core Monolith, Developer Enablement Score

Deliver a single demand solution that helps creators attract and retain audience throughout the event lifecycle. Measurement: Monthly Unique Visitors, Eventbrite Driven Paid Tickets, Eventbrite Driven Revenue


We always start with the business strategy and translate that into a product strategy

We then break that product strategy down into components, and we have used various terms for that: themes or initiatives, for example

Themes are broken down into pillars. At this level, we set OKRs and a roadmap of what we’ll deliver to achieve those key results

This roadmap is informed by what we built before

Aggregated cross-functional feedback from CX, Sales, and other function

Institutional knowledge of engineers, PM’s and designers in key areas

The roadmap will be high level at this point, and may just pinpoint the problem we’ll work on rather than distinct solution

Dependencies should be identified here and resolved before approval

The theme aggregates the roadmaps of the pillars for a theme level OKR

We do not do squad (read: xfn team of PM, engineers, EM, and perhaps design, data) based OKRs at this time, but the goal is to train teams to eventually do this

 where we approve work on a problem and a proposed solution from a squad

 a newer meeting we are refining where engineering figures out the right technical approach to build the solution agreed upon in concept review

 where we approve projects to be launched to customers

 where we evaluate projects we launched for impact and learning

 where we look at any risk to the roadmap, either through dependencies or execution issues

 one internal training per month, one external training per month, and the rest of the time is used for operational updates

 discuss what is constraining the product organization from being more effective

 where designers get critiqued from others designers to improve their designs

 our review of performance for each theme / pillar

 Squads have different rituals they have aligned on that help them be most effective. You may hear teams like Agile, Scrum, or KanbanSome of the most common are:

 This is a defined time frame (usually ranging from a week to a few weeks) where the team agrees what they are trying to get done and how they will achieve. This is when a team plans which engineers, designers are doing what, what is getting released, etc.

 At the end of a sprint, how did the team do and what did they learn to help them perform better next sprint or to adjust their roadmap

 a formalized process by which you go from vague problem to solution prototype within a week

Engineering: Very little in my function can be successfully executed with a healthy and functioning engineering organization. This is not only true with building the products, but also with measuring their success.

Recruiting: Not only does the Product organization need to grow its talent base in other countries, but we also need more engineers recruited to the team to be able to achieve our plans

Marketing: If we deliver valuable products and they are not marketed properly, we will not achieve the leverage we hope to by building these products.

Sales & Services: If we deliver valuable products and they are not sold properly, we will not achieve the leverage we hope to by building these products. If we are unable to build a good feedback loop from the Sales team into the product, our product roadmap will be weaker than it could be.

CX: If we are unable to maintain a good feedback loop from the CX team into the product, our product roadmap will be weaker than it could be.

Product Management functional strategy at Eventbrite

Product Management Functional Strategy

Area(s) of Responsibility

My Role in the Area(s) of Responsibility

Sign up to see more