Getting Your Product Out the Door: Writing Requirements

Detailed templates and tips

Knowing what your customer wants in a product and getting that vision built are two different things. The bridge between product idea and product delivery is one built with meticulous detail, clear communication and disciplined trade-offs.  You understand your role as a product owner and communicate effectively with IT, so what else is necessary?  The plan.

This is the fourth of six serialized sections of Getting Your Product out the Door: Writing Requirements. It provides of the tools you need to document product requirements, and tips, examples and best practices for using them.

Puzzle Pieces


Endless pages of requirements and hours of meetings, and the product still doesn’t look like you’d hoped.  When you’re new to product development, such setbacks can seem daunting, but they can be overcome – even avoided completely. How can you frame your customer’s needs in a way that enables IT to build what you need, on time and within budget?

Getting Your Product out the Door: Writing Requirements is the fourth article in a six-part series compiled by product owners with decades of experience in creating and launching successful subscription products.  The series is full of specific tips, checklists, examples and tools as well as best practices and foundational knowledge that will help deliver the requirements engineering needs to deliver a product that meets your subscribers’ needs.

This series is written with the beginner in mind.  The content is explanatory and foundational, designed to give someone new to product leadership the practical tools necessary to help an engineering team build the product in a timely and efficient manner.  

Product SealGetting Your Product out the Door: Product Development Basics – Writing Requirements

The Elements of Product Requirement Documentation

There is no right way to organize and create the documentation necessary to deliver a good product.  Some organizations opt for very detailed business requirements, others have done away with them altogether in favor of user stories and wireframes. A few never create requirements at all, but rather iterate with verbal instruction or using bug-tracking software to document back-and-forth discussion on changes.  The critical point is to have a process and use it, so that you and your teams aren’t bogged down by confusion over who does what.

In part three of this series (Getting Your Product out the Door: Working with IT), we reviewed the Agile, Waterfall and other methods of new product development.  Developing a new product is a de-facto Waterfall process: an initial version of the product has to be created in its entirety in order to deliver something meaningful to the market. However, most product development proceeds in an Agile or hybrid-Agile environment.  That is to say, as you continue to enhance your product post-launch, you’ll likely segment your product feature enhancements into meaningful chunks of work that can be released on a frequent, ongoing basis throughout the year. As a result, this article incorporates the key elements of requirements for both Waterfall and Agile development processes.

These are:

  • The Customer Persona: who are you trying to serve?
  • Statement of Strategic Fit: how does this product relate to our overall company goals?
  • Statement of Customer Need: what is the problem we’re trying to solve?
  • Themes, Epics and User Stories: how is the user going to interact with the product?
  • Business Requirements: what do you need the product to do?
  • Wireframes: what should the product look like?

The following paragraphs detail each of these steps.

“The only way to guarantee bad decisions is to make all of them yourself.”  Agile Process Proverbs

Customer Persona

PhotosWhat Is It? 

The customer persona is a generalized description of your ideal customer. It brings your market research and customer knowledge to life in the form of a story that includes all the meaningful information about the overall market and why they want your product.  While the customer persona is representative of overall market need, it is presented as the story of an individual with a name, photo and demographics attached to bring it to life.

Ideally, you’ve already created a set of customer personas from which you can choose to illustrate the overall motivations of the market.  If not, it’s important to do so now, but what information should you include?

The Customer Persona Checklist

You can use the checklist below to not only build customer personas, but to guide you in performing the market research needed to do so.


Found Where?



