From Market Requirement To Product Requirements

Last week, we looked at an example of market analysis, defining first a market opportunity, and then a market requirement. We wrote an article a while ago about how to go from an MRD to a PRD. In this article, we will look at the journey from our example market requirement to associated product requirements. And thanks, Roger, for throwing down the gauntlet.

Background Perspective

We have shown that the same statement means different things to different people, depending on their perspective. “Improve the handling of that car” could be an implementation or design statement, or it could be a requirement or goal. An executive, faced with market research data could conclude that the best way to penetrate the enthusiast market is by making the car more fun to drive, and would choose to achieve that requirement by improving the handling. An engineer in the automotive design department will sit down to design a new suspension system, or shock absorber, with a requirement – “Improve the handling”.

The difference is perspective. We’ve taken a look at how this affects folks in the software world in our article, …One Man’s Trash.

Recapping Our Example

We’ve identified a market opportunity

Sole-proprietor restaurants are losing over 5% of their top line sales in food spoilage.

And from that, based on our strategy and vision, defined a market requirement

Sole-proprietor restaurants will reduce the amount of food spoilage by 50%, by making better food purchasing decisions.

Finding the Path To Product Requirements

The key to making the next step is in recognizing that this is an ideation step. There are multiple ways to address this market requirement. We have to choose one.

The challenge in creating product requirements designed to address this market requirement is that we don’t want to specify design. [Ed: Here’s an article on the difference between requirements and design]. There are many different ways to achieve the requirement, and not all of them involve products, or software.

Different Solution Approaches

With a market requirement of

Sole-proprietor restaurants will reduce the amount of food spoilage by 50%, by making better food purchasing decisions.

We can reasonably choose any of the following (and so can our customers):

• Change to suppliers with shorter lead times. This allows us to reduce the amount of food on hand at any point in time, thereby allowing us to reduce spoilage. With shorter lead times, we can better adapt to variations in usage by changing the size of our orders. No product or software required. This improved service will come at a cost – increased ingredient prices, and increased process costs (from the extra order-creation and delivery steps).
• Change our ingredients. We could use ingredients with a better shelf-life. Canned tomatoes instead of fresh ones. Frozen chicken instead of fresh. These products would last longer, thus effectively reducing the spoilage. While we would still have the same amount of inventory on hand at any given time, we would reduce the amount of “about to spoil” inventory, thereby increasing our ability to deal with variations in demand. This improved ingredient longetivity would also come at a cost – reduced food quality.
• Change our storage technology. We could start vacuum-sealing all of our ingredients. This would extend their shelf life by changing the “spoilage equation.” This approach also reduces the amount of “about to spoil” inventory, without a sacrifice in food quality or increased food costs. However, this is a product-based solution, with costs associated with the sealing equipment, as well as increased process costs to seal and un-seal ingredients.
• Change our order sizes and frequencies. Simply put, we have spoilage because we order too much food. We absorb this cost to avoid the risk of 86’ing items on the menu. 86’ing would result in lost immediate sales, and lost long-term sales (by losing repeat business). To reduce our order sizes, we have to do it in a way that does not increase our risks.

Ideation

Each of the strategies outlined above involves ideation – we think about the fundamental problem, spoilage, and we devise several strategies for addressing it. As a software vendor, the last option is most appealing to us. We believe that our customers can easily achieve some reduction in spoilage with the first option, and incur some cost along with it. It is a net benefit to our customers, so for any sales that we don’t make, we will encourage them to pursue that – after all, losing the sale does not mean we have to lose the relationship.

Product Requirements

We can write product requirements, combining our market requirement (50% reduction in spoilage) with our strategy (make smaller orders without increasing risk). We will also incorporate a couple constraints that guide our software strategy. These constraints represent our understanding of our target market.

• Our customers will require feedback (on the effectiveness of our software) in order to develop trust and thereby increase usage.
• Our customers will not migrate their entire business process onto our software overnight – it will be gradual.

Given those added constraints, here are the product requirements:

1. The system shall recommend ingredient purchase amounts and timing that would reduce spoilage by at least 50% against the baseline. This is the primary requirement. This is the only product requirement that is directly derived from the market requirement. The remaining requirements are in support of our constraints.
2. The system shall allow users to ignore its recommendations. Without specifying implementation details (does the system automate the orders, does it print out a schedule to support manual ordering, etc), we know we need to allow our system to be adopted gradually.

The Grey Area Between Requirements and Design

This brings us to an interesting place. Consider the next set of statements:

• The system shall create a prediction of spoilage associated with recommended purchases and timing. This is looking at the next level of detail. We propose that making reccommendations to reduce spoilage be based upon predictions of spoilage.
• The system shall provide a prediction of spoilage associated with manually entered purchases and timing. Another detail – we want our feedback loop to apply our calculations to “manual orders”, which would help our customers gain confidence in the software more rapidly.
• The system shall track ongoing food spoilage statistics. Strictly speaking, we don’t need the software to do the measurement for us, but we think that is a good idea. It supports our belief that user adoption is a function of performance validation, and this statement makes that validation process cost less. While our customers may not associate this with a hard ROI estimate, we believe that it does have an ROI impact, based on applying expected value calculations to the anticipated usage of the software.

It is tough to define if these statements represent requirements or design. [Ed: Many individuals will say this is easy to define. But those people will not agree on which definition. Therefore, it is hard]. We admit that using predictions to drive our reccommendations is a design decision. We also believe that the statement provides guidance to software developers about how to approach the solution.

Although we used language patterns that make the statements look like requirements, these statements are actually design. As a validation of that statement, we ask “Can other approaches achieve the same results?” There are many products that are designed for inventory management for manufacturing companies. Those products typically look at minimizing WIP inventory due to the associated opportunity costs of money tied up in inventory. Our problem, while not manifested in the same way, is still the same problem – excess inventory results in excess cost of goods sold. Those products can achieve the same results without predicting spoilage amounts.

Therefore, these are not requirements.

Summary

The market requirement:

Sole-proprietor restaurants will reduce the amount of food spoilage by 50%, by making better food purchasing decisions.

Is addressed through two product requirements:

1. The system shall reccommend ingredient purchase amounts and timing that would reduce spoilage by at least 50% against the baseline.
2. The system shall allow users to ignore its reccommendations.

Additional decomposition of the problem would represent design or could be considered elements of an SRS (which, being a specification, is either design or requirements – depending upon your perspective).