How to design a cupcake

8 min readNov 24, 2020

Photo by Calum Lewis on Unsplash

Businesses can better improve their product and compete within their marketplace when they make small, incremental steps to build toward a vision. This is because by starting small, they’re able to quicker weed out good ideas from bad ones with real user feedback that minimizes effort wasted. One way to think about this approach is to compare it to baking a cake:

The classic way people think about baking has them focussing on the individual ingredients, each of no value to the end user. You can deliver the base first, then the filling, and finally the icing. Only at the end of the final phase do you have something edible; something you can learn from.
Alternatively you could start off with a cupcake. You’ll learn the flavours you like, uncover any problems in your kitchen, and in general you’ll fast forward the feedback loop. You can then step up to a regular size cake, safe in the knowledge your ingredients are all fresh, your oven works, and your flavours are nice. Only then can you deliver a wedding cake.
– From Start with a cupcake by Des Traynor, co-founder and Chief Strategy Officer at Intercom

Though speed is a core principle of the agile process, and stepped approaches are widely favored within the product community, it’s much easier said than done. Starting with a cupcake is very difficult when this theory is applied to real world conditions.

I’ve spent a decade with “designer” in my title, and this past summer, I transitioned to a hybrid design/product management one. My experience completely shifted my thinking about design. I realized how much influence design can have on the success of projects if they’re involved in mapping out how to get there.

What can designers do?

There are a few key parts of a PM’s role that designers can adopt to have more impact on their company’s success.

One thing at a time

At my last job with The Washington Post, I was part of a team responsible for maintaining and improving a page that marketed subscription options. The page’s performance had a significant impact on the company’s bottom line, but it hadn’t been redesigned in some time. There were a variety of small changes we wanted to make to clarify the customer’s options and visually polish the overall styles. I spent months deliberating on a solution that combined a variety of updates and the team was convinced it would boost subscriptions. We tested my new design against what existed and to our surprise, the new design failed. Making it worse was that we combined so many adjustments into one variant it was impossible to know WHY the new design failed.

So if you’re setting up an experiment, determine what question it’s posing. Make sure the test isn’t combining multiple questions, otherwise feedback won’t be clear.

If this is an initiative to address known user pain points, use data to highlight the most important pain point for users and aim to address that first.

Use Parkinson’s law

Parkinson’s law states that work expands to fill the time allotted. Have you ever noticed that team meetings rarely end early? This is because the conversation length usually fills the time available. You may have also noticed that spending more time to have a discussion doesn’t always mean it will be more productive. Time and value, in this case, are not linked.

If you’re having trouble narrowing down what work needs to be done to release something, try adding hypothetical constraints. Think about how long it should take to build something based on its importance. What if you only had two weeks to build something? After those two weeks, what would you decide should come next? This should help your team clarify its goals and keep the project’s scope tight.

Work closely with developers

It’s hard to make pragmatic design decisions without knowing the effort involved in building them.

Imagine that instead of designing something, you’re writing a sentence. Every letter costs money, and your budget is small. You may start with some drafts to figure out what point you want to make. Eventually, you’ll want to find ways to be more concise. Are there any synonyms that are shorter? Are any of the words superfluous? The objective is to make sure that the cost of each word is justified by its meaning or contribution.

Reach out to the developers on your team early so you know what will take a long time to build, what’s fast, and whether anything that already exists can be reused. Use this information as inspiration to guide your solution. Remember that you can expand the sentence or create a paragraph once the feature proves to be valuable to users.

Dedicate time

The design process is never linear. It’s messy because problem solving is messy. Still, I believe that build plans can be stronger if designers carve out time within their process to think about how the project should be built in order to deliver improvements to users more quickly.

One approach could be to schedule time with your PM to define implementation together. To take this a step further, ask to operate as a PM on an upcoming project and gain a first-hand sense of the role.

Spending time to think about the rollout will make a difference in how you design because you’ll more deeply understand all of the considerations at play before a product is released to its users.

What about the long term vision?

None of what I say above should be taken to mean that designers shouldn’t spend time on the product vision. One of our strengths as designers is our ability to visually illustrate ideas. Showing a picture of a feature can be much more compelling than describing it with words. I’ve found that designing for both the ideal vision and a first step toward it is a powerful approach for two reasons. For one, it can be hard to define pragmatic ways to work towards a vision because the exercise intentionally ignores constraints. And two, it can be hard for teams to rally behind an MVP if they’re not sure where it can lead.

So, work forward, not backward from your vision. Think of it as a guidepost, not a literal depiction of a feature. Use it to gain agreement on a high level direction, then re-focus on what exists today and what can be repurposed to take a baby step toward the long-term goal.

We often think that it’s the designer’s job to push for what’s ideal and the PM’s to cut scope and make it happen. This, we think, is a healthy tension. When my role shifted, I no longer had a clean divider between design and product management. I was forced to adopt a hyper practical mindset, and instead of only thinking about what an ideal experience would be, I had to consider the cost of each and every decision I was making. This switch showed me that designers are well equipped to create implementation plans because of our deep understanding of each ingredient; we know what will work at cupcake scale and taste best.