Why You Should Be Lazy To Win

I often challenge teams with the following question:

What would happen if you stopped building anything new? Just stopped? Killed the backlogs and roadmaps? Burned it down? Acted like a stubborn mule?

Try asking!

Someone is usually quick to say “we’d lose our jobs” (which is likely true given how most orgs work), but after the nervous laughing subsides the conversation gets interesting. Invariably, when pushed, a brave soul will come forward and say “you know, I’m not sure things will change all that much!”

Blasphemy! Make, build, grow, get things done, check things off, and stay busy. It’s who we are, right? There’s always room for another lawn gnome …

Engineers are “resources” that must be “fully utilized” and kept from being “idle”. “What would we do all day? Just sit around and refactor the code, tool up, and knock out bugs?” Keep the line rolling …

Continue the thought experiment. If you were to stop shipping new stuff, WHAT would happen and WHEN would it happen ? Would you miss a sales goal or growth goal? Would churn increase? Would the competition trounce you? And how do you know?

Pretty quickly you will get to the crux of the matter. And often you’ll discover that building more stuff isn’t necessarily the only way to solve the problem.

The irony is that sometimes we disincentivize our front-line resources — often the ones who know best — from asking these questions. Their job descriptions don’t read “push back on adding ANY new complexity to the product unless we have demonstrated that the value is a massive multiple of costs.” Instead, most organizations and individuals celebrate output over outcomes, and shipping over validating. Try revisiting your release notes from a couple of quarters ago? What happened? Do you even remember what you shipped?

If we have so many ideas … then some of them MUST be good.

In a weird form of Parkinson’s Law, teams are invariably able to fill the backlog with ideas that seem reasonably valuable (or at least valuable in comparison to each other). There’s always some new silver bullet to build or table stakes addition. Ideas are cheap. The items are stacked back to back with little opportunity to validate outcomes delivered.

Why is leaving marginally validated new stuff in the product so harmful? It’s super expensive!
Shipping new stuff creates instant debt beyond the resources consumed for the initial build (which — while diligently estimated and obsessed over — often comprise a small % of the overall cost). You’re in the red immediately. You’ve got to service it, maintain it, sell it, market it, and document it. It limits your turning radius. Take your engineering costs and multiply them x10 (and then charge regular interest) to get a better idea of the outcomes you must deliver to make it all worth it.

Why would you ever want to leave those features in the product?
So try the thought experiment with your team. What would happen if the default stance was to continuously work down debt (UX, technical, etc.), and to test rigorously, and in most cases kill, new ideas? What if the rallying call was efficacy and not efficiency or velocity? What if you encouraged people to do the least amount of building necessary to achieve the required outcomes?
Try asking the question:

What would happen if you were very stubborn about adding anything new?

Tip: One way to “get stubborn” about building random new features is to leverage data, user behavior, and actual user feedback. See how other product managers are using data to achieve 2x higher ARR.

John Cutler currently grapples with existential “why” of product management at Pendo, frequently posts on Medium, and makes really great doodles.