Build Less, Execute Better: A Mantra for Better Digital Products

We’ve shipped hundreds of digital products, and iterations on those products, since we started Paper Leaf back in 2009. Whether it’s a web application, mobile app, or website, I’ve seen one thing more consistently than anything else:

Too many features, not enough budget.

Often, this is an unconscious agenda, or something borne out of a lack of experience. But the background doesn’t really matter; the plain fact is, many of us have feature eyes too big for our budget stomach. We try to fit way too many features into our web or mobile app budget.

From a buyer’s side – I get it. Personally, I want to maximize the value of anything I buy, be it a house, or a car, or some weird piece of bikepacking gear. The same applies to those sitting down to sign a software development contract.

The problem, though, is when we conflate volume with value. Meaning, more features must equal better value. That belief couldn’t be further from the truth.

Feature Volume vs. Implementation Quality

Feature bloat is a real thing, and it creeps up on the best of us over the course of any digital project. It could start in the ideation stage – the “wouldn’t it be cool if…” moments – and routinely comes up through discovery and design/development cycles. And the plain truth is, it often comes at the expense of quality. Why? Because timelines and budgets don’t shift at all, or enough, to accommodate the new features. If budget is fixed, at a certain point volume and quality become mutually exclusive.

It’s easy for excitement and an unclear value proposition to take charge, leading to more and more features added to the list. When that happens – when we succumb to feature bloat, or try to maximize the volume of features over the quality of implementation, we can end up with:

1. shoddy implementation
2. bad UX
3. technical debt
4. an unhappy product owner
5. low adoption, and/or
6. a blown budget

And if you have the above, your product is doomed. It doesn’t matter how good your service level agreement is, or if you’ve accounted for all the post-launch risks in the world. If you do acquire early stage users, they are likely to churn out as you pay the technical debt and UX piper.

Instead, if you approach your product with a “build less, execute better” mindset, you’ll often have a better outcome. Here’s why.

Benefits & Principles of Building Less & Executing Better

“Build less, execute better” means you should follow most or all of these principles:

1. Fewer features, same budget
2. Simpler implementation
3. Proper, cutthroat prioritization
4. Emphasize user testing

And if you do follow the principles of building less and executing better, you’ll likely see: better adoption from your users; better UX; less technical debt; and next-to-no budget overages.

Your odds of success are considerably higher. Building less and executing better also means you’ll likely get your product in your users’ hands more quickly, leading to the all-important end-user feedback cycle – which is where products move from good to great.

Putting it Into Practice

At its core, the principles of building less and executing better are simply about valuing execution and prioritization over everything else.

Take a moment to think about the applications we all use on a daily basis – Google’s tools, Microsoft’s stack, Facebook, Instagram, Twitter, AirBnb, and LinkedIn. All of these tools have exceptional UX and UI, and they are changing our baseline expectations of acceptable software. In order to land and retain your users, you have to have exceptional UX and UI. And exceptional UX and UI comes from – you guessed it – building less and executing better.

I’ll leave you with four key ways to put this all into practice.

1. Understand your users, deeply.
2. Have multiple rounds of prioritization. Read more about the 2×2 method here, but don’t just do it at the project outset.
3. Initially, identify and ship the smallest combination of features that differentiate the product – nothing superfluous.
4. Design, test, iterate, and be flexible on those features.

The world doesn’t need anymore half-baked, bloated, poorly executed software, so let’s just … not. Besides, those products fail more than the smaller, well-executed products. Instead, start small, understand your users be cutthroat about your features, and work in an agile manner.

Say it with me: Build less. Execute better.