If they’re going to cut scope, you’ve got to watch out for the ‘Mutant Potato Head’

In addition to facing very tight development schedules, we invariably find ourselves needing to cut scope from a project in order to meet the desired ship dates. At our company, we’re operating in a date-driven environment. I don’t know about you? But that seems to be the norm in my experience in spite of the more open-ended framework you hear about in the Agile books.

So if cutting scope is the reality, what’s a UXer on a sprint team to do? Well, let me start by telling you what NOT to do: You most definitely do not want to end up with a Mutant Mr. Potato Head on your hands.


I’ve seen it happen too many times. A person – usually someone not on the actual sprint team – starts going through the backlog and pushing things out of the release based on size (storypoints/hours) and personal opinion (“We don’t need that. That’s gold-plating…”) until they get to a point where what’s left fits the dates.

This may be followed by an announcement to the team: “We need to pull in the dates by a month, but it’s okay, I took care of it.” Or, “We’re not burning through the backlog fast enough so I went ahead and cut the fat from the project so we can make the date. We just need to finish what’s left.”

Now, you could say there’s a problem of encroachment here: It’s the Product Owner’s job to manage the backlog. Why is someone else going in there and pushing stuff around without consulting him/her? And you’d have a point.

But I say there’s a more fundamental problem that starts with the approach that was taken. When you need to cut scope – for whatever reason – the starting point isn’t to go looking in the backlog for what you can take out. The starting point is to have a conversation with the team, on behalf of the customer, to re-examine the goals of the project and ask, “How can we deliver value and meet the intent of the project in less time?”

UX needs to be sitting front and center when that conversation occurs.

But let me digress… You may be wondering, what does any of this have to do with a ‘Mutant Mr. Potato Head”?

That came from a conversation I had with the UX team after this exact scenario happened to us. I heard about the cuts after the fact. A UX team member brought it up in our UX team meeting and he was not very happy about it.

I sized up the situation and went to a white board to start drawing. “This isn’t the right way to go about it,” I told them. “They’re not thinking about what we’re trying to deliver to the customer.” (In this case “they” was the Product Manager and Architect, both of whom knew the project well but were not members of the sprint team with an intimate understanding of the feature-level designs. But they still went ahead and chopped away at the backlog when word came down that we had to bring in the dates.)

I drew an analogy for the UX team to help make my point. I asked them to imagine that we were a toy company and that we wanted to make a Mr. Potato Head doll to sell to the kids. (My daughter was around 3-years-old at the time and we had a Mr. Potato Head at home, so it was the first thing that leapt to mind.)

Now say we came up with the design and we’re all happy with it and it’s been kid-tested, mother-approved – so now we’re ready to build. But as we start building things go wrong and we’re running late. We need to cut back from the original scope in order to deliver something on time. But what do we cut? Well, we could just start hacking away at the backlog based on sizing, but that may produce something like this:

Mutant Mr. Potato Head

Do you think a kid would like to play with that? It’s actually a little creepy and scary isn’t it? But hey, we can hit the date so who cares. Our work is done here.

Not right.

If we were to take a step back and reconsider the project goals: Let’s make a fun toy for kids to play with that lets them design the character and make it different each time. What could we do?

Well, first of all, you have to have the body. Everything depends on the body. And notice in the Mutant Mr. Potato head above, there’s only one foot. The thing won’t stand up with just one foot! That’s no good. You need two feet. Okay, now what? How about a face? Two eyes and a mouth will do it. A nose would be nice, but we’re pressed for time. Maybe it’s more fun to have a hat or a silly hair or something else to put on top. The top is kind of flat and weird without something up there, so yes, that’s a good idea. We’ll go with a hat and not a nose.

Now what? That’s all that fits. We’re at maximum capacity. Okay … But think about it. It doesn’t cost us anything to put the extra holes in the body where the parts click-in. We can put all the holes in and then the kids can move parts we’re shipping with around to silly places. And shortly after the product is launched we can have a follow-up project to produce a ‘Parts Pack’ that we can sell in stores that adds all kinds of fun things the kids can add to their Potato Head. And we can charge extra for that! Hey, we didn’t even think about that idea the first time around…

Okay, it almost sounds like we planned it this way from the start. Cool. We have a project. So don’t build the ears or the bow tie or the nose yet. Instead we’ll do the eyes, mouth and head. And definitely the body and feet. And we’ll add the holes where all the new parts will go. Perfect! Now witness the difference between our new plan vs. the old Mutant Potato Head plan.


And all it took was a conversation.

So the sad news is, in the original story where the Mutant Mr. Potato Head example came from – we did ship a bad design. The fact that the cuts were already made worked against us. It was too hard to get the powers that be to go back and revisit the work. And we paid a price in future Tech Support calls. So we learned our lesson.

Now whenever we face a situation where cuts need to be made the UXers in the group always call out, “Watch out for the Mutant Potato Head”. It makes people laugh, but hey, they remember it. And it leads to having the conversation up front before making decisions which produces a better result, proving yet another way that UX can help provide value.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s