How To Write a Product Feature Set

One of the key benefits of a product feature set is that it helps communicate your product vision with others, such as your team or investors. In this article, I'll teach you how to structure your product feature set and what should be covered in such a document. Along the way, I'll try to convince you of the value of writing a product feature set.

When you start building a product, you have a vision of what you want to achieve. Through a product feature set, you’re forced to make your vision as specific as possible.

1. What & Why?

What is a product feature set?

A feature set can best be summarized as a written document that lists the specifications of a product. It includes the list of features that together makes a product. On top of that, you cover your design vision as well as what technologies will be used to build the product.

Why would you need this?

A product feature set is first and foremost used to facilitate the communication about your product vision. These are a few typical use cases:

• For Yourself: The main purpose is to have a reference document you can rely on and refer back to. It forces you to be specific about what you want to create.
• For Your Team: For teams, it makes an even stronger use case. Getting everyone on the same page about a product during it's development isn’t easy. While other processes, such as user stories, do a great job at describing the nitty-gritty details of a feature and their technical implementation, a feature set is useful to get everyone on the same page of the grand vision of a product. Typically, one person takes ownership of this living document. Usually, that's the product owner. This creates a status quo of what the product is and makes internal discussions with your team easier. In these scenarios, a product feature set is often called a product requirements document.
• For Investors: You have an idea for a product and you’re trying to raise money. A single document covering the product in great detail helps investors understand what your product entails.
• For Your Client: If you work as a freelancer or in a service company, such as an agency, the quality of your communication is often what separates the best from the great. Presenting a feature set to your client before entering design and development of a product assures everyone is on the same page.

A product feature set is a low-cost, highly valuable document that makes communication easier. It sets the tone for a product before it enters development.

2. Requirements of a Product Feature Set

There isn't a standard for a product feature set. I’ve found the following structure works best for me. It covers a variety of topics that define the direction of the product:

• Introduction
• Summary or Pitch
• Vision
• Product Vision
• Design Vision
• Business Vision
• Product
• Information Architecture
• Technical Architecture
• Features
• Product Roadmap

Thinking about each of these individual elements will help you understand your product better. It will make the communication about different parts of said product easier.

3. Let's Start Writing

Enough with the theory, let's write a product feature set. In this article, I provide recommendations for how to write a product feature set. However, feel free to tweak it to your needs and, more importantly, your audience. If the product feature set is solely for investors, then the structure and wording can be different than when you're writing it for yourself.

Introduction

In the first section of a feature set, you start writing the summary of your product. In the summary, you set the stage for the rest of the document. This should be short and sweet. Try to stick within two to three paragraphs. If someone would glance over the summary, they should know what the value proposition of your product is.

Let’s say you're writing a summary for Snapchat, in the early days of the product. The summary could be something like this:

Vision

In the vision section, we focus on the bigger picture of different aspects of your product.

Product Vision

In the product vision section, you have the opportunity to explain the bigger picture of your product. The best products all originate from an MVP or minimum viable product. If you're not sure what a minimum viable product is or you’re wondering how you can scope one yourself, you can read this article.

The product summary should explain your MVP. In the product vision, you describe your grand vision, what is the ultimate goal of the product?

Compare product development to climbing a mountain. Your MVP—the product summary—is your first stop on the mountain during the climb while the product vision is the summit.

Let's take another example, Facebook. Their product vision could have sounded like this:

Design Vision

If you're a designer, I’m certain that you have a direction in mind for the user experience as well as the user interface. You might have a design style in mind, for example Material Design, or you can mention a number of products you really enjoy in terms of their user experience. This is what you cover in the design vision of your feature set.

For someone who's a lot less familiar with design this might be a difficult section to write. If you can’t think of much more than "clean, easy to use", then I'd recommend to not include this section in your feature set.

A product's design is important. If it's not part of your skill set, then I strongly recommend seeking advice from a product designer.

Business Vision

Of course, the business model of the product is covered as well. There are plenty of monetization routes available to you, ranging from freemium and advertising to a subscription-based model. This is an important and broad topic that requires a separate article.

In this section, you describe how you plan to get a return of investment from the product and how you would define it as "successful". Depending on the product's goals, it might not even be revenue, but creating impact in a marketing campaign for example.

Remember that most products rarely generate revenue from day one. In fact, most products require significant of traction before they break even. This is especially true for freemium and advertising focused products.

Monetization for each product is different. Sometimes it's better to focus on user traction and sometimes it's better to focus on the monetary aspect of your product. It's a decision you have to make.

Product

Awesome. We’ve covered the 10,000 feet view of your goals. It's now time to get to the nitty-gritty. In the product section, you describe more granular what the plan is. You define all the moving pieces of the product.

Information Architecture

First of all, the information architecture of the product needs to be defined. By defining the Information architecture, you structure a product to support usability and discoverability.

In your feature set, the goal is to list the different flows of the product. This provides a good understanding of how big—or small—the product is. It helps people understand what features the product contains. It also answers the question how a user navigates through your product.

The following outline is an example of an information architecture for a simple dating app:

A great exercise is to try and map a large, existing product. For example, if you do this exercise for Facebook, you will realize that there are a lot of moving parts (events, groups, pages, advertising, …).

Technical Architecture

If you have a technical background, providing some high-level technical notes is recommended.

Personally, in the technical architecture I like to list APIs I plan on using, describe functionality of the backend, and describe possible technical challenges for the product.

I'm not a developer myself so my goal by defining the technical architecture is to be able to start a discussion with a team of developers.

The goal is not to make final technical decisions, but rather have a conversation about the underlying technology and how it affects the product.

Here's an example of a technical architecture from a feature set:

Features

The features section is the most important section of your feature set. In this section, you describe the features of the product in greater detail.

You might wonder how much detail you should add? When a designer is able to design the user interface of the product based on your feature set, then there's enough detail.

In essence, describing a feature means describing the different elements to make that feature work. What logic is required on the backend? What elements does the user interface need to have? How can I navigate between different flows? These are some questions you can ask yourself when writing the product's features.

Here's an example of a home feed that lists event invitations:

Product Roadmap

The goal of your feature set is to focus on the minimum viable product as I described in the beginning of this article. As for most products, there's a grand vision of what you want to achieve and how you see your product grow in terms of features. This is covered in the product roadmap.

In the final section of the product feature set, you cover the future of your product.

What features would you possibly want to develop in a version 1.1? Version 1.5? What about 2.0?

What's important is that in this section you merely scratch the surface. As your product gains traction, you get insights into how people use your product. This information typically affects your product vision. Your product might get used in different ways than you imagined.

Here's a brief example of how a product roadmap could look for an MVP of a fitness product:

Conclusion

That's it. In this article, we've covered how you write a product feature set. Now it's your turn. The only way to truly learn how to write a feature set is by actually writing one.

If you don't have a product you're working on at the moment, I recommend to write the feature set of an existing product. It's a good exercise.

Questions? Let me know in the comments or on Twitter.

Resources

• How To Create a Minimum Viable Product
• Feature Set Template (Google Docs)