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:
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?
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?
Well, we do know there are some things that are problematic with Excel:
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.
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:
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.”
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.
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 […]