Walking the Tightrope
What is our core competency at FreshBooks? Walking the Tightrope.
Walking the tightrope is a term I use around here more and more…What does walking the tightrope mean if you are a web application developer? It means finding a balance between what people need and what you *can* put in your application.
Believe me, we’ve dreamed of a million things to add to FreshBooks, but that does not mean we should add them all. If fact, the whole point is we should NOT add most of the things we come up with. We should only add what people need…or what most of the people need. The guys at 37Signals call this the 80/20 rule. I like that. If 80% of people need something you dream up, chances are it should be added. What else should you add? Things that *pain* people…if you have a nice tight feedback loop, and you stay close to your customers, it won’t be long before you know very clearly what pains people.
Increasingly I talk with people outside our company who say, “What if you added this? What if it worked this way? I bet people would like this feature?”
The thing I like most about these questions these days is the way I get to answer: “Well…we have over 2.5 years of customer feedback, I’ve read every one, and no one has mentioned that so while I can see it might be *nice to have*, people just don’t seem to need it”. If I give it a moments thought I can come up with a very logical reason as to why no one has asked for it: It’s out of context of the relationship/the workflow/people’s expectations, and every time that happens, I get more insight into what we’re doing here that I can use to help better walk the tightrope carrying forward. It’s a virtuous circle.
users collect enough money to buy all 
9:12 pm
You’re taking the right approach, Mike. Good on ya.
Walking a Tightrope is what David Maister refers to as ‘Strategy Means Saying No.’ Any time you need some moral support on that, check out Maister’s article of the same name (here: http://davidmaister.com/articles/4/95/)
(Full disclosure: David is a client, and I am a very happy Freshbooks user.)
10:49 pm
Mike, Great post and so very true. It’s one of the reasons Microsoft is so different from Apple. Microsoft products are robust and powerful, but so complicated that users are not fully aware of the potential and will never even scratch the surface if they did because they don’t know how to use it. I don’t personally use Apple but everyone knows that they take the lessons you mentioned to heart and create user centric experiences that do the basic things people know and love and do them well. Here is a short topic from one of the Apple developer websites that in line with your blog gives an insightful explanation of software design considerations.
————————————-
Making Design Decisions – When making design decisions regarding features in your application, it’s important to weigh the costs, not all of which are financial, against the potential benefits. Every time you add a feature to your application, the following things can happen:
* Your application gets larger.
* Your application gets slower.
* Your application’s human interface becomes more complex.
* You spend time developing new features rather than refining existing features.
* Your application’s documentation and help become more extensive.
* You run the risk of introducing changes that could adversely affect existing features.
* You increase the time required to validate the behavior of your application.
Choosing appropriate features and devoting the needed resources to implement them correctly can save you time and effort later. Choosing poor feature sets or failing to assign appropriate design, engineering, testing, and documentation resources often incurs heavier costs later when critical bugs appear or users can’t figure out how to use your product.
Avoid Feature Cascade – If you are developing a simple application, it can be very tempting to add features that aren’t wholly relevant to the original intent of the program. This feature cascade can lead to a bloated interface that is slow and difficult to use because of its complexity. Try to stick to the original intent of your program and include only features that are relevant to the main workflow.
The best products aren’t the ones with the most features. The best products are those whose features are tightly integrated with the solutions they provide, making them the most usable.
Apply the 80 Percent Solution – During the design process, if you discover problems with your product design, you might consider applying the 80 percent solution—that is, designing your software to meet the needs of at least 80 percent of your users. This type of design typically favors simpler, more elegant approaches to problems.
If you try to design for the 20 percent of your target audience who are power users, your design may not be usable by the other 80 percent of users. Even though that smaller group of power users is likely to have good ideas for features, the majority of your user base may not think in the same way. Involving a broad range of users in your design process can help you find the 80 percent solution.