The Cake Model: A New Approach to Creating MVPs

Building products is hard. Building the right product is even harder. And building the right product quickly is an order of magnitude harder yet again.

Agile ways of working were developed to reduce the amount of time it takes for a product to reach the market. In doing so, Agile helped teams test product ideas and get quick feedback. The essence is speed and iteration. But sometimes the best laid plans of mice and men go awry – even in agile teams. 

As an Agile team building an Agile-related product, we’ve had our own experiences where things didn’t turn out as planned. And we learned how easy it is to lose sight of quickly iterating with the goal of getting feedback. 

Since we built our retrospective and estimation meeting tools, Parabol has been on a mission to support all types of agile meetings. When we launched Standups – our fourth custom meeting type –  we felt we’d finally done it. 

But there was a problem.

Between initial designs to first release a year had passed in the blink of an eye. 🤯

We reflected as a team on why this feature took us so long:

While we work in 2-week sprints, have regular retrospectives to identify process improvements, give team members autonomy to adapt along the way, and break down big ideas into MVPs and then enhancements, we fell into the trap of focusing on the big goal rather than the steps along the way.

We wanted to deliver a great standup experience, and focused on getting it right rather than getting it to users, receiving feedback, and iterating. 

Since we launched standups, we’ve made various changes in our planning, experimentation and product processes to work smaller. But in my view, one of the most critical was letting go of MVPs and embracing cupcakes. 

The Cake Model I introduce in this article has been invaluable for us in making sure we’re shipping MVPs that give us the maximum return on our work invested. I hope it resonates with you and you find it helpful in your product development work. 

The concept of the MVP (minimum viable product) is ubiquitous in tech: 

Coined by Eric Reis in the Lean Startup, the MVP approach can be truly transformative for a group building its very first product, without existing users or a known market. 

Instead of being huge, your product should be small – minimum. As small as you can make it, so you can get it out faster. 

Instead of being full-featured, your product should be basic – viable. Your goal is feedback, not completeness. 

Both of these tenets make starting on a path towards a big goal feel more doable. 

When you’re ready to ship your MVP, the intention is to launch to early adopters, folks who have opted-in to early, speculative, and often quite broken products. They’ll be forgiving. They’ll be invested in your product because you’re building it with them. Importantly, they’ve chosen to come along for the ride. 

Again, this solves the problem of having to get it right from the very start, and makes starting easier.

But when you’re an existing company, with existing users, looking to make something new, the MVP framework falls short in a few key ways: 

The core idea of making it smaller to get it in people’s hands is useful. But the MVP concept on its own doesn’t provide enough guidance. Product managers working with the weight of reputation, the expectations of existing users, and the scale of existing products, often end up defining MVPs that are still relatively large. 

We needed a different approach if we were going to ship new product experiences in a genuinely Agile way. Rather than just knowing we needed a closer finish line, we needed to be able to see the path from a starting line to that finish line. Enter, cupcakes.  

Before getting into the Cake Model, let’s talk for a minute about Henrik Kniberg and skateboards: 

Kniberg’s illustration is ubiquitous in product circles. It builds on the MVP framework but drives home a few important, often-overlooked parts. 

In the first row, Kniberg shows “bastardized agile” – a development process that does technically include iteration because at each stage, you’re building another part. But it still has a big reveal at the end, much like waterfall processes. Instead, the ideal agile process looks more like the lower row, where each stage includes a unique solution, put in front of an increasingly pleased customer. 

In the Skateboard Model, each stage of development is a complete, sellable product, rather than a component. Rather than making part of a car at each stage, you’re making a distinct solution in each iteration. Each iteration could be the final state, it’s complete by itself. 

The Skateboard Model also shows that, at each stage, the product needs to be shared with users for feedback and iteration. Rather than being unhappy until the final result, in this model, customers are increasingly happy with each version, telling you that you’re on the right path. 

In this Model, the MVP may well be the car, that could be the only iteration that truly, viably solves the problem. However, Kniberg argues this is a bad place to start because it’s expensive, especially if you can learn that a simpler solution is viable. For this reason, Kniberg calls the skateboard the “Earliest Testable Product,” and argues we should aim for the smallest variation that we can share for feedback. 

When we first conceived of the standups launch, we indeed had a skateboard > motorcycle > car plan. We would first build something we could show 10 users in research calls, then release to a core set of 100-1,000 users, then release to everyone. Based on what we heard, we would adapt. Iteration was built right in! So where did we go wrong? 

Well, there’s an obvious problem: making a skateboard teaches you little about making a car, especially when customers want a car. 

The latest and, in my view, most helpful evolution in this conversation comes from Brandon Schauer and Adaptive Path. It’s called the Cake Model: 

Source: Ola Micek

The Cake Model of Product Strategy is a framework for iterative product development. Building on Agile principles, the framework suggests breaking down a large product vision into distinct, delightful and complete products that each contain the core elements of the final vision, much like a cupcake contains the components of a much larger wedding cake. This approach to planning allows product owners to get faster feedback by making things smaller. 

