Your ‘ideal product concept’ may be ‘not so ideal’ after the product launch. This is often the case when you get negative feedback from customers. The features they get turn out to be not the best solutions for their problems. They may solve them but partly or, in the worst case, be useless.
This situation is often the result of skipping or ignoring one of the most important elements of the pre-planning stage of the project – the development of a market requirements document. Without market research, you get a wrong understanding of the customers’ needs. Very often, the right vision of such needs is just substituted by what you think to be correct.
Of course, professional insight and intuition should not be underestimated. The guesses of a product manager may be right, as a good PM is always an advanced user of the software product. However, intuition may not work. This will result in mistakes in product development.
A product cannot be flawless; minor mistakes are always detected after the product launch and need adjustments. Still, there is always a way to minimize flaws. For this, a market requirements document should be developed. This blog will explain what it is, its purpose, and its structure.
Market Requirements Document. Understanding the Basics
A Market Requirements Document (MRD) is a document based on data concerning the needs of customers. This information is further used to develop a plan to satisfy those needs. An MRD usually contains an outline of the context of a problem and ways of its solution.
An MRD should be developed during the product life cycle's pre-planning stage before giving assignments to the development team.
Only through market research can the co-operation with the development be started. The research involves the analysis of the customers' feedback. A detailed description of the needs of the target market follows it.
An MRD should not be regarded as an isolated document. It is part of all documentation accompanying the product lifecycle. An MRD has an impact on other supporting docs. The most influenced one is a Product Requirements Document (PRD). It is written for the development team and contains direct instructions on how the product must be built, what functions it must feature, and how it must be designed.
A product requirements document is based on an MRD. Part of it actually quotes an MRD – there is a special section in its structure explaining why a customer needs the product.
Structurally, an MRD is composed of three main blocks:
- description of the market size,
- analysis of the customers you are targeting,
- and competitor analysis.
In a way, it is close to the traditional SWOT analysis (the analysis of strengths, weaknesses, opportunities, and threats). It helps understand the product’s position and potential in the market niche.
Strategically, an MRD is needed to answer one fundamental question for further product development: What do customers want? By way of comparison, a PRD is rather about How to build a product that is exactly what the customers want.
An MRD is typical for companies that practice the waterfall approach to the development process. A waterfall approach means every product should go through the planning, building, and delivery stages. An MRD refers to the planning or pre-planning stage and is created prior to the start of the development work.
Actually, an MRD is equally important in an agile development methodology though agile is less sequential and relies more on the collaborative process. Still, an MRD helps to align the vision of the product of all the team members involved in the process.
MRD Structure
To develop a market requirements document, one needs to collect information that will make the context of the problem. The context includes several components:
- The problem itself (problem statement) and its scenarios.
- Personality types (personas) or, putting it simply, people who experience problems.
- The formulation (statement) of the market needs. This may be the hardest thing to do in the whole product delivery strategy, as it implies analysis, synthesis, and generalization skills.
When working on the context, the most important thing is to keep the customer in mind, but the image of the customer is sometimes tough to grasp. A good solution here is to simplify the image. Try and make it schematic, like a drawing. This will make things much easier.
This process is called creating a persona, i.e., an abstract portrait of your customer(s). Don’t try to bring your portrait as close to life as possible; try to single out only the most distinctive features that might help solve the problem.
Defining the following features will help describe a persona:
After describing the possible personas, you can move to the problem scenarios. These are situations that can motivate a persona to buy your product. The scenarios should include the following:
- Goal: What is the goal of the customer? What does he/she want to fix?
- Persona(s): You have to get a clear vision of who is having a problem and is trying to reach a goal.
- Background: The situation in which the customer is trying to solve a problem can be different. This may concern differences in the software installed on the PC (this issue concerns the compatibility of your product with other software), budget differences (here you have to think of different subscription plans for your product), whether your customer is a company or an individual, etc.
- Frequency: Your potential customers will need your product depending on how often the problem happens.
- Cause: What is the cause of the problem? Thinking of the cause will help you to create an MRD (and, later, a PRD) that will help to meet the customers’ needs in the best possible way.
- Extra features: Think of any other relevant features of the problem scenarios that will help to make your MRD more comprehensive.
After making these two steps, you can proceed to describing the market needs. They are usually presented in the following way:
This means that a certain persona (user) must be able to achieve a certain result or solve a problem.
ClickHelp and a Market Requirements Document
Your company may launch new products quite often and have several products at a time on the market. Besides, the more products you have, the more updates they require. This means lots of technical documentation accompanying each product and each update or version.
Writing a new MRD for each update will be too time-consuming. To streamline the technical writing process, you need to introduce help authoring software in your company.
ClickHelp is a tool based on the principles of single-sourcing and content reuse. These features are critical if you want to keep up with the fleeting reality of the IT market. They will save you a great deal of time, effort, and money otherwise wasted on copy pasting.
In practice, it means that you can create a single source of content and then use the content reuse feature to include that content in multiple topics or sections within your documentation. You can also use the single-sourcing feature to generate documentation in multiple formats, such as online help or PDF, from the same source of content.
If you work in an agile company with a focus on teamwork and collaboration, ClickHelp will give you exactly what you want. It will enable several authors to work on the same project. For example, a tech writer (or several writers), a translator (a team of translators), and a reviewer/editor will be able to work on one text at a time.
This will speed up not only content writing but all business processes in your company. In the case of co-authoring described above, creating an MRD will take your team much less time than usual, and you will proceed to create a PRD right away. This will put your product on the market faster than that of your competitors.
ClickHelp makes co-authoring still more effective by allowing all team members engaged in the project to leave comments and replies in online mode. This will enhance cooperation and finally improve the output.
Conclusion
It is true that global companies may be strong enough to influence markets and form customers’ desires. They may start working on a new product because they have their own vision of the market and customer needs.
Such cases are quite rare, though. For most IT businesses, creating a product starts with market research and understanding what customers want. To put research results together and describe the market needs, a market requirements document should be created.
An MRD is essential if you want to understand the needs of your customers and position your product correctly. Only then can you proceed to the next document, a PRD containing direct recommendations to the development team.
Good luck with your technical writing!
ClickHelp Team
Author, host and deliver documentation across platforms and devices