Requirements Capture versus Product Specification

In our post on Requirements Capture I looked at how we can go about understanding what a product has to do, who it has to do it for, and how to assess that. The output of this process is often referred to as a Product Specification or more specifically a Product Technical Specification.

 

One way to think of this is that Requirements Capture is a pull process, where as Product Specification is often a push process.

 

I was amused to read Jama Software’s blog on this topic where they show a number of ways to go about writing the Product Specification. My favourite was their description of letting the development team write the specification.

 

We see a lot of this with web development where the web developers want to try a particular tool or technique so they use it for your project whether that is good for you or not. Below is a summary  of the other options and some common pitfalls.

 

Customer Supplied Specifications

If the customer is writing from a marketing perspective or a specific opportunity then you can end up with a very useful Product Specification. But if it purely a sales driven process then you often end up with the following combination:

 

• superset of the features of all other products on the market
• at a price 10% below the cheapest product on the market

 

This generally leads to a project doomed to fail or at the very least puts the product in a price war with a race to the bottom of the market. At the very least, it can put a straight jacket on the product and significantly reduce the likelihood of commercial success.

 

A marketing driven process will determine where in the market a product can be and at what price, for who and a clear strategy for competing with the other offerings.

 

Ask the customer

As Steve Jobs famously said, “don’t ask them, they don’t know”.  This isn’t always true, but the client often doesn’t know what is possible and part of the role of Product Developers is to give good guidance on Technology Selection to give the product an edge in the market.

 

Otherwise, you just deliver what they asked for without caring about their success. I often think this is one thing we offer. We care about the client’s success.

 

Analyse across all constraints

This is the process we try and use.  And it is well captured in this image from Jama Software.

 

 

To be successful, a product should:

 

• be possible and affordable with available technology you can actually buy or deploy
• solve a well defined problem in an acceptable manner
• fit within the constraints of either the manufacturing capability, logistics capability or market channels available

 

The last point is often overlooked. I was recently asked why we couldn’t design a product that cost $20 to make, have the range of a mobile phone, be manufactured in quantities of 100 of on demand, a development budget of under $20,000 and be able to be deployed with no infrastructure costs. This is an example of a wish list that can’t be realised as it is currently expressed. However, when we looked at it from a different perspective, we were able to come up with a solution. The questions we asked were:

 

• why do they want it?
• who do they wanted it for?
• what problem is it meant to solve?
• what is solving that problem worth to the end user / buyer?
• what is the manufactured volume versus unit price trade-off?
• what can it really cost to develop and manufacture and still be profitable?

 

And suddenly the impossible can become possible. In this case they knew their market well. It was just an example of the customer starting with a specification rather than using the resources around them to get to a specification that could lead to commercial success.

 

And ultimately, that is where a Product Specification is meant to lead to: commercial success.

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2015 Successful Endeavours Pty Ltd.