The Cake Model uses the metaphor of someone wanting to start a wedding cake business. Instead of learning how to make sponge then frosting then cake (and only having a product at the end), the Cake Model suggests thinking of first making a cupcake, which contains all the components of a wedding cake, but is smaller, easier to make, and can be scaled up. 

Like MVPs and skateboards, the Cake Model supports starting small, shipping a complete offering at each iteration, and getting feedback to define the next stage. 

But the Cake Model makes meaningful improvements on its predecessors by giving us more structure to define each stage.

There’s a reason cupcake towers had a moment as a wedding cake alternative. Wedding cakes and cupcakes have the same components, just at different scales. 

When trying to figure out the first viable iteration of a big vision, product owners need to consider the components in their product (the cake, frosting and decorations) that are necessary to still call it a product. For example: A cupcake without frosting isn’t a cake, it’s a muffin, and you eat it for breakfast. If we’re going to call it a cake, it needs frosting. 

Once you’ve identified the components, we need to trace each back to its most basic version. A wedding cake has multiple layers of sponge, but we can simplify that to just be one layer, and then simplify again to be just a cup-sized layer. It’s still a sponge, but it’s simpler and faster to bake.   

A version of the Cake Model for standups might have looked like this: 

Unlike building a skateboard on the way to making a car, at each stage of the Cake Model, you’re building core product competencies. Alongside building the patterns in the product, you’re building your own skills and knowledge about these specific concerns. 

If you’re building in a brand-new-to-you space, you may not know enough to define the sponge, frosting, and decorations. But in our case: we knew our users and had already spoken with current and prospective users to understand alternative practices and pain points. If you don’t know enough to know the components of your cake, it may be time to ask. 

By considering the key components that need to be present, in some way, to meet users’ needs, we can make sure to test a variation of each of them in every iteration, and also build our skills in delivering that kind of component. 

If you want a car, chances are that a skateboard is a disappointing alternative, which Kniberg shows with the customer’s face in his illustration. 

The same might be true of getting a cupcake if you wanted a wedding cake, but as the cupcake tower trend shows, it depends on the customer. 

That’s another layer to the Cake Model. Rather than accepting that a customer will be less disappointed with each iteration, product owners consider which customer to target with each solution to define a product that fits. 

For standups, this might have looked like:

With the Skateboard Model, we expect that users will be disappointed with our first iteration. 

With the Cake Model, we can think both of how the product evolves but also how the user we’re serving evolves with each iteration. 

Where both the MVP framework and the Skateboard Model encourage making things smaller, the Cake Model has something the others don’t: cupcakes are delightful because of their size. 

The Cake Model centers the user’s joy as a goal of the product development process. 

Too often, in the quest to make things smaller, product managers will strip out things that add character, delight, or joy. The result is an MVP that may function, but doesn’t feel good to use. Imagine a motorcycle with no seat. 

Depending on what you want to learn, that could be fine, but if a product is too bare, the friction in using it might be such a high barrier for users that they give up. A product manager may look at that data and conclude the product wasn’t a good idea in the first place, when it was really the poor execution that turned users off. 

Product leaders have attempted to solve this flaw in the MVP concept by encouraging Minimum Loveable Product or Minimum Viable Loveable Product as the goal instead, acknowledging that by ignoring delight or joy, products aren’t really viable. 

With the Cake Model, delight is at the center. That means product managers need to consider what would make the product not just functional, but a joy to use. 

All three of these frameworks have a few things in common, but most importantly, learning is baked into the process. Each iteration is meant to be handed to users to see what they ask for, what they struggle with, and what they don’t like. 

With our standups launch, we introduced users to our MVP a year into our own exploration of standups. We still considered this an MVP, but we’d invested a lot of time into it. 

If we had employed the Cake Model earlier, we likely would’ve created a delightful cupcake as our First Testable Product. While we may still have taken a year to realize a Standups experience that felt sufficient, the shape of that product likely would’ve looked different as it would’ve been informed every step of the way by user feedback and interaction. 

Since launching Standups, we’ve adjusted our product development processes to focus less on MVPs and more on cupcakes. This shows in our latest release: Team Health. 

Team Health is a much smaller feature than Standups, and it only took us 4.5 sprints from commitment to launch. While we have a bigger vision for Team Health – allowing team-of-team leads to understand morale across a complex organization – we started small, with a cupcake. 

Depending on what we learn from users, the birthday cake phase could include custom prompts, templates, better reporting, custom responses, or more – it all depends on the feedback we get (which you can share here).

It may still take us another year or more to get to our complete vision for this feature, but along the way, we hope to deliver delightful, complete solutions that include all the important components and learn from our users what matters most. 

If you try the Cake Model, let us know! Especially if you find something that can be improved – I’d love to know what the next evolution of this framework looks like.