In case you haven't been following along, I tend to talk quite a bit about web2project and its upcoming release. At this point, the release is so close that a number of questions have popped up:
What features does it have? What features doesn't it have? Where are these features found, defined, and refined? How do you determine any of those? What is the process? How do we get there from here?
These are all variations and nuances of:
What does the next version look like?
Regardless, all variations of these questions plague organizations, teams, product managers, and customers waiting for the next version. In some organizations, answering these questions will cost millions of dollars and potentially lead to many millions more. Luckily, in this case, we're only considering web2project, but my process tends to be the same.
First, listen to your customers. Pull together your bug lists, feature requests, the “nice to have's” and everything else in between and put them on a single list. It doesn't matter who requested what or when at this point, just get them all into one big list.
Next, listen to your team. Every member of your team (including you!) probably has a list of annoyances, issues, or things they've been doing outside the product that might make sense. It doesn't matter who requested what or when at this point, just get them all into one big list. If they're already on the list, add a checkmark.
Next, listen to your community – including sales staff if it applies. Odds are you have competitors – new and established – and potential customers that became their customers. If you can find out what problems they're facing, all them to the list. It doesn't matter who requested what or when at this point, just get them all into one big list. If they're already on the list, add a checkmark.
Now you have a list of every thing everyone has requested. Most likely there are a number of things that have come up numerous times. Most likely there are lots of silly things that don't really make sense. Most likely there are some real insights and powerful concepts that you hadn't considered. And most likely there are things costing you quite a bit. The “cost” could be incurred through lost customers, bad press/commentary, dissatisfied users, or a variety of other things… not all will translate directly to dollars.
Now, choose one. If you could only do one thing on the list, which one would it be? This is going to be a battle and each stakeholder in your project is going to have a different opinion on what it should be. If you keep the decision based around the “cost” concept from above, it should keep things focused and non-personal. Most likely whenever you pick something, a whole list of dependencies
will be required. Identify those too. Now choose the next “single
item” and repeat this process. Once you've done that three or four
times, go to the next step.
Now, start attaching estimates to each of those items and dependencies. You aren't looking for exact estimates, more “order of magnitude” for a
starting point. I generally use “small”, “medium”, or “large” to keep
expectations from being too solid yet.
As you're working through these, your picks from above will shift. For example, if you have one “large” item that saves a few hours each month and rarely requested, it will probably drop off the list in favor of “medium” item that saves a few hours each month. The benefit is the same but the cost is smaller, so the smaller cost wins. This is Return on Investment (ROI) and handy to keep in mind.. sometimes a bunch of little wins are better than one large win.
Finally, compare the estimates against your limitations and find the cut off. If you have an annual release cycle and ten people, it's going to be signficantly different than a team of three on a quarterly release. Either way, you have limitations that will require you to draw a dividing line on your list… on one side of the line is what you can get done, the other side isn't going to happen this time. Please note that “not this time” is not the same as “never”.
Overall, I've found this to be a tedious painful time-consuming effective way to collect feedback from the people who care (aka not necessarily everyone) and make some decisions. There is no way everyone will agree on all of it 100% of the time, but it's a good way to get most of the team to mostly agree.
Foolproof?
Not a chance...