Software is based on features. It really boils down to a series of tasks to complete. The faster your software can allow a user to complete the task they are set out to do, the more enjoyable it is for the user and the happier they are to pay you.
Think about the software that you love. Think about your go to app in a crowded market. That market could be todo apps, project management apps, or maybe even word processors. The one app that you use without thinking is the one that makes you the happiest.
Now think about the software that you tried and hated. It was difficult to use, finding what you were looking for is clumsy and never quite works as you expect it to. It took too many action to complete a task. It probably even has features that you don’t use or even understand how to use.
Bad software is the result of a poor feature set. If those features aren’t solving a problem that you are having, they are just taking up screen real estate. And more often than not, getting in your way because you don’t care about them. They hold no value to you.
Understanding Features
The importance of being able to understand features cannot be overstated. Extracting business value from features is the key to building something worthwhile. It’s easy to get bogged down with wants versus needs. A feature that ends up in the want column is one that is cosmetic. It might start out like this “Hey, wouldn’t it be cool if we could…”. Beware. This isn’t solving anything and it will get in the way.
Features must demonstrate business value.
Question everything.
Feature Specification
This is why story driven development is so effective. Instead of looking at features as something you think a user should be able to do, you are looking at why a user is using a particular feature.
The basic format for a story is:
As a [user]
I want [perform some task]
So I can [receive some value]
Now the conversation turns to why. Why is the user looking to complete this task? You are defining what value is being gained from a certain task. If your feature doesn’t fit in this format, it’s more than likely a want.
For example, say you want to add comments to your application. You think this is something your users want and it provides a definite value. You might write that as this.
As a customer
I want to comment on entires
So I can contribute to the community
Now everyone on the team knows why they are building comments. Comments provide a community aspect that keeps users coming back to contribute. This is definitely valuable. Not only to the users of the application, but also to the product owner.
This also sparks a conversation. How should these comments be structured? Can a user reply to a certain comment or person? A lot of applications allow users to reply inline with another comment. Is that valuable? Why? Does the user get the same value without the inline comments?
You should see a pattern here. This is clear communication. These are words everyone understands. No programming logic or color theory. Only expected outcomes. The result is always a more solid feature with high value for users and product owners.
Solve the real problem
For every feature, there is a deeper problem to be solved. The feature is actually exposing the problem, you just have to see through what’s on the outside to get to the core.
You can’t go wrong with valuing communication over everything else. Ask questions, debate purpose, and solve problems at the core.
Not Just for Teams
I often work by myself. Just an editor, an idea, and me. This method of extracting business value still works. Even for apps that are just for play.
It still forces me to build things that matter. Not to mention it’s always good practice to play how you work.