The Best and Worst Ways to Create a Product Specification

One of the biggest challenges product development teams face is simply how to decide what product to build. In the case of teams that work from a product specification, particularly in hardware development, engineers are typically not allowed to start working until it is completed and approved. And given that most development timelines are incredibly short, there often isn’t enough time to consider alternative solutions once new information comes into view.

One way of looking at this challenge is shown here. You can imagine that the circle is every possible way the team could build the product. And that tiny blue dot is the specification for one particular product. This product spec defines exactly which product the developers should focus on and build.

In this post, I’ll first describe some of the common methods used to agree upon a product specification. Then I’ll explore the problems with those methods and how they can lead to building products from a spec that doesn’t actually solve your customer’s problems.

I should say that my perspective comes from 10 years of experience working in the analog and mixed-signal semiconductor industry, first as an applications engineer and later as a product definer. Now, I’m a consultant here at Jama.

Worst Ways to Create a Product Specification:

1. Ask Your Customer What They Want You To Build

One way to start is to ask your customers what they need. This could be done by waiting for a request for quotation (RFQ) issued by the customer, or less formally, through meetings and discussions. Typically what you will learn with this approach is what solution or product they are using today and what they would like to see changed in the very near future. In a way, you’re acting as a contractor and your customer is responsible for all of the details of the specification.

Given that this scenario calls for iterating on an existing product, there’s a high likelihood you’ll end up with a very specific idea that you definitely can implement.

However, there are several problems with this approach:

What your customer is telling you about their product strategy they are also likely telling your competition, and a key goal of the project is probably to make something cheaper than the existing solution. You will find yourself in a price war.
Your customer already is set on a type of solution, based on what they’d bought before, which makes it difficult to suggest anything that may better meet their needs.
The schedule is likely extremely aggressive, leaving little opportunity to build anything new, or allowing for true innovation.
Your customer may not be aware of new technologies, or they just may not know what they need.

In this case, you are relying on your customer to translate their internal requirements into a specification for you, rather than you writing requirements for a product that the broader market needs and will buy.

As you develop the product, your team will inevitably have to make trade-offs for various reasons. The only way to be sure that the best choice is made is to review changes to the resulting product spec with your customer. If you don’t, then you run the risk of building a product they won’t accept. But because the design team will be under extreme pressure to execute on an aggressive schedule, there is a strong chance they will make product trade-offs without all the best information. This further increases the risk of building the wrong product.

This approach works in that a product is delivered. If you are in the business of delivering commodity components, then this is fine. If you are looking for a unique solution that defends gross margin, then this isn’t the best approach.

2. Have an Engineer Write the Entire Spec

Another common scenario is one where an engineer, or some other customer-facing team member, envisions a solution based on conversations they’ve had with one or a few customers. The team rallies around this idea, and with a rush of internal momentum the requirements are quickly documented and the team’s efforts quickly turn to writing the product specifications and developing the solution.

Once a solution is complete and ready to go to market, some teams will validate their idea with customers, but since the team is presenting a solution—not exploring a need—the discussion tends to be around details in the product spec. These teams won’t have an opportunity to find out if the solution is solving a problem.

Typically, in this scenario, the product requirements come straight from one individual’s head and are then captured in a lengthy spec sheet, and the rest of the team transacts using the documented specification. Any time the team runs into a conflict where a trade-off must be made, the individual who authored the requirements has to decide the correct trade-offs independently, with little or no new information. In addition, if that person hasn’t researched nor validated the requirements, then the team will build the wrong product.

Why These Approaches Don’t Lead to Success

What both of the previous approaches have in common is that the focus is on getting to a finished product specification as quickly as possible. Teams are in such a hurry to start building something and meet the customer’s deadline, they don’t first make sure that the something is the right something.

In addition, the knowledge of the requirements exists with just one individual on the team. That individual is either the person interfacing with the sponsor customer, or it’s the person who came up with the product idea. In either case, the rest of the team is lacking any context for the solution, the why they are building this product, and therefore cannot make recommendations.

The outcome is often products get killed later than they should have, after much time and money has been wasted, or teams create products that are unsuccessful or me-too products that compete largely on price. None of these are good for business.

The Best Ways to Create a Product Specification:

1. Start with the Problem

The best way to build products your customers will buy is to get out there and talk to your target market long before you start writing your specification. First, you need to articulate your problem statement.

A product problem statement is a few sentences or paragraphs that describe a market need. They are written from the perspective of the persona that has the problem and—this is critical—say nothing about how to actually solve the problem. The goal of this stage in the exploration is to convey an understanding of the problem and a sense of the value associated with solving it.

