Let’s imagine building an electronic product from scratch. You start with a product concept that you think is cool and can solve some issues to make the world a better place to live. Then, you leverage an evaluation board such as Raspberry Pi or Arduino to build a working prototype to validate if your product concept can effectively solve the problem.
That might be sufficient if you only do this for fun or as a hobby. But if you are serious about making it a business, the reality is you are still miles away. The shortcut? Start working on your MRD and PRD as they are part of the necessary steps to bring your product from concept to commercialisation. This article takes a deep dive into what they are and prepares you to create one for your project.
Market Requirement Document
MRD or Market Requirement Document details the business plan of your project. In simple words, it should answer the questions: whom will you sell your product to, at what price level, and how? These are the critical questions you must ask yourself in order to evaluate the marketability of your product.
The MRD will also be crucial in proving to potential supply chain partners that your project is worthy for them to invest their engineering resources into, or, at a later phase during fundraising, to demonstrate to VCs that your product has a good chance of achieving product-market-fit. It should be a live record for your team to document and update as your research deepens with more market insights. Below are the items that tend to be included in an MRD:
Pain point: It would be best to start by setting out the nature of the problem or users’ pain points you want to address. While it is helpful to have your own observations, conducting interviews with people facing the problem enriches your understanding through their experiences and whether having the product will solve it. Your interviewees are the best advisers on recommending functions to incorporate into the product’s concept. You should also come back to them at various project phases for feedback, such as when testing a working prototype.
Use-case: This part explains how your users will adopt your product to solve their pain points from a user perspective. You need to emphasise who does what, in what scenarios, and to fulfil what objectives, as detailed as possible. When working with a product development firm in the project’s early stage when the product’s functions are not fully defined, you will need to explain the use-cases thoroughly so the firm can propose a product design that fits your criteria. Also, having a clear use-case description helps you prioritise what functions will be critically needed for the product and what can be listed as good-to-have. This prioritisation is beneficial when working on a limited budget with a defined threshold price-point for the manufacturing cost. As a rule of thumb, the more complicated a product’s functions are, the more electronic components will be needed to build it and, hence, the more expensive the manufacturing cost will be.
Target audience: Based on the analysed pain points and interviews, you can create several personas of the potential customers you think will find your product valuable enough to be willing to pay for it. Try to be as detailed as possible in describing their attributes, including age, gender, occupation, income level, lifestyle, or what kind of company they are running if your product is for industrial applications. Visualising who would become your customers is the first step towards understanding whether your product concept has business potential. If you can’t think of any, you should scrap that concept and go back to the drawing board.
Market scope: Once you have a clear picture of your product’s potential customers, you can estimate what the market size will potentially be, given their demographics. For instance, there might be existing reports or statistical datasets on the topic to give you an idea of the market’s size. This approach helps you determine if there is a good customer pool in place to justify your investment in developing and manufacturing the product. Hardware development is costly.
Competitor analysis: Now that you understand your product might have a decent number of potential customers, you need to be realistic about it. There will always be competitors with functionally similar products in the market. It is worth the effort to do comprehensive research to understand them better. Who are they? What are their advantages? What is their product’s MSRP? What are their sales channels? Based on the findings, you can conduct a SWOT (strengths, weaknesses, opportunities, and threats) analysis to assess whether your product will have a good chance of out-competing them.
What is essential here is their pricing strategy. While it is challenging to decide on a suitable MSRP for your product at the project’s early phase when the manufacturing and marketing costs are unknown, you still need to take an educated guess to determine a reasonable price range based on the competitor price comparison. This will then give you some insight into what price level potential consumers would find satisfactory, which serves as a reference for setting a cap on your target manufacturing cost when placing RFQs with manufacturers.
Business model: A business model determines how you make money through your product. It is about how you will sell it, through what type of sales channels, and under what pricing strategies or charging models. For example, considering a consumer-oriented product like a smart home appliance, you can partner with existing business-to-consumer sales channels with a readily available pool of customers. Suppose the value proposition of your product is focused on the convenience generated through the use of data, like an IoT smart farming device. In that case, you can consider adopting a subscription model to charge your users a fixed fee per usage period. Different vertical industries often have distinct distribution routes for optimised sales activities. You should spend an equal amount of time, if not more, on crafting your business model as on your product development. Remember, even a perfectly designed product has to be retailed at the right price through the most suitable marketing strategies to gain traction with the target customers.
Product Requirement Document
Let’s move on to PRD or Product Requirement Document. Unlike MRD, which focuses on the business side of the project, PRD details everything about the product you want to build. It should be the master file consolidating all the finalised functions and specifications of the product, synchronised across your engineering team. When going for RFQ, this file will contain most of the product information a product design firm or contract manufacturer needs to understand your product concept and prepare a quotation for you. Below are the items that tend to be included in a PRD:
Product features/functions: The PRD should contain a breakdown of the product’s functionalities necessary to achieve the purposed use-cases. Take a wearable healthcare device, for example. You should explain its required functions, such as what vital sign data will be collected through the device. If you want it to connect to a cloud server for data analysis, you need to detail what type of wireless connectivity would be preferable to use. This is also associated with how long you want the wearable to operate on a single battery charge, as some wireless protocols are more energy-efficient than others but have restrictions depending on what internet infrastructures are available locally. The device’s operational time depends on the size of the battery, which, again, is interdependent with factors such as what kind of design and dimensions you want for your product. You see, almost all the functions are linked with each other. That is why you need to prioritise them in case of potential trade-offs if there are conflicts between the required functions, such as a compact product design and long battery run time.
Specifications: The PRD should also contain technically detailed information about the product based on the functions you listed. This includes items like the electronic and mechanical capabilities, compatible software, and the certifications obtained for the product. This part may not be fully defined at the beginning of the project as your engineering team, or your contracted product development firm needs to design the schematics and PCBA layout and select the necessary components first. Upon finalising the product design, the specification listed in the PRD should be the same as the information on your product package or other promotional materials.
In summary, MRD explains the product’s sales and marketing plan based on your market research findings. PRD documents all the use-cases underlying how the users would interact with the product, what functions the product performs to fulfil it, and the required technical specifications that enable the functions. Together, they work hand in hand to systematically outline the scope of your business and the product you want to build, helping you to determine whether a product concept has commercialisation potential, to sell your idea to investors, and to effectively communicate your business plan with supply chain partners.
If you have completed your MRD and PRD, and are ready to engage with supply chain partners, TECHDesign can help to find the most suitable suppliers for your product requirements. Or if you need help with your MRD or PRD or with your hardware development in general, please don’t hesitate to reach out to them for help!
