Prioritizing Functionality - Five Questions Every Client Should Ask Themselves
Posted by: Carl Smith on Tuesday February 12, 2008
As professional web developers we have the ability to create web functionality. What we don’t always have the ability to do is determine if that functionality will be effective for our clients. That responsibility falls to the client and more specifically their users. So clients of every size, shape and color I give you these five questions. Ask them of yourself, your internal staff and your users before meeting with your web team. You’ll be surprised how much easier your kickoff meeting goes.
1) Is this functionality something my current users want?
Believe it or not, too often functionality gets built without ever asking a user if they want it. It doesn’t take long or cost much to ask them, and it can save a lot of wasted time and money. Sometimes rationales for functionality are for future users that may want a certain feature. In my experience, tomorrow never comes. It’s better to focus on the people who like what you offer today instead of going after the ones that don’t. Plus, if a substantial quantity of new users show up you can always build it for them later. Even if you have budget to spend, creating functionality nobody wants can be very negative. Imagine a forum nobody uses. A ghost ship on the web that creates the perception your company is dead in the water.
2) If current users do want this functionality, do they already have a way to get it?
The web of today is a thriving marketplace of ideas bursting into reality. If you have an idea for your site there’s a good chance it’s based on something you saw online. It’s important to make sure your users don’t already have a reliable resource they use for the problem you are trying to solve. For example, you decide to invest a chunk of your budget in a members area because there is no good place for your users to network. If your users are handymen ask yourself how many handymen even use the web? Do industry specific networking sites exist? Maybe handymen don’t network online, or it could be they’ve been pulled into the gravitational force of LinkedIn like many of the rest of us. Again, the easiest way to find out is to ask them.
3) Does adding this functionality help me achieve my site goals?
As much as it always amazes me, this question often results in a stunned look. Too often people charge into a web redevelopment project without clearly identifying the goals of the project. Without defining goals you’re going to have a tough time deciding if the functionality will help achieve anything. Examples of common goals are increasing leads, lowering support call volume, increasing sales or expanding awareness.
Often original functionality that may be great for your users won’t help you get closer to your goals. For example, let’s say you decide to create a wiki where users can collectively document information and techniques for doing their job. The result is they get the answers they need from the site and go back to work. So much for increasing leads.
4) Do I have the human resources to effectively maintain this functionality?
An often overlooked aspect of developing functionality is the need to have someone manage it. Blogs need qualified content providers, forums need a moderator and in its simplest form someone has to the answer emails sent to . Otherwise you will end up with a disaster on your hands. Forget someone thinking you don’t have any original content to put on your blog, someone may start talking about a negative experience with your company on your forum and even one day without a moderator stepping in to “find out more” may look like you just don’t care. Dedicated people with time to manage required functionalities are a must.
5) Do I have the budget to build it correctly?
This is the question everyone wants to answer first. But to prioritize the functionality you need to look at each opportunity individually and order them based on their ability to achieve the project goals. Obviously there are very few projects with endless budgets. With that in mind, once you have the functionality prioritized it’s a great time to put Andy Budd’s Contract Killers philosophy into play.
Filed under: Business, Interweb, Technology
Fred Boyle
02.19.08 at 2:40pm
A great post, and so true.
The importance of “what problem/goal does this address” is HUGE.
Without carefully considering this a project can get out of hand very quickly.
Reducing the essence of a web site to core features and doing those features well is far better than creating all possible features in a so-so way.
A web site is a dynamic beast, always evolving and changing – features can be added or modified over time.