Have you ever seen, or participated, in a conversation like this?

Person A: How long until Feature X is ready?
Person B: It’ll take at least 3 months.
Person A: We really need to have something ready in 3 weeks.
Person B: We could postpone Sub-Features A and B, but it’ll still take 2 months for the rest.

I was involved in a discussion like this a few years ago. This conversation had been ongoing for several weeks. The developer on the project was doing his honest best to cut scope, and produce a minimal, working product. But nothing was getting us under budget or on schedule.

That’s when I asked during one meeting:

What if we had to have a usable version of this new feature ready by tomorrow or the business would fail?

I got blank stares from both the developer and the stakeholder.

I elaborated.

Imagine that this is a make-or-break feature, and it absolutely positively has to be done tomorrow. What shortcuts would you take to ensure it was ready by then?

This completely reframed the conversation. With this fresh perspective, rather than trying to find where we could “cut the fat” from a complete design, we were able to conceptually add only the elements necessary for success.

Next time you can’t figure out how to scale down a larger feature, think of it the other way around. Rather than making a big problem smaller, start with the smallest possible version of the problem: How could you solve this by tomorrow? Then work your way up from there.