Writing market and product stories

June 5, 2014 / Steve Johnson

There are many ways to write feature requests including traditional requirements, user stories, and job stories.

The traditional requirement took the form of “The product shall <have some capability>.” And this approach can work. Many teams still use this format, particularly for what are called non-functional requirements—that is, requirements that focus on capabilities and constraints, like performance, usability, security and similar items that are not feature-based.

The challenge many teams face with traditional requirements is they tend to articulate an already-designed feature. The problem with this approach is the focus is on the product rather than the person using the product.

User stories

Popularized by Mike Cohn in User Stories Applied , the user story format takes the customer as the subject instead of the product.

The format is:  As a [role] I want to [do something] so I can [achieve a benefit]

Cohn explains user stories on his website at http://www.mountaingoatsoftware.com/agile/user-stories:

User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

As a <type of user>, I want to <achieve some goal> so that <some reason>.

User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

One of the benefits of agile user stories is that they can be written at varying levels of detail. We can write a user story to cover large amounts of functionality. These large user stories are generally known as epics. Here is an epic agile user story example from a desktop backup product:

• As a user, I can backup my entire hard drive.

Because an epic is generally too large for an agile team to complete in one iteration, it is split into multiple smaller user stories before it is worked on. The epic above could be split into dozens (or possibly hundreds), including these two:

• As a power user, I can specify files or folders to backup based on file size, date created and date modified.

• As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved. 

Job stories

Alan Klement has some problems with user stories. In http://insideintercom.io/using-job-stories-design-features-ui-ux/ he writes:

Summed up, the problem with user stories is that it’s too many assumptions and doesn’t acknowledge causality. When a task is put in the format of a user story ( As a [type of user], I want [some action], so that [outcome] ) there’s no room to ask ‘why’ — you’re essentially locked into a particular sequence with no context.

In a related article, Klement argues in favor of “job stories.” He writes:

I’ve come across a great way to use the ‘jobs to be done’ philosophy to help define features. I call them Job Stories. We frame every design problem in a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome:

When _____ , I want to _____ , so I can _____ .

For example: When an important new customer signs up, I want to be notified, so I can start a conversation with them.

(Read more on job stories at Replacing the User Story with the Job Story)

I think Klement is on to something. The “job to be done” concept is powerful. That is, what job does your customer need to get done? But user stories work too. Either serves as a placeholder for an idea.

Market stories and product stories

Lately I’ve been working with teams to define two types of stories: market stories and product stories. One is from the context of the market and the other from the context of the product. A market story is written from a customer point of view, preferably in his or her exact words.

“My father wandered away from home and we can’t find him.”

That’s a market story. (Some might call this an “epic” or “theme.”) And you can hear the words as a family member would put it.

Lo-jack makes a product for families dealing with Alzheimer’s: SafetyNet™ by LoJack®. They explain: “When a loved one wanders off, there's a way to bring them back safe and sound.”

To me, this “market story” reveals the emotion felt by a concerned family member.

You can see how the market story drives the way we market the product to potential customers. But also think how this story can drive the vision of your product—it’s a rallying cry—and also a part of the acceptance criteria. As new features are proposed, we can look at the market story to see if the feature helps address the overall situation.

But clearly, this isn’t enough detail for guiding a development team. We need something more specific. I call those “product stories.”

A product story is about the specific feature or capability that will address the market story. 

• A method for pinpointing Dad’s location (maybe a bracelet or necklace—assume he won’t have his mobile phone.)

• Scheduling when Dad will be at one of multiple locations such as home, work, school, community center

• Get notified when Dad leaves a “safe” location (geo-fencing?)

• Share custody among the family members with escalation if I’m not available.

These are not development tasks but are topics for discussion. The main thing is for you and your team to agree on a way to communicate, preferably without having to write pages and pages of detail.

Which story method works for your team? Try writing stories from the market persona's point of view. 

Product managers and product owners help the team understand the people who buy and use your products. Inspire your team with market and product stories, a key part of your product playbook.