Do less: A strategy for building better products

05 Jul 2020

Product managers love building new things. It is a driving force behind why many of us decide on this career path; we get to spend all day figuring out what cool new thing to build next.

This love of building stuff serves us well in the early days of a product. Everything is new, you don’t have many users, and you are missing core components of your product’s value proposition. Delivering new features quickly helps you find problems that your users want you to solve before you run out of cash.

Eventually, if you build the right things and all of the pieces fall into place, you get past the early stage of searching for product-market fit and find that you have a growing base of happy users.

Reaching this point is a wonderful achievement — and a signal that your product strategy needs to change.

New feature addiction

Many product teams fail to recognize the strategic shift they need to make once they reach product-market fit and so they continue churning out new feature after new feature for years without knowing why. Often times this happens out of inertia. We’re used to building new things and building new things is comfortable, so we keep building new things.

Features will be released, fail to catch on, and drift off into the abyss as your team pivots to the next new idea. This inertia, left unchecked, will lead to a confusing product that lacks vision and fails to deliver on its promise.

All of these new features, each of which was probably a nice idea in isolation, will begin to wear on users. They bought your product because it solved a problem for them and each new feature release is another thing they have to learn, a new tab, a new button, a new pop-up announcing the latest release that they don’t need.

New feature addiction will eventually produce outcomes that you aren’t going to like:

• Your core feature set will age poorly. As you chase new features to expand your product and solve new problems, the features that got you to product-market fit will start to feel less valuable, less innovative. Your competitors will learn what made you successful and they’ll copy and improve on the good parts, without all of your baggage.
• The debt built up from years of new features that didn’t quite hit the mark will make your product hard to use, hard to explain, and weigh down your engineers. Bugs will crop up more frequently, your support team will struggle to articulate how your product works, and your velocity will slow down.

Avoid these outcomes by intentionally doing less.

Do less

Do less doesn’t mean stop working on your product. Instead, it is a call to refocus your team on the right work to keep your product healthy for the long term. A less controversial way to think about the concept of doing less is doing less work that people see.

What I really mean when I encourage product teams to “do less” is to make your product better by focusing on the hard, often invisible work of optimizing what you already have. If you do this right your users will /feel/your work more than they’ll see your work.

Doing less can feel uncomfortable, frustrating, or confusing for teams that are used to feature-based roadmaps and cultures that praise output and splashy new releases.

How can you do less and still deliver a great product? Let’s find out.

Know who you are

The first step to doing less is to create a product vision that clearly defines what your product is, who it is for, and what problems it solves. This vision will form the boundaries within which changes to the product should live. If a feature idea comes through that sounds valuable but doesn’t align with the vision, that feature should not be built.

Before you achieve product-market fit, you should have a product vision, but that vision likely won’t have enough details to keep new feature addiction in check. As you turn the corner to a more mature product, refine your vision, get buy-in from your team, and build processes to hold yourself accountable to the vision.

Do less by defining your vision and boxing out the work that distracts you from achieving that vision.

Go deep, not wide

Besides inertia and a love of the new, another reason we build new features is that new features are easy to build. Every new feature is a Greenfield full of hopes and dreams for what it could be in — all the hard stuff is still somewhere out ahead.

Working to improve a feature after it is out in the world is more difficult. You have to go deep into how people use the feature, what value they get from it, and how it could be improved. This type of work uncovers more warts than you’ll find in Greenfield work and it carries with it more risk of upsetting your users if you miss the mark.

Despite the difficulty of the work, going deeper into the features that your users already value will produce a higher return in the long run. Your customers didn’t buy 100 features, they bought a handful of really valuable, easy-to-use features. Continuous improvements to a small set of high-value features will always win out over a constant barrage of new features that are tangential to your product’s core job.

Do less by going deep into your core features, instead of playing around on the margins.

Focus on quality

No matter what your software does and who your users are, there are two things that your customers want:

1. Your product should be fast
2. Your product should work

Those two things are universally true in software. No one wants to use your slow product, and they don’t want to deal with bugs. Let’s tackle speed first. We know that faster page loads produce better conversion rates — people don’t want to waste time staring at a blank screen or a loading icon.

Speed typically isn’t a concern in the early days of most SaaS products. Everything is fast because no one uses your product. Problematic database queries are masked behind tiny tables, edge cases haven’t been discovered yet, and your single Heroku instance can handle 100x your peak traffic.

Left unattended, your product will slow down. Database tables grow, edge cases become commonplace, and your eyes are on launching a new feature while your users spend 3 seconds waiting for every single page turn. Time spent optimizing performance will almost always be a higher return on investment than time spent building nice-to-have features. Don’t wait until your users tell you things are slow — push your engineering team to proactively seek out and eliminate poor performance early and often.

The other side of quality is fixing bugs. Software is never bug-free and that should not be the aim ; however, a perception that your product is “buggy” will kill your growth faster than nearly anything else. No one wants to spend their time and money on something that doesn’t work — error pages, downtime, and unexpected behavior all add up to a terrible experience. Ignoring bugs will encourage your users to move on to a competitor that can promise a more reliable solution, even if your product has more features.

The cost of unresolved bugs compounds over time. A bug is a crack in your product’s foundation — the best time to fix that crack was before it existed. The second best time is now. Find and fix bugs before they reach your users, and build a product that is focused, testable, and easy to understand, or find yourself paying the cost for a buggy product.

Do less by prioritizing a fast, reliable product experience.

Doing less doesn’t mean stop innovating

Does doing less mean you never build new features?

No. There will be times when an opportunity exists that is worth investing in. If you stay focused on doing less, you’ll be more likely to be in a position to capitalize on new opportunities because your existing product will be more focused and more prepared to integrate a new core feature than an unfocused product full of unfinished ideas.

How do you know if a feature is worth investing in? Start with your product vision. Does the new feature closely align with your vision? Do the users you serve have the problem you want to solve and do they trust you to solve it? Do you have enough input signals to validate that the idea is worth pursuing? If you can answer yes to these questions, and your core features are fast, reliable, and well-optimized, then it might be time to incorporate something new. 

Wrapping up

Doing less is hard — I’ve struggled at various times in my career with wanting to push new features ahead of the less exciting and less visible work that comes with committing to doing less.

The strategies I’ve outlined above have helped me keep my teams focused on the long term, and they’ve been developed in direct response to getting off course by chasing after new things instead of digging deeper.

The work of doing less requires discipline, focus, and clarity of purpose. As with most really valuable things, you won’t get there overnight but the results will be worth it.

If you’re struggling with where to start, try to identify just one area where you can start to change your habits:

• If you’re dealing with a buggy or unreliable product, work with your engineering team to understand what’s causing the bugs and divert resources away from new feature development to resolve outstanding bugs
• Look for an area of your core product that you haven’t touched in a while. Use that feature as if you were a new user and take notes on what you could improve about the experience. Spend time reviewing your directional inputs to find patterns related to that core feature. Develop a plan to make that one feature a bit better than it is today and see how that work impacts your KPIs.

Starting small, changing what you can, and looking for evidence that this approach works for your product, is, as usual, the best approach.