Defining Product Requirements

Developing a product that solves your customers’ problems
(Post 4)

Your customer has needs. You have a brilliant product. But is it a solution to their problem? We investigate how to develop the perspective needed to create a product offering that your target market will immediately recognize as critical to their business. 

It’s key to recognize the distinction between how the target customer thinks about purchases, versus how a product provider thinks about their offerings. Consider the diagram below. The target market bubbles on the left reflect the customer’s point of view: they are thinking about the problems and challenges they face, how to break into new markets, how to improve their business. In contrast, a product provider’s considerations about their offerings are shown on the right: the implementation details of their product, including costs, risks, future enhancements, etc. These bubbles are not the same! And to achieve a solution (and a sale), the seller needs to bridge the gap, making sure the product they are creating and offering to the marketplace is meeting a need in that market.

You’ll notice the target market’s needs are not just your typical “Eureka!” products typically envisioned when we think about a new company. The product offerings could be derivations of existing product offerings, improvements, enablers applied to new markets, behaviors to be changed, and new performance and cost reduction paradigms. The product and services can be quite subtle, from enhancement to an entirely new platforms (more on platforms later). They could be new disruptive technology, or an existing technology applied in a new way to create value. Regardless of the nature of the product or service offering, I break the world down to the “What” and the “How” as shown in the next diagram, or “What” I need and “How” I’m going to get it.

I first started thinking about the “What” and the “How” when I was consulting and working with teams to solve very difficult product and process development problems.  The problem with the material science-based companies I often work with is that the process enables the product, and not the other way around.   They are so tightly linked, there would be no product innovation without constant refinement and improvement of the process and equipment.   The Product is the Process, and the Process is the Product.  This is where I first encountered the confounding nature of the “What” and “How”. 

Engineers, physicists, highly skilled technologists, and other highly technical people always jump ahead to the “How” without fully understanding what the actual problem is and who is the receiver of the problem solving “services.”  Why?  Because problem solving is fun and is what technical people live for.  Their entire professional development has been based on solving problems that are out there, not taking the time to understand the problem that real live customer needs to solve, how to measure the results to make sure the problem is solved, and ensuring the solution is durable and sustainable.  For larger companies, this can be a wasteful practice, but won’t likely put them out of business.  For a startup, at all levels, it can be a disaster, wasting valuable time and resources.

Later, there will be chapters on the nature of technical decision making contrasted to risk.  For now, I want to focus on the value of a startup taking time to understand the “What and How” of their product or service.

Understanding the “What”

Finding the target customer, understanding their market, know the competitors, doing research, and asking the right questions fuel the search for defining the “What”:

Understanding the “How”

Keeping the “What” in mind throughout the development process ensures you will not be searching for a question for your answer later in the game. The “How” questions are very different, but are informed by the “What” of your target market.

Any one of these arrows could be a chapter, or more likely a college course.  But the startup needs to be aware of these factors and constraints that can shape requirements in their decision making.  Some of these topics will be woven into this blog, whereas other are placeholders for future independent research.

And now the “Why”

We want to ensure the highest probability of delivering a product or service with features that customers actually want.  Companies with De-Risk Design and Product/Service Development efforts are more likely to achieve profitability by eliminating money wasting behaviors and have the highest ROI (Return on Investment).  These requirement defining methods help validate the product’s or service’s value through the lens of the people who BUY them, when they have a problem to solve, whether it’s real or perceived.   Lastly these methods Conserve Resources (less spending) by ensuring focused product (service) development based on quantitative analysis and NOT Gut Feel, which saves money in commercialization because there will be less changes in design and manufacturing.

The “What” and “How” defines your Product Life Cycle (PLC) Phase I which will be discussed in the next chapter. And it’s the phase that gets a lot of attention from investors and prospective customers.  The work of thinking about the “What and How” is free, as well as the concepts I’ll be sharing in the next chapter.

If you’re interested in getting templates of Marketing and Product Requirement documents, click on the this link PRD and MRD Content.