Functional requirements template in Excel (Image by IvanWalsh.com, CC 2.0 license)
As PMs we know that we should “write things down” instead of trying to keep them all in our head. (Even PMs’ heads are only so big.) We have a few choices for this:
- Use a tool we already have on the desktop (Excel, Word)
- Use a tool that is really for something else, but might work (Jira, a wiki)
- Use a tool that’s designed for product managers
Mostly, product managers choose #1, ending up with Excel for requirements management, but they are frustrated – “There must be a better way.” So they evaluate the tools meant to replace Excel for product managers, but remain frustrated. Why?
We Love Excel – To A Point
Excel is incredibly good for lists of things, and at first glance, requirements seem a lot like lists. Indeed, for a lot of companies, most of the requirements are one-liners – often called “tweets”- and so they fit into an Excel list well.
And Excel – for lists anyway – is easy to use. It’s easy to add a new item, it’s easy to “improve” the schema by adding a column. You can color the cells in a spreadsheet easily, either ad hoc (i.e., making a row red so you remember to do some work on it later), or via a formula (i.e., making all the requirements that are 30 days from scheduled release orange). It has sorting and filtering built-in. What’s not to like about Excel?
The Problems With Excel
Well, we do know there are some things that are problematic with Excel:
- It’s not multi-user. It’s hard to have multiple people making changes to the requirements, or, honestly, to have multiple people reviewing the requirements. This can be partially addressed by putting the spreadsheet into the source control system, or by putting it into Sharepoint, but we all know that’s pretty much of a hack.
- Excel doesn’t do well with lots of text, especially if it’s formatted. Once your requirements become more than just “tweets”, you often have to put that information into another system, whether it’s a Word doc or a wiki or whatever. Of course, it’s easy to put a link to that rich content into your spreadsheet, so as long as referential integrity is maintained, that’s not too bad. Just another hurdle to jump over, but it’s not very high.
Requirements Are Not Lists
But the bigger problem with Excel, from a product manager’s perspective, is not related to those two issues, important though they are. It’s that intrinsically, requirements are not really lists. They are really nodes on a “graph” – that is, they are things that have relationships to other things. And those other things can be both requirements and entities like customers, marketing themes, strategies, competitors, and all the other things in the product manager’s conceptual world.
This seems theoretical, except that all those other things impact critical product management activities like:
If your tool doesn’t support those relationships then you have to keep them in your head. That’s difficult, and it means your cognitive resources are not being used as productively as they could be.
Excel sees the world as lists, but the nature of the product management “schema” is that it’s a graph.
So Why Not Use A PM Tool?
Given all this, why don’t more people choose the third option for “writing things down” – the product management-specific tool? Well, there’s a good reason. Although most product management tools address the first two problems with Excel:
- Multi-user support
- Support for rich content
Unfortunately, just like Excel, they see the world as lists, and don’t know about the graph. That’s a big problem. You’re no better off than you were with Excel.
I’ll talk more about this problem, and give some concrete examples, in my next post.
For another take on this, check out Anders Lindorf’s recent post on the SensorSix blog about “How to Replace Excel As the Product Management Tool of Choice.”