Even though “requirements chaos” seems to be about requirements, it’s really not. It’s about the process that requirements go through.
If you’re a product manager, you suffer from “requirements chaos.” You have too many requirements to execute on, no matter how valuable each one is. You constantly comb through the list moving them from sprint to sprint and release to release. You strive to come up with designs that knock off multiple customer desires at once. You get some features partially completed but often don’t get to finish them to your satisfaction. There’s always an “obvious” hole in your favorite feature of the latest release that you just wish you could get someone to spend a few days on, but you’re out of time.
“Recognizing that our tool problem is not just about managing a list of requirements is a major realization.”
This sounds like a requirement problem, but it’s not. It’s a process problem. It’s the process of moving requirements out of the way while I work on the higher priority ones – but making sure they aren’t lost as I do so. It’s the process of prioritizing the work I’m going to do in such a way that it’s defensible to my boss and their bosses. It’s the process of making sure I am using my heuristics to help me make the best decisions about what to do next.
For example, consider this common situation. You have a desirable requirement that will provide a lot of value, but you know you will not have the capacity to implement it in the next year.
Does any product management tool handle that situation for you? That will, for example, hide it for a year and then pop it up again? Or hide it until the product planning process seems to indicate that it might be of interest again? Or hide it until the product manager says, “Gee, I have a little extra resource for this release that I didn’t expect, what might be a good fillip to add in that will give customers a bit of excitement?”
Every tool I know makes me keep that requirement in mind. Or it makes me put it in some bucket that I’m supposed to remember to revisit later. I have a lot to remember already, and I don’t want this thing on my mind too. In fact, I want it off my mind for a while. I don’t want to have to remember to visit some bucket or other at some random point in the future. Instead, I often end up constantly seeing the list of things that I’ve deferred and making those decisions over and over again. That’s a big waste of my time, but I do it to make sure I’m not missing anything.
I want the system to get me out of this cycle. I want to trust that it’ll help me find that requirement right when it’s needed. Don’t make me use cognitive capacity now, but give it to me when I need it, magically.
I might be asking for a lot, but that’s what I want. And that’s only one example of a process I have to manage in my head, rather than being able to trust it to a tool. (I wrote about another such process-oriented capability I wanted a few weeks ago – call it “the datasheet metric” for a requirement.)
Accept360 had an approach that got me part way there – an analytical prioritization that would surface requirements that aligned with a particular set of priorities. So if next year my priorities shifted to favor that requirement I’d hidden away, it might pop up. But getting that capability depended on my having made a correct set of relationships – which isn’t terrible, except that Accept360 was not good at helping me create those relationships.
Even so, Accept360 was unique in this capability. I think and hope some of the newer tools will step up to this. In particular ProdPad has a basic analysis that compares “Effort vs. Impact” – which is something like what we had in Accept360. I haven’t validated that their “Impact” metric is as flexible as I’d like. (I talked about an algorithm for analytic prioritization in an article last year.)
The point is our tool problems are not just about managing a list of requirements. And anything that focuses on the list, and managing the list, is just going to move around the chaos for me, instead of reducing it. Solving the real product management problem is going to be harder than that. It may require taking technology to a new level – it’s definitely not just going to be using frameworks to put data on the screen. It will be exciting to work on these tools, and it will take some programmers who are ready to think outside the normal Web 2.0 box and step up to doing some unusual and amazing things.
Your host and author, Nils Davis, is a long-time product manager, consultant, trainer, and coach. He is the author of The Secret Product Manager Handbook, many blog posts, a series of video trainings on product management, and the occasional grilled pizza.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.