This is an overview of the review process I put in place at Eventbrite. A lot of companies have Product Reviews (a single type). At Eventbrite, I decided to institute three different types of reviews for different inflection points of a project. This overview gave the team a simple view of the differences between them and links to resources like templates + examples.

I didn't go into Eventbrite thinking I was going to institute this. But when I first got there, I noticed a few things: 

We were shipping a lot of low-quality things. 

I realized the product org needed a lot of coaching at each phase of development and help to set and hold a quality bar for product thinking and the solutions we shipped. PMs were treating every type of product problem the same and approaching it with the same methods. This realization actually led to 

. These reviews acted as coaching sessions to uplevel the team and set expectations. Over time as a PM became more senior, they became opt-in to get feedback. While I attended every one for over a year, over time I handed this over to the VPs as the consistency was established.

The first concept reviews we ran were pretty rough. The thinking about what to work on was pretty bad, and so I ended up killing a lot of initial concepts. The team wasn't used to hearing that feedback. But the team improved over time.

Coding time is expensive. So the primary goal of this was to make sure we were careful that the time we spent coding would be high ROI.

I think one of the keys is that the Product Leaders should treat these as coaching sessions. Not only for the individual presenting but also allow other PMs to join to observe and learn from others' work.

One of my biggest rules for these reviews, but especially Product Reviews, is that people don't leave things unsaid. If you don't think something is high quality enough, you need to get it out before it ships. So if the design team doesn't think the user experience meets the quality bar, they can say it's not ready to ship, and we can discuss it. But you can't bring this up after the fact.

About 80% of the time, initiatives passed the product review and shipped to a percentage of users. But about 20% of the time something didn't hit the quality bar, and the team needed to go back and iterate. It's important to hold this bar.

We initially created the results review on the growth team at Pinterest. I instituted it at Eventbrite because early on there was a habit of shipping things and then just moving on. This created a lack of learnings, increased tech debt, and more. The results review is a forcing function for the team to learn from what we ship, but it also works to clean up the solution before rolling it out to 100% and moving on to the next thing.

The results review also helps manage tech debt. Companies who ship and just move on tend to leave a wake in their path. Part of the results review is to ask what tech/UX debt did we create we need to clean up based on the ship/iterate/kill decision. How do we make sure we do that cleanup before anything new?

Casey Winters

This visual outlines the details of how product reviews work at Eventbrite. I ran these sessions with my team during a standing 2-hour block every week.

This visual outlines the details of how product reviews work at Eventbrite. Casey ran these sessions with his team during a standing 2-hour block every week. The system consisted of three types: 

Product review process at Eventbrite

Product review process at Eventbrite

Sign up to see more