I am a big fan of boxes and arrows, but this time, Jeffrey Davidson found a great article by Dan Willis before I did, and told me about it. Thanks Jeffrey! The article is about how to deal with the what and how of requirements and design – and it provides some really sage advice. But what got my attention was the lack of prioritization of requirements in his example.
One Man’s Trash
Dan’s article is about the difference between what and how. He provides good advice on changing the conversation to be what-centric, not how-centric. Dan is writing from the perspective of an information architect, and he defines what and how as follows:
As I started to work in jobs where some people communicated with one another using requirements, it seemed reasonable to keep separating “the what†from “the how.†These two definitions are the result:
- Business requirements: What the project, system, or solution needs to accomplish.
- Functional requirements: From a high level, how the project, system, or solution needs to accomplish what it needs to accomplish.
Are Useful Requirements Just A Fairy Tale? (and why an IA should care)
Although we used slightly different language, we wrote an article about how different people in the software development life cycle think about different artifacts created in the process. The following diagram sums it up:
Dan describes the product management view of the world in his article. It is a good article, and you should read it – his pragmatic solutions to common frustrations are good ones. They center around turning the conversation (with product managers) into one of What do you need? instead of How do you think I should build something?.
Prioritization Hell
As good as his article is about the frustration of mis-matched roles, here’s the paragraph that really got my attention:
First, you get a group of stakeholders in a room so they can “blue-sky brainstorm†to figure out how they want to improve their product. The group comes up with a list that has everything from “Make the little blue buttons bigger†to “Bring world peace.†The list goes to an engineering team who organizes the list into three categories: Things we can do now, things we can do by the end of the year, and things that will take a long time. They email the categorized list to a project manager who changes the categories to Phase 1, Phase 2, and Phase 3 and sets up a project schedule for the first 10 things in the Phase 1 list.
Dan Willis
Aargh!
This is why prioritization matters.
You should always prioritize the capabilities that yield the highest returns on your investments. Those returns may be based upon a measurement of risk, a strategy for gaining market share, or straightforward cost reductions. You can also refine this approach by applying the principles of Kano analysis to maintain a user-focus. You may need to balance the goals of users with those of stakeholders. But definitely don’t let someone prioritize features based on how long they take to implement.
Dan, we feel your pain!
