3 Ways to Stop Building More Features

I was working with a software company a few years ago and they were having trouble developing new features for their customers.

The idea was: “we want to get feedback from our users and apply it directly to our software build.”

This is a GREAT idea–but it’s so often implemented poorly.

Customers generally ask for features, and that may not be what actually helps them or their workflow–and development teams end up adding them because they don’t know what else to do to move forward.

The saying goes, that if you ask a customer what they want, they’ll generally ask for a “faster horse,” not being able to foresee the automobile.

Customers generally have an idea of what they want, but they often just ask for features. This means that you’re going to be adding and building on a structure that might not be equipt to handle all of these limbs.

So how do YOU see and build the car, instead?

1. Start with the 5 Why’s

Once you’ve asked the customer “why” they need or want something, and they give you an answer, ask “why” again. And again. And again. Eventually, you’ll get to a root cause that will likely give you insight into a more systematic or global problem.

Here’s what Six Sigma has to say about this process.

2. Ask: “can you walk me through this process?”

Customers often can’t tell you about all the little pains and problems they have until they’re right there, in front of them. Have them walk through the software and you’ll start seeing the 20% of the problems that are causing 80% of the friction.

3. User Centric Design

Instead of telling your development team: “we need to add a button on this page,” it helps to think about the feature from the customer’s perspective. Instead, try telling the team: “the customer wants to add an item to their shopping cart so they can check-out without leaving the page.” UCD puts the customer first, ahead of the features.

This sentence has 3 parts: Who, What, Why. If you’ve used “user stories” as part of the Agile SCRUM methodology, this will look familiar.

  • Who’s story is this? For whom are we building this? This gives context to the development team.
  • What do they need to do? If you limit your team to thinking they just need to build a button on your website, they won’t be able to consider all the other simpler and easier options that might help in the long term. It’s not your job to tell your team how to build the feature, that’s why you hired them!
  • Why does the customer need this? Knowing this will not only help you design something that works with their workflow, but it will also help you prioritize this task when it comes down to it.

The common denominator here?

“Get out of the building and talk to customers”

– Steve Blank

Do these three things, and you’ll have a much better chance at building the automobile, instead of just a faster horse.


I’m not going to lie to you and tell you I haven’t done it.

I’m not going to wave my hand and point fingers.

Instead of pretending to be perfect all the time, how about we substitute a little pragmatism.

Instead of telling yourself that it’s inexcusable to ever hit the snooze button, perhaps a better question might be: “How many mornings out of the week do you hit the snooze button?”

How many mornings out of the month?

The year?

The snooze button is another habit. It’s a small moment of procrastination, and it’s worth mentioning because it’s literally the first thing you start your day with.

If you start most days with an act of procrastination, how do you think it might fold into other habits? How might it affect your mindset or your thinking in other contexts?

It’s a brick wall.

And every day you do what you want or expect yourself to do, you get to add another brick.

The more times you hit the snooze button, the more missing bricks you’ve got–and you can’t go back and add them once everything’s sealed in concrete.

At the end of the year, at the end of your life, how strong is your wall?

A few gaps won’t make that much of a difference, but a gap every 7 bricks might.

Priority vs. Urgency

What’s the number one thing you need to accomplish today?

It doesn’t matter what’s urgent, pressing, or what’s got a big red notification on your phone.

Priority is not the same as urgency.

Urgency asks when something needs to be done.

Priority asks whether you should do it at all.

There’s only one priority.

So if everything is a priority, nothing is a priority. Sometimes putting in more work can help get more done, but if your focus is allocated across multiple “priorities” you’ll probably just end up with a bunch of half-baked tasks.

Ask yourself “is it better to get one thing done, or to get nothing done at all?”

If the answer is still “well, everything has to get done now,” you may want to reconsider the mission for your project and if you’re solving a problem that’s solvable with your current resources, or, perhaps, whether you’re sure you want to be working on this at all.