How To Write Product Requirements That Engage Everyone on the Team

Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery.

Why do you write product requirements?

We used to write long product requirement documents to communicate the solution we wanted our engineering teams to build.

But over time we learned that outlining every detail of the solution upfront leads to overcommitting to solutions before we know whether or not they work.

With the rise of Agile methodologies we started to define our requirements iteratively allowing us to collect feedback from the market before we over invest.

With the introduction of the user story and more recently the job story, we shifted our focus again from the solution to the problem we are trying to solve.

The Who, What, and Why of Communicating the Opportunity

Both user stories and job stories shift the focus from what should be built to what the opportunity is, for who, and why.

They differ slightly in their format.

User Story: As a discussion participant, i want to be able to use a pseudonym, so that I can maintain my privacy yet have a persistent identify throughout the conversation.

Job Story: When I find a discussion that I want to participate in, I want to be able to use a pseudonym, so that I can maintain my privacy yet have a persistent identify throughout the conversation.

The key difference is that the user story highlights the role of the user, whereas the job story highlights the context in which the need arises.

Regardless of which format you choose, you want to make sure that both elements are reflected in your requirements.

The format of your requirements is less important than what you communicate. – Tweet This

Frame the Opportunity So That Everyone Can Participate

A user problem represents an opportunity for your product team to create value for your user.

When writing product requirements, focus on capturing the opportunity, not on generating a solution. –Tweet This

Make sure that the opportunity is framed in a way such that everyone on your team can participate.

It should leave room for you and your user experience team to explore multiple solutions.

It should allow your engineering team to start thinking about what technical challenges might lie ahead and to give input on what directions might be easier than others.

It should allow your marketing team to start to test messaging and value propositions.

Remember, a user story or job story should start the conversation. It’s not the final word. – Tweet This

Iterate Until You Get It Right

It’s one thing to read about how to do this. It’s another thing to put it into practice.

Let’s walk through an example:

As a user, I want to use my Gravatar photo when commenting on blog posts, so that people know who I am.

What’s wrong with this user story?

• It doesn’t specify a clear role. “As a user …” doesn’t communicate anything.
• It focuses on a solution – Gravatar photos.
• The benefit is weak. Why do I care if people know who I am?

Let’s try again.

As a blog commenter, I want to include a photo of myself, so that other readers recognize who I am and I am able to grow my reputation within the community.

This is better, but it still needs work.

“As a blog commenter …” is better than “As a user …”, but what are you trying to communicate about the user with this requirement? How can you include more of that in the story itself?

Consider the following:

• “As an aspiring entrepreneur  …”
• “As an awkward teenage who has an embarrassing question …”
• “As a cancer survivor who is proud of overcoming my battle …”

While each of these people might all be blog commenters, these roles communicate so much more to your team about what you are doing and why.

Use the role in user stories to communicate meaningful context about the user.  – Tweet This

We have another problem. Our user story restricts us to a single solution – include a photo of myself.

It doesn’t accurately represent a problem or opportunity.

Our opportunity is actually hiding in our benefit.

Rewrite this user story as follows:

As an aspiring entrepreneur, I want to be recognized for my comments so that I can grow my reputation within the community.

This user story does several things:

• It communicates context about the user.
• It communicates the opportunity.
• It communicates the benefit of delivering on that opportunity.
• It allows your team to start discussing how you  might deliver on this opportunity.
• It allows your team to explore multiple solutions.

Before you call it done, you’ll need to add acceptance criteria and define a desired outcome, but you’ve come a long way from where we started.

Create a Product Requirements Checklist

It can be hard to keep all of this in mind as you scramble to write product requirements for your next sprint.

A product requirements checklist is an easy way to ensure that you don’t slip back into describing solutions.  – Tweet This

After you write your requirements, ask yourself the following questions:

• Does your requirement communicate who you are building for, what they need, and why?
• For user stories:
  • Did you specify a specific role?
  • Did you describe the challenge that role faces?
  • Did you explain how solving that challenge benefits the user?
• For job stories:
  • Did you describe the context in which the challenge arises?
  • Did you describe the challenge that occurs in that context?
  • Did you explain how solving that challenge benefits the user?
• Does your product requirement allow the team to explore multiple solutions?
• Does your product requirement allow the engineering team to start investigating technical implications?
• Doe the opportunity define a measurable outcome that makes it clear when this opportunity has been met?
• Does your product requirement engage everyone in a conversation?

Define Your Team Process for Communicating Opportunities

As a team, take the time to answer the following questions and add your responses to your team charter:

• Who will choose which opportunities the team will pursue?
• Who will define the opportunities?
• What format (i.e. user stories, job stories, etc.) will you use to define opportunities?
• How will you ensure that your product requirements start a conversation and aren’t the final word?

Don’t gloss over these questions.

Teams waste too much time debating about whether or not they are pursuing the right opportunities.

Take the time to decide on a process upfront. It will help you move faster during development when it matters most.

This article is part of a series on building shared responsibility for product delivery across the product development team. To get notified of future articles, subscribe to the Product Talk mailing list. You can find the previous articles here.