Requirements - Discover, not Gather!

Over the years, I have found that I always have an internal screech when someone uses the term “requirements gathering”. The term itself makes it seem like the requirements are lying there, and the Product Manager just has to grab them and pop ‘em in a document. If we were creating custom solutions, the phrase might be more accurate – all of the users would be identifiable, and we could truly gather requirements from them. We’d still need to design the product in ways the user couldn’t even imagine, but with a limited and fully identified group of users the job would be pretty straight-forward.

The requirements beast changes its face when we’re building commercial solutions. We define a market segment, to help narrow the field of potential users. Then, we have to find potentials in that market segment, and watch them in their environment. We need to interview them, to really get to know their situations. And, we need to find ways to sample the segment at large, to find out how pervasive problems really are across the segment.

Each potential we visit may use slightly different ways of expressing their problems. The adjacent systems may vary from one location to another. Some problems only occur in parts of the market segment, and the problems sometimes seem to vary greatly.

Product Managers must study all of this information, and somehow discern which problems are most important. We have to narrow our field of vision from “all possible requirements” down to sets of problems that, when solved, will incent people to spend money. Only then can we actually document the requirement (Every [frequency], [persona] has [problem].) and clearly guide our teams to build a product that’s worth our time and energy.

To build awesome commercial solutions that people want to buy, we can’t just GATHER requirements – we have to study the market, and analyze their problems. Requirements aren’t gathered, they are DISCOVERED through our analysis of market evidence. Then, they are written with the right context to improve communication to our teams, helping our teams build outstanding solutions that resonate in the market.

What do you call the process of discovering requirements?

Is Cherry-Picking Bad?

The long Memorial Day weekend was nice, and the weather is finally decent in Wisconsin. The grass is growing faster than I can mow it, and the birds are thick. Last week, the woodcocks were peenting most of the night, and the owl calls have begun. The oaks are finally leafed out, and the wild geraniums are blooming everywhere. All this means that I am distracted, as you can probably tell by the lack of posts this past week! It’s not that I’m not working – it’s just that I haven’t had a really high concentration level. This week, it’s back to business – the birds are tuned out and I am catching up on my reading.

Last week, I found myself cherry-picking from my to do list. I finished quite a few things…light-weight items that didn’t require a lot of concentration. I travel a lot, and find it most beneficial to do these low-concentration tasks for my first few days back in the office. My mind needs to rest and re-acclimate before I can focus.

I can organize my workload appropriately, so that I can cherry-pick the easier stuff when my mind isn’t prepared to focus. I can get away with that for a week or so, max. After that, I have to go back to high-concentration items, because the light-weight tasks are done for now and the meatier items need to be addressed.

One of the best parts of my job is that I get to talk with a lot of Product Managers. One common complaint is that their agile development team is cherry-picking items during the sprint. We turn over requirements, and development creates a sprint from the highest priority group. Our developers are often optimistic about schedules. During the sprint, some things don’t get done. I often hear a suspicion in these teams – suspicion that the development team works on the items that seem most fun, and don’t make it to the “other” items. That’s like if I cherry-pick from my to do list, and never quite make it to the higher-concentration items.

This behavior during an individual sprint does not bother me. In fact, I don’t really care how the development team’s work is organized – as long as they are addressing requirements in descending priority order. I understand that sometimes, we overestimate capacity and don’t complete everything that was planned for the sprint. All I ask is that the next sprint begins with the leftover tasks, so that they continue working in descending priority order.

Our teams should finish ALL the items planned for one sprint, before moving on to the next group of requirements. If we’ve done our jobs as product managers, the current iteration includes the highest priority requirements. If the team gets to the end of the sprint and they haven’t finished all the work, the next sprint should begin with the leftover items. Cherry picking is OK for a little while, but eventually we have to go back and finish the stuff we skipped. It’s a good rule for personal organization, and it’s crucial when developing commercial software in an agile world.