When people discuss application design, they like to talk about killer features; however, the talk about killer features is often misguided. Many product managers, project managers, and developers get caught up in the killer feature mindset, and then they completely overlook the fact that the product itself is not very useful, or is trying to solve the wrong problems. A killer feature is only important if it supports your application's purpose.
For instance, let's say you invent one-click checkout, but your site sells services that require a lot of customization at checkout. In this scenario, you might have a great feature, but it would be killing your sales. Instead of thinking, "what features can I build that no one else has?" there is a much deeper and important question: "what's my killer idea?"
You often see people throwing a feature into their product because a famous application uses that feature, but success will not necessarily be the result. Take a look at Amazon.com. It's tempting to think that the company's success is due to having a killer feature like one-click checkout or its product recommendation engine. These features do play a huge role in Amazon's success, but take a deeper look at everything that Amazon does; the entire company's focus can be stated as, "make it as easy and desirable as possible for customers to spend their money with us." That is Amazon's killer idea, and the site's features support that goal.
When you shift your thinking to the concept of killer ideas, a new realm of possibilities opens up. You'll likely realize that you often do not need innovation or invention to solve problems — just some common sense.
A couple of months ago, Bob Walsh of 47 Hats did one of his MicroConsults to help me with my Web application Rat Catcher. It was worth the money, and I learned a lot. He helped me focus on marketing, and reinforced that I need to convey three things to potential customers:
- They have a pain point.
- I have a solution for their pain.
- How my solution addresses their pain.
How does this relate to features vs. concepts? Simple. A feature plays into the third point, and features solve problems. The idea is the second item.
I think of Rat Catcher as a tool that allows content publishers to discover inappropriate use of copyrighted material, and that's the sales pitch. New features are always evaluated against that metric, "does this proposal allow us to better meet our goal?" If not, then there needs to be an overwhelming reason to include it in the software; otherwise, I am just wasting my time and cluttering up my user's life. My target audience is very busy, and as it is, they barely have time to use the tool. One thing I've learned from the beta period is that, even though putting a document into Rat Catcher takes less than a minute, that is still too much to easily integrate it into the busy process of people. That's why one of my first post-launch features will be integration with WordPress to coordinate the submission of new items. This single feature would get more people using the application. Will it be a killer feature? Maybe. But, more importantly, it is in support of the killer idea.
This is where a lot of application developers go wrong. They add features because they can, or to justify changing the version number (and, therefore, charging for an upgrade). The broken business models underlying many (if not most) software companies are partially to blame, though the leadership and development staff share a lot of the responsibility too. Developers love the new and shiny. Sometimes this can be great, such as when we want to explore cutting-edge techniques that deliver real results. At the same time, a clever idea that we insist on sticking into shipping code can lead to feature and scope creep. And throughout the process, we lose focus of the point of the application — that is, the killer idea.
If you haven't come up with your application's killer idea, it's a great time to think of one. Start by considering the simple question, "what pain does this alleviate?" and then writing down the answer. That's the goal of the application. Next, you need to explicitly define what your application does to solve the problem — not in terms of features that can be put into bulletpoints but as an overarching solution. This is your killer idea. Finally, you should lay out what your application does at a feature level to support that idea.
Here's an example that uses my friend Jon Kragh's Create a Restaurant Website. I don't know that the following was his actual decision making process for this project, but this is me laying my process onto his excellent idea.
- Restaurants have awful Web sites. They pay a lot of money to someone who gives them an ugly, SEO poor design. They either get a complicated CMS or a bunch of static HTML, and either way, they can't figure out how to update it on their own. So they need a way to save money on their site, and be able to self-service the updates.
- Create a system where restaurants can sign up and fill in a simple form with their information, and the system will create the site. Bundle the hosting in and provide a number of SEO friendly, highly usable, good looking layout templates, and charge a low, monthly fee.
- Feature: easy to self-service restaurant details.
Feature: selection of templates/CSS.Etc.
The end result is an application that has a laser beam focus, and as a result, will no doubt be of great value to customers as well as generate piles of revenue. Now that's a business model I can get behind!
By constantly supporting an idea and not a feature list, you have the ability to truly innovate and deliver a great application that your customers will love.
Justin James is the Lead Architect for Conigent.