The big problem with PM tools is that they are stuck in “list mode” – they mostly treat requirements as a list to be gotten through. Agile has made this even worse – because it doesn’t even know about dependencies and other relationships. But many-to-many relationships, and even squishier relationships than that, are the stock in trade of product managers.
A big part of the job of a PM tool (in addition to keeping useful lists) is to be an offboard memory for me, so I don’t have to make the same decision twice, and if I do need to revisit a decision, I can easily remember what led to the original decision. I’d also like it to help me find the things that I’ve already done some thinking about and enable me to reuse that thinking in the same context or a new context.
So, some of the questions I regularly ask myself, and I’d rather ask my tool:
What I want is the system to recognize patterns, even very simple ones at first, and surface them to me. It has to be non-stupid, but it can be simple. For example, for the various impact areas I discussed last week, there are three potential states: “not applicable,” “ask me later,” and other. (“Other” being the actual description of the impact.) It would be hard to correlate the “other” answers – not impossible, there’s technology for it, but it would be hard. But it’s easy to make use of the N/A and “ask me later” states.
Obviously, “ask me later” means the system should remind me later, at a reasonable time in the future, that I haven’t answered those questions. Just as it might remind me at various points that I haven’t written the value proposition yet, or other things. For the N/A answers – at least it could list out the other features that have a similar set of N/A answers, which might reflect an underlying similarity that can be reused.
Taking that a step further, if I answer N/A for some impact area, that presumably means that the feature doesn’t impact that area at all, which has implications for the cost of implementing the feature. Some areas are costly to make changes to, while others are less costly. So if I get a low estimate for a feature that has an impact in a high cost area, the tool should warn me.
Another analysis of the same situation – if I have a feature that has an impact in a high cost area, I should double-check its rationale for existing – important customers want it, or it’s important to align to market themes, or whatever it might be.
Simply going through a list of features is never going to give me these kinds of insights. And today I have to remember to do all that myself.
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.
Session expired
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.
Thanks for the useful post, and especially the list of questions that it would be great for a tool to answer. I agree that finding the patterns is the essential aspect, and I like how you are bringing the list view and pattern view together here.
Mr Hobbs – thanks for the comment. My constant refrain is that there are things we do as product managers that require us to find patterns, some of which at least the computer could be finding for us.
[…] It is necessary to take some thoughts out of the mind of the product manager and put them into the tool, so he/she doesn’t need to worry about them. Something Nils has detailed in another blog post […]