I need a tool to help me with all the messy things I do today in random Word docs – I have to do them, but they are messy, and the tools don’t support the messiness.
- Writing and refining value propositions – for products and releases
- Decomposing requirements, especially when they are already underway and won’t be 100% completed
- Writing data sheets, both the benefits portion and the features portion
- Writing and managing release notes
- Writing documentation
- Managing customer meeting notes and their relationship to the things I’m building
Why are these messy? Some of the reasons are: There are lots of many-to-many relationships. There is a lot of decomposition, and then recomposition. There are emergent or combinatorial interactions.
For example, when I write release notes, I often need one version for internal people (the “rude” version) and one version for customers. And for some features or bug fixes I only need one of these, and for some I don’t need either. For some features or fixes, there’s another release note that already addresses them. And there’s a difference between “No release note needed” and “I haven’t written the release note yet, but it needs one.” Does your requirements management tool support any of these scenarios? Mine doesn’t. (Mine is Jira, today, but was Accept360 in the old days – neither handles this level of messiness.)
I could come up with a similar set of messiness generators for all the other items on the list above, and many more besides.
Handling The Messiness – Tool Considerations
Some key points for people building tools, as a metric to see if they are handling messiness. People evaluating tools can use these points as well:
- If a feature seems like “just like I’d do it in Excel, only multi-user with a repository,” then you’re not solving a hard-enough problem.
- If your feature assumes that the process the element goes through is not messy, then you’re not solving a hard-enough problem.
As tool builders (PM tool or otherwise), you need to take Paul Graham’s exhortation to heart – “Use difficulty as a guide not just in selecting the overall aim of your company, but also at decision points along the way … deliberately [seek] hard problems,” (about 2/3 of the way into the article). And conversely, if a problem seems easy, especially in this domain, it may mean you don’t understand it.