How to Write a Product Feature Set

One of the key benefits of a product feature set or software feature list 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 and 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 make a product. On top of that list of features, you cover your design vision and the technologies that will be used to build the product. It's a good idea to look for a solid product feature list example to use as a reference. 

Why Would You Need This?

We'll see some examples of product feature documents in this post. You'll notice that a product feature set or software feature list is first and foremost used to facilitate 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 its development isn’t easy. While other processes, such as user stories, do a great job of describing the nitty-gritty details of a feature and their technical implementation, a feature set is useful to get everyone on the same page regarding 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 rest. Presenting a feature set to your client before starting the design and development of a product ensures 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 format 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 it easier to talk about the different parts of the product.

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 a 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 to two or three paragraphs. If someone were to 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, you 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 could 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 not very 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 not including 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 on 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 products rarely generate revenue from day one. In fact, most products require significant 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-foot view of your goals. It's now time to get to the nitty-gritty. In the product section, you describe what the plan is in more granular detail. 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 doing this, 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 of 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 to 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, etc.).

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 the functionality of the back end, and describe possible technical challenges for the product.

I'm not a developer myself, so my goal in 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 to 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, 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 back end? 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 based on 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 at the beginning of this article. For most products, there's a grand vision of what you want to achieve and how you see your product growing 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 version 1.1? Version 1.5? What about 2.0?

What's important is that in this section you're merely scratching the surface. As your product gains traction, you'll get insights into how people use your product, and this information will typically affect 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:

Learn More

Now you have all the basics on how to write a product feature set. You can also find some guidance in this Feature Set Template (Google Docs) I've created for you. Get more learning resources in the articles below: 

• How to Create a Minimum Viable Product

  Sven Lenaerts

  03 Oct 2014
• How to Start in App Development

  Arooha Arif

  16 Sep 2021
• Programming for Android: What Language to Use?

  Arooha Arif

  15 Jul 2021
• How to Get Started With an Android App Template

  Ashraff Hathibelagal

  17 Mar 2021

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 writing the feature set of an existing product. It's a good exercise.