3 Ways to Stop Building More Features

3 Ways to Stop Building More Features

By chris danilo on Sep 05, 2016 07:00 am

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.

Recent Articles:

Snooze
Priority vs. Urgency
You Can Build Whatever Kind of House You Want
The Only Thing That Matters for your Project
The Truth About "No Pain; No Gain"