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:
- Summary or Pitch
- Product Vision
- Design Vision
- Business Vision
- Information Architecture
- Technical Architecture
- 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.
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:
|With Snapchat, users are able to send private messages to each other. The private messages are in the form of photos taken by the user in real time. The user can select the amount of time the receiver is able to view the photo.|
Through our product, we would like to bring back privacy to conversations, both between friends and strangers. The target audience mainly consists of men and women, between the age of 16 and 30.
By using private photos as the main method of communication, we expect short bursts of product usage. The user generated content will be of lower quality as it is aimed at a single person. This goes against the current status quo of the industry, which is curating content for a large audience, such as Instagram or Facebook.
In the vision section, we focus on the bigger picture of different aspects of your product.
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:
|Initially we want to focus on connecting college students at local colleges. Ultimately, we want to empower all people to connect with their friends, family, and strangers.|
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.
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.
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.
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, …).
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:
|List of APIs:|
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:
|The home feed consists of a list of events. Each list item contains a title and a date. The list is sorted by date, the most recent events are displayed first. The list only shows current and future events, events in the past are no longer visible. Events the user has created have a visual indicator. Should a user not have any invitations in their home feed, then they will see an illustration plus copywriting with a call to action to create an event.|
The home feed has a top navigation bar. In the top navigation bar, the user can navigate to their settings or create an event. The user can tap on an event to see the event detail screen.
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:
|1. Connect with Others|
One of the possible next routes for the product would be starting the integration of being able to connect with others. We would build a social layer on top of the user profiles.
Possible other features are an activity feed, the ability to friend other users, finding a personal trainer, and the ability to message other users.
2. Web Integration & Profile Sharing
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.