![\"Product](\"https:\/\/www.jamasoftware.com\/media\/2019\/05\/the-best-and-worst-ways-product-specifications_1024x512-1.jpg\")
<\/p>\n<\/p>\n
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\u2019t enough time to consider alternative solutions once new information comes into view.<\/span><\/p>\n 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.<\/span><\/p>\n In this post, I\u2019ll first describe some of the common methods used to agree upon a product specification. Then I\u2019ll explore the problems with those methods and how they can lead to building products from a spec that doesn\u2019t actually solve your customer’s problems.<\/p>\n 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\u2019m a consultant here at Jama.<\/p>\n <\/p>\n 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\u2019re acting as a contractor and your customer is responsible for all of the details of the specification.<\/span><\/p>\n Given that this scenario calls for iterating on an existing product, there\u2019s a high likelihood you\u2019ll end up with a very specific idea that you definitely can implement.<\/p>\n However, there are several problems with this approach:<\/p>\n 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.<\/span><\/i><\/p>\n 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<\/span> customer. If you don\u2019t, then you run the risk of building a product they won\u2019t 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.<\/span><\/p>\n 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\u2019t the best approach.<\/span><\/p>\n RELATED POST:<\/strong>\u00a0How to Perform Better Impact Analysis on Upstream and Downstream Relationships<\/a><\/em><\/span><\/p>\n Another common scenario is one where an engineer, or some other customer-facing team member, envisions a solution based on conversations they\u2019ve 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\u2019s efforts quickly turn to writing the product specifications and developing the solution.<\/span><\/p>\n 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\u2014not exploring a need\u2014the discussion tends to be around details in the product spec. These teams won\u2019t have an opportunity to find out if the solution is solving a problem.<\/p>\n Typically, in this scenario, the product requirements come straight from one individual\u2019s 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\u2019t researched nor validated the requirements<\/a>, then the team will build the wrong product. <\/span><\/p>\n What both of the previous approaches have in common is that the focus is on <\/span>getting to a finished product specification as quickly as possible<\/span><\/i>. Teams are in such a hurry to start building <\/span>something<\/span><\/i> and meet the customer\u2019s deadline, they don\u2019t first make sure that the something is the <\/span>right<\/span><\/i> something.<\/span><\/p>\n 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\u2019s 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 <\/span>why <\/span><\/i>they are building this product, and therefore cannot make recommendations.<\/span><\/p>\n 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.<\/span><\/p>\n RELATED POST:<\/strong> 8 Do’s and Don’ts for Writing Requirements<\/a><\/span><\/p>\n 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 <\/span>problem statement<\/b>.<\/span><\/p>\n 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\u2014this is critical\u2014say 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.<\/p>\n A problem statement generally is made up of three parts:<\/p>\n 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.<\/p>\n If you do this successfully, you\u2019ll end up identifying a problem that you can solve and that your customer will pay for.<\/span><\/p>\n During the process, be careful that you don\u2019t 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.<\/span><\/p>\n Let\u2019s go back to our diagram of all possible products that we can build.<\/p>\n This time we\u2019ve 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.<\/p>\n You\u2019ll 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.<\/span><\/em><\/p>\n The idea is to give the design team maximum flexibility<\/strong> in creating the most innovative solution possible within the constraints.<\/span><\/p>\n RELATED POST:<\/strong> Checklist: Selecting a Requirements Management Tool<\/a><\/span><\/p>\n How Do You Get to a Final Problem Statement? <\/strong><\/p>\n Here are my recommendations:<\/p>\n 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.<\/p>\n 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.<\/p>\n The best approach here is to release small pieces of the specification to the team as early as possible to get fast feedback.\u00a0 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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\u2019ll be able to explain exactly what value your product offers and why it needs to have the features that the team has specified.<\/p>\n 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.<\/p>\n![\"1.](\"https:\/\/static.jamasoftware.com\/www\/imports\/2015\/10\/1.-The-Challenge.png\")
<\/a><\/p>\nWorst Ways to Create a Product Specification:<\/b><\/h2>\n
1. Ask Your Customer What They Want You To Build<\/b><\/h2>\n
<\/a><\/p>\n\n
\n
\n2. Have<\/b>\u00a0<\/i><\/b>an Engineer Write the Entire Spec<\/b><\/h3>\n
<\/a><\/p>\nWhy These <\/b>Approaches Don’t Lead to Success<\/b><\/h2>\n
\n
\nThe Best Ways to Create a Product Specification<\/b>: <\/b><\/h2>\n
\n1. Start with the Problem<\/b><\/h2>\n\n
<\/a><\/p>\n
\n
\n\n
2. From problem statement to specification<\/strong><\/h2>\n
<\/a><\/p>\n3. Release the Product Specification in Small Batches<\/strong><\/h2>\n
4. Refer to the Problem Statement to Ensure You’re on Track<\/b><\/h2>\n
Designing Products to Market Needs is Critical to Success<\/b><\/h2>\n
\n
\nTo 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<\/em><\/a>.<\/h5>\n