To MRD or not to MRD ...
The old school product management world we lived and died by the Market Requirements Document. Sometimes, it is worth the effort to create it
That is the question.
In the way back time, before Agile, before OKRs and other fads, product managers wrote MRDs, or Market Requirement Documents. This was the artifact the began the process of developing a new product, or a variant of a product.
Now, the general consensus seems to be that the MRD is dead as the Dodo, replaced by a product backlog, groomed by a product owner, and lean startup techniques that encourage build/test/evaluate/pivot cycles until you achieve the magical “product-market fit” that is the manna from heaven to a modern corp.
And while there is much to the less analysis upfront, more experimentation modus operandi, it isn’t the be-all, end-all of product.
There are times when the old ways really are both appropriate and better.
Why am I bringing this up? A recent project, a complete re-do of one of our flagship products was needed. Without going into details, it sparked a pretty thorough reëvaluation of the whole stack product. The leadership team asked for a formal Market Requirements Document to help their decision process.
Fortunately, in the pre-work for the product refresh, I had spent a lot of time talking to index users, key influencers, internal and external domain experts, and done some historical booking and revenue analysis, and some detailed market analysis (SAM/TAM/sizing/segmentation/affinity analysis) so I had almost all the data I needed at hand to create a true MRD in the style of the old-school.
Oh, there were some challenges. We had gone so long since the last formal MRD that the approved and documented template was glacial in its age. It had last been touched in 2016. Yikes. Had it really been that long since a project had a formal MRD?
Sidebar: We had used an executive summary PowerPoint deck for approvals and stage gates, so there was some process, but those decks are done with less rigor than a formal approved document)
I waded in, relishing the reliving of how product management used to be done. The MRD has an executive summary (done last, of course) and detailed sections on market, market assumptions, forecast pro forma costing of the effort, the impact on other products/groups, any cannibalization effects, what happens if we don’t do it, what it will be, and as important, what it will not be.
Again, not rocket science, but it is all topics and knowledge/research that you – as a product manager – SHOULD know and be constantly researching, validating, and verifying. When you aren’t playing Product Owner that is.
In some ways, it was refreshing, it reminded me of when I was a new product manager, and building the MRD was this scary thing, and it drove me to be super diligent. It drove me to constantly hone my tactics, my skills, and my ability to divine information from a wide slate of stakeholders and external opinion leaders.
Do I think that all efforts require an MRD? No, not at all. In fact, for many programs it is totally overkill. But, I think that there needs to be more MRDs written, and this will help both organizations to get clarity on the “what” they are building, and ultimately to reduce churn in the hunt for product-market fit. Imagine starting 75% correct instead of 15% correct, and how much less churn you will be bringing to the organization.
Oh, and the MRD I wrote for this? I got accolades from the leadership team, kudos for capturing it (trick question, I already had it) and bringing clarity to the effort.
I felt pretty good about it.
