by Product Specification
A product specification (also referred to as “product specs”) is a document with a set of requirements that provides product teams the information they need to build out new features or functionality.
A product specification is a strategic document with requirements aimed to provide product teams with the data they need to develop new product features. It is also known as Product Specs.
An effective product specification gives team members relevant context about business needs, potential customers/ users, and other useful criteria that help them make right decisions as they design solutions.
Product managers will agree that a well-written specification should contain clarity and transparency. The more information you add to your spec, the more clarity you’ll give the team working on the product.
A good product spec doesn’t micro-manage product development. Rather, it gives them relevant context about users, business needs and other criteria to help them make informed decisions as they design and build a solution.
What goes into a product specification?
Product specs don’t have be long or overly technical. In fact, the most effective product specs are actually pretty brief.
You know your product spec has done its job when it answers the following questions:
- What are we building and why?
- What should the final build achieve?
- How do we measure success?
How to write a product specification?
- Define the sources of problems.
- Use customers’ feedback.
- Determine and evaluate requirements.
- Break a specific problem down into hypotheses.
- Add the pages/screens with all the features if needed.
- Arrange discussions across your team if needed.
- Add user testing with your closest customers.
- Simplify the document.
- Send the spec to development.
Establishment of Specifications
- 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.
- 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.
- 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.
- 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.
