Market Requirements Documents in an Era of Rapid Change
No matter what form it takes, an effective MRD lays out the following key elements:
- Target markets: market definition, sizing, segments and their relative importance
- Buyer analysis: a review of all types of buyers (economic buyer, technology buyer, using buyers, other influencers) along with their key motivations and pain points
- Competitive analysis: an analysis of the product’s position in the marketplace, identifying key differentiators and competitive gaps
- Selling, partner, and pricing models
Taken together and aligned with overall company goals, these elements should drive you towards a set of release goals and a system to prioritize feature sets. And in a changing, competitive market place, such a system is more important than ever before. This is true regardless of whether your company is on fast-moving SaaS product development cycles or slower, more traditional release processes.
I think that the MRD—not the actual product requirements—is also where cross-functional alignment is most important. This is the time to get critical input on how the product direction fits in with business strategies, sales and channel strategies, etc. – not when you are making individual feature trade-offs.
In an ideal world, a cross-functional product steering committee would meet once a month to discuss market conditions and suggest changes to each product’s strategy. The MRD (or some part of it) would serve as the basis of the discussion. But the process of aligning to strategies and reinforcing product goals is what makes the MRD a living document.
Web 2.0/ collaborative technologies help the MRD process by giving product marketers an easier way to capture market information and disseminate market analysis for feedback. Sales teams could incorporate real-world examples of buyer pains, competitive issues, etc. as they come up in their opportunities. Product marketing could more easily collect data to answer key strategic questions and get feedback on specific assumptions and recommendations. Using collaborative technologies in the MRD process make it more efficient and complete; but none of these technologies can fully replicate the value of an open discussion between stakeholders with different perspectives.
What happens if the MRD changes so much that the product requirements change? Depending on the length of your product development cycles and where you are in the process, the answer could vary from nothing to everything. Of course, rapidly changing markets are one of the main reasons that more companies are releasing products on shorter cycles today. Slower-moving companies still have the ability to make adjustments to mid-cycle – particularly if they have a clear process for what to do and why. It is when you combine a slow product development cycle with anecdotal market information and no change request process that you have a recipe for inertia.
Doesn’t this all sound like Agile software development? Absolutely, yes. But in my experience, companies implementing Agile focus much more effort on the requirements-to-product phase than the market-to-requirements phase. They also tend to focus more on customers/ users and less on the broader market. The process I describe above is in effect the Agile MRD, a way to address these shortcomings.
In conclusion: call your MRD process whatever you like and implement it in whatever way that will fit into your current processes and culture. Just know that this process is fundamental to creating a consistent track record of successful products. And just do it.
Posted on Mon, November 30, 2009
by Linda Sonne