A problem statement generally is made up of three parts:

The first is the persona, or a description of who has the problem. It is helpful to describe the persona in great detail separately and then reference a particular persona in the problem statement to keep from repeating the same persona description.
Next is a description of the problem. The more detail the better here. You want to make sure that the need is crystal clear. Also, give the problem a name. This makes it easier for teams to refer back to it during the project.
Finally, write a description of how often the problem occurs. If the problem happens rarely and has low impact, then solving it is of low value. If the problem happens frequently and has high impact, then the value of solving it will be high.

You can start by asking customers what problems they have that they think you can solve, but you have to dig deeper to get to the truly valuable problem statements or golden nuggets. These golden nuggets generally come from developing a deep understanding of the market and piecing together information from a wide range of sources.

If you do this successfully, you’ll end up identifying a problem that you can solve and that your customer will pay for.

During the process, be careful that you don’t run into false positives or negatives. Listening too much to people inside your company or only a small number of customers can lead you to falsely validate or abandon a problem. Talk to as many customers as you can and collect as much data as possible.

Let’s go back to our diagram of all possible products that we can build.

This time we’ve added intersecting lines that represent constraints. If we think of problem statements as lines crossing the circle, then a good problem statement grounded in market understanding will bound an area in the circle that represents all the acceptable solutions. Anything in this area solves the problem and would be acceptable to the customer.

You’ll notice that the size of this area is far larger than the previous RFQ and product idea circles. This is because these problem statements and context intentionally bound the solution as loosely as possible to allow for new ideas to come forward.

The idea is to give the design team maximum flexibility in creating the most innovative solution possible within the constraints.

How Do You Get to a Final Problem Statement?

Here are my recommendations:

Start by assigning someone for each project the responsibility of being the voice of the customer.
Next, task that person with identifying the market problems solely based on information gathered from the market.
Ensure those market problems are documented and shared in a place that the entire team has access to.
Write down a justification for each market problem statement that explains why it is a problem and how important it is to solve
Add a milestone in the project plan where the problem statements must be reviewed and approved by the team along with a business case.
As the team starts developing a solution, periodically return to the list of problem statements to remind everyone what the target is.
For each problem, capture a list of the product features that will solve the problem.
If any problem can’t be fully solved, re-review the business case to ensure the product is still viable.

2. From problem statement to specification

Now that you have your problem statements and the team has become familiar with them, start collaboratively developing a product specification. Since everyone on the team understands the problem being solved, everyone can contribute to the specification.

Because you’ve done the upfront work of identifying the problem you’re solving, within identified constraints, and your team has considered multiple ways to deliver the solution, you have enough information to write the product spec.

3. Release the Product Specification in Small Batches

The best approach here is to release small pieces of the specification to the team as early as possible to get fast feedback. This will help avoid wasting time going down the wrong path and will make it much easier for the team to provide high-quality feedback.

Not convinced? Consider this: What happens if you receive a 200-page spec sheet to review? You probably look at the first few pages and then skim the rest.

Now, what happens if you receive a one-page document? You probably review the whole thing. Two-hundred one-page documents will result in much better feedback than a single 200-page document.

4. Refer to the Problem Statement to Ensure You’re on Track

Also, as you develop the specification, check back to make sure that the product is still a valid solution to the problem. It is easy to get caught up in the trade-off inherent in developing a product and forget to check and see if you are still on target.

This approach also manages the expectations of your stakeholders. As the process is controlled, there is a framework and transparency that prevents anyone from overriding decisions. At any point in the project, you’ll be able to explain exactly what value your product offers and why it needs to have the features that the team has specified.

Designing Products to Market Needs is Critical to Success

I recognize that in some industries this is a big change from how products have been designed and built. But as markets get more competitive, and products grow increasingly complex, just delivering another iteration of something you’ve built before isn’t going to keep you in business for long.

To learn more about how to write requirements in a way that all stakeholders have a clear understanding of development needs, download our eBook, Best Practices for Writing Requirements.

READ THE EBOOK

Author
Recent Posts

Adrian Rolufs

System Architect at NXP Semiconductors

I love standing at the intersection of market need, project execution, and engineering to develop successful product. Over my career I have focused on this space both as a team member and a consultant, primarily in the semiconductor and automotive industries. I have spent hours in the lab eliminating click-and-pop in audio circuits, travelled the world lecturing on requirements management best practices, and transformed corporate product development methodologies.