Persona Image Paid photo sites such as Shutterstock, public image-search sites such as Bing and Google Images Any photograph of a person that reflects the characteristics of your customer persona (i.e., female around age 35 who enjoys South American travel). While persona documents are generally not used for commercial purposes, you should still be very careful about copyright. If you use an image from a free site, make sure to sort by License = Free to Share and Use.
Persona Name Choose any name; a fun way to select a name is to check the Social Security Administration’s “Top 5 Names” list for the year your persona would have been born. Amanda is a good name from 1985. Do not use movie star or other real names, even internally.
Persona Demographics Based on market research. Age, race, sex, political affiliation, geography, education, income, etc. Be wary of making assumptions when including demographics; gather as much actual data as is feasible.
Job Demographics Based on market research. Job title, functional area of expertise, type of business, seniority. Job information is important even if your relationship with the subscriber is based on their personal interests. You may use career-specific references, images or examples in your content or advertising, for example.
A Day in the Life Extrapolated from the facts in the data and your experience with your customer base. “Amanda just got back from Brazil, where she spent a week tasting wine and exploring historic sites.” This is the story that will bring your persona to life.  Be accurate, but have fun with it!
Goals Based on market research. “Amanda is always looking for new South American wineries to explore – this is her main reason for travelling to South America. She wants to visit any new winery and know what’s going on at the established ones.” Highlight goals that pertain to your product, while also giving a sense for how essential – or optional – your product is to your customer.
Frustrations Based on marker research. “Amanda is really frustrated that she can’t find winery reviews from women her own age, and also wishes she could add her own comments directly to the reviews she does find.” As with goals, highlight not only the frustrations, but their relative importance.
Tactical statement Within your strategic plan and product goals. “We’ll meet Amanda’s needs by offering young-female winery reviews and allowing her to sort reviews by age, gender and date of last visit.” This is the area where you respond to the needs of the customer with a product offering.

Who Helps Create It?

While your organization may be different, customer personas are most often created by the marketing team.  They should, of course, gather information from your sales and customer services teams, external demographic sources and, of course, the customers themselves – and you! But the responsibility for putting the actual materials together is most commonly in marketing’s camp.

What Does It Look Like?

The richer the detail on your customer persona, the easier it is for others to use it when they make decisions about the product. So – tell a story, and use specifics. Here are some examples of customer personas:


TIP:  Start with one persona and grow from there. The goal is to create only those personas that make decisions about your product differently.  For example, if the 35-year-old female travel enthusiast makes her buying decision in roughly the same way as the 60-year-old male travel enthusiast, then there’s no need to create two personas.  However, if your market research shows that one chooses based on subscription price and the other on coverage of China, then two personas make sense. 

Statement of Strategic Fit 

What Is It?

A statement of strategic fit is a short explanation of how this new product fits into the overall vision of your company.  Short and to the point, this statement provides context to the team so they understand how the work they’re embarking on is important to the company. 

Who Helps Create It?

This is something the product owner will create, and then vet with senior management to make sure it’s accurate.  Ideally, this statement becomes a talking point that the executives themselves will use as they update the organization in their own status reports.

What Does It Look Like?

A statement of strategic fit need only be a sentence or two, and include the product being developed, its purpose, when you hope to deliver it and what stated goal of the company it addresses.  For example:

“The TravelMag product team is excited to be developing a Chinese-language app so those interested in our publication in China can easily access it.  The development of TravelMagChina fits in with our 3-year plan goal of growing our presence in Asia, and we hope to deliver it to the market early next year.”

What if your company doesn’t have a strategic plan?  Even without a strategic plan, it’s still important to state clearly why you’re moving ahead with a project, for the following reasons.  First, if you can’t give a solid justification for going forward, you should stop until you can and, second, a clear statement of strategic fit give others on the team (even external consultants or vendors) a better idea of what you’re trying to accomplish, so they can bring better ideas to the table themselves as you begin work. 

User Themes, Epics and Stories

What Are They?

Hand PencilUser themes, epics and stories are the building blocks of Agile product development, and are about writing down what the customer wants, from the customer’s point of view.  Each describes a need, not a functionality, that should be met by the product. 

  • The theme is a general statement of the task at hand, and can be as simple as, “Enabling subscribers to comment on articles.”
  • An epic begins the narrative in the first person, at a high level.  For example, “As a reader, I want to post my opinion about the article I just read.” 
  • A story offers the detail behind each step of the epic, such as, “As a reader, I want to see how others react to my opinion – whether they like or dislike it.” While the user story can also offer a solution to the need, it shouldn’t get so specific that you constrain your development team from offering better technical options.

Who Helps Create Them?

Product owners leverage their knowledge of the customers to create the user stories.  Again, it is assumed that a good product owner is learning from not only the customer but the market and environment as a whole as well as internal resources such as sales and customer service. If you have one, the User Experience (UX) expert in engineering is another very valuable resource to creating user stories, particularly when it comes to offering solutions to the need.

What Do They Look Like?

A very easy template for creating user stories originated from a former marketing software company in the U.K., called Connextra

