My PM Toolkit and “requirements chaos” posts from last week seemed to strike a bit of a chord. I think I can summarize my key point from those posts:
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.
This includes:
- 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.
Messy, messy, messy! Yes, the job of a PM is filled with the endless messiness involved in integrating the needs, ideas and points of view of many people. It is inherent in the job that we are joining disparate processes and ways of thinking, bridging the gaps among customers, designers, developers, and our internal stakeholders.
I've been thinking about ways to address this since you suggested breaking down requirements that are partially complete into smaller pieces on the ideas forum for Reqqs (ideas.reqqs.com). It's not an easy problem but I think it may be something we can tackle. Stay tuned.
Bruce – "not easy" = good (often)! If it were easy, anyone could do it.
An example of messiness I deal with in reference to: "Decomposing requirements, especially when they are already underway and won’t be 100% completed". We us both PRD and Backlog and thus I must decompose requirements and scenarios listed in the PRD (word) and convert into digestible by developer stories (JIRA). I wish (or is there?) one tool that can do this for me?
Karen – That's exactly the problem I was describing! It's a big pain to have Word in the mix, because it's not multi-user, it's not a central system of record, and it's easy for things to get lost if they get deferred out of a particular release. And then it's up to you and your (fine) mind to keep track of all of it. That was the first thing I was looking for when I made the transition from Word-based PRDs to using Accept360 – the fact that no requirement every just quietly disappeared into an "old PRD" never to be seen again.