This was a joint internal presentation between myself and our Director of Design, 

When I joined, there was organizational inertia towards shipping low quality stuff that didn't solve the problem and then moving on from it.

We wanted to build a better framework of when to build what type of solution that we could apply throughout the Concept, Product, and Results (Insert Link to This Artifact) review process that would lead us to better results for our customers and the business.

This is a common problem I see across product orgs. Product work tends to be treated all the same, but there are very different types of product work as explained in 

The framework from the presentation was systemized in our review process.

In concept reviews we'd ask how confident are you in the problem and solution? Based on that what solution does that dictate?

In product review, we'd confirm the solution was built to the standards of the type of solution that was agreed upon in the concept review.

In results review, we'd look at scale or quality issues if we had decided to do an MVP or MVF. We'd also look at where are confidence level on the problem/solution had changed and what type of solution that dictated as the next step.

This was a visual of the problem we were seeing done by Cody. Essentially, the team was being inconsistent of how we use and define an MVP.

Often times the term was being used to cut scope and time which is wrong. This is/was a problem within the industry, not just at Eventbrite in building products. Instead it's about ambiguity and quality which we explain on the next slides.

The framework that Cody Evol came up with was 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.

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.

This was a visualization that Cody put together to help visualize the difference between the different types of solutions.

The pyramid represents a fully complete product. In an experiment for example you don't care about reliability because not everyone is going to see it. In phased development, the reason it's not completely white is that you are still going to release the product in chunks.

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.

Once we got the team thinking about using the right product development solution for what we're trying to accomplish, how does time and sprints fit in?

Each of these types of solutions fits into the sprint process. So these next three slides show that for each.

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 created frameworks at Eventbrite not so that we can shut our brains off and follow an exact guide to building our product, but so that the team can focus our brain power on the thousands of other very confusing and ambiguous questions we needed to answer in order to build the product over time.

Casey Winters

To help Eventbrite build a better framework of when to build what type of solution, a colleague and I presented this deck to orient the team around processes and approaches that could lead to better results.


Guide to determine the first version of a new product or feature at Eventbrite

MVP/Design quality

Goal

Problem

Time and scope

Ambiguity

Sign up to see more