Even today, using this simple model is an ideal way to being creating user stories. Following are some examples of good user stories, and some that need to be improved:

Good User Story

Not a User Story


“As a subscriber, I would like to compare the options for subscription before I sign up.”



“Show the 1-year, 2-year and 5-year prices and let the prospect choose what they want.”


“As a subscriber, I want to be able to reset my password if I forget the old one.”



“Don’t make subscribers call customer service to reset their passwords.”


“As a subscriber, I want to know at least 30 days before you automatically renew my subscription.”



“As a product owner, I want my customers auto-renewed.”


Tip: Avoid falling into the habit of placing yourself into the narrative.  Neither the product owner nor the developing engineer should have a voice in the user stories.  You should never begin your user story with, “As a product owner, I would like to…”

“Writing something in the form of a user story when it’s not about users of the system misses the point.”  Bill Wake, Agile expert

Use Cases and Business Requirements

What Are They?

Use cases are similar to user stories, in that they describe a process that a subscriber does, but are a more traditional form of documenting what’s needed and commonly associated with the Waterfall methodology.  Business requirements may take use cases a step further by providing a specific workflow solution or functional direction for the engineering team.

Magnify KeyboardWhile formal requirements are not part of the Agile process per se, the reality is that requirements, themes, epics and stories are all commonly used to some degree in most subscription businesses.  Some businesses don’t create one or the other of these several documents, others use the terms interchangeably and still others combine them into a custom product development process.  So, be sure you understand what’s used in your company, or build a system that works for you.

Tip: ask to see examples or templates of “requirements” and “user stories” that your manager and/or it consider to be best-practice.  companies often have very different formats and use terms interchangeably.

While the characteristics and goal of all this documentation can be intimidating, a wise product owner will leverage the system in place within their organization, or adopt whatever mix-and-match works best for them.

Who Helps Create Them? 

If you work in a large or tech-focused business, the product owner will likely work with the developers or a business analyst.  If not, or if you are a startup working with technical consultants, you might collaborate on what works to best communicate your ideas to that team.

Business Functional Requirements

What Do They Look Like?

A common theme in these articles is “it depends.” The actual format, process and expectation for any documentation or product development process will depend on the organization, possibly even the team or initiative.  That said, following are some key elements of most business requirements:

 Business Requirements


What Are They?

Wireframes are a representation of what you want the product to look like, from the perspective of the customer – similar to storyboards used in movie production.  While most closely associated with website, software or app creation, wireframes are useful in any type of technical product development.

Who Helps Create Them?

If you work for a larger organization, you may have a User Experience (UX) expert, who keeps up on the latest trends in app and software design best practices.  If so, that person may create the wireframes for your review.  If not, you should create these yourself.  As with most product development deliverables, it’s more important to use what works within your own business than to use a specific wireframe software or tool.  Whether you mock up your product in Powerpoint, leverage a tool like Wirify to create wireframes of a web page you like.

What Do They Look Like?

Following are some examples of wireframes: 



Creating documents that bring your customer need to life for a group of people who may never meet them face-to-face is a major task!  Doing so in a way that will ensure a robust and useful product is created only increases the challenge.  And then there’s the fact that all organizations have their own way of creating product requirements.  How can you succeed?

Solution PuzzleFirst, remember to ask for templates or samples of best practices. The examples in this article are great to use if nothing else exists, but always use what your organization is comfortable with if such a thing is available.

Second, make your customer real to the engineers and other team members with a thoughtful, inspiring customer persona. Tell a story of your market need through the eyes of one individual – a “person” everyone can keep in in mind as they create the product.

And last but most important: be thorough, exact and detailed when creating requirements. This doesn’t mean overly verbose, just precise. Use accurate action words and make sure the reasoning (user story) is truly a customer perspective on the feature being requested.

Next up, an overview of best practices in sourcing and vendor relations. See you then!

Up Next

Register Now For Email Subscription News Updates!

Search this site

You May Be Interested in:

Log In

Join Subscription Insider!

Want access to premium member-only content, plus conference discounts and other benefits? We deliver the information you need for improved decision-making, skills, and profitability.

Access these premium-exclusive features


$ 57


$ 397


$ 997

Interested in a team license? For up to 5 team members, order here.
Need more seats? Please contact us here.