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:
- Capacity management
- Value proposition
- Competitive positioning
- Customer satisfaction
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.”
A simple first step is to stop using "files" and start using cloud documents, editable or accessible by multiple collaborators on any device. I've been using Google docs, sheets, slides, and drawings for years. Also, LucidChart.
These types of tools provide product managers and teams plenty of ways of capturing and conveying market learnings, product strategy, design concepts, and the context, details, and rationale for product decisions.
Sorry for the delay Roger. Thanks for your comment. I agree, you can do what you suggest, and it gets you over some parts of the frustration with Excel – such as support for rich text, and a somewhat better solution for multi-user.
But It doesn't help much with the whole "relationship" thing. For example, I would imagine it's still challenging for you to get a list of all the requested features for a particular customer that are NOT desired by the "lead" customer for a release. (I.e., the features that customer has requested that probably won't be done because the most important customer doesn't care about them). In a lot of (non-PM) systems, that type of list is available via a simple query. And I could easily do that in Accept360, and it was very powerful. The query I suggest above is simple compared to what can be done if you have a system that understands the relationships and lets you query over them.
Nils, I haven't ever needed to perform the query in your example, but it would be a pretty simple structure and formula in Google Sheets. Definitely open to new ideas, though, and looking forward to your next post.
[…] got a couple of great essays in the hopper (I know I promised a followup on why Excel is not great for product managers), that will be baked soon, I […]