What’s The (User) Story Behind your Product?

You just validated your idea, a great one, a new product -or feature- that clearly brings a solution to a problem.

Everything now rests on your ability to execute it efficiently and make it a game-changer, that will bring you success. If you achieve to execute it.

 As every entrepreneur should, you have a wise vision of your idea, of the best manner to address your market, and fix the problem of your target. With fame, in addition: you will not be satisfied by fixing the problem only, you wish your product can become the next industry standard that everyone is talking about.

This is the true challenge here, because your resources -time and money- are limited, in contrast to your ambition.

So:

• how can you compose between your ambition, and your limited resources?

• how to ensure that targeted users will be at the center of the development process?

• and that the developed product remains true to your vision?

Nor a work methodology, nor a doctrine, User Stories are a common, simple, and flexible practice in agile development methods. They match with those objectives, while guiding your team towards a user-focused development.

User Stories as team guideline

I first heard about User Stories when I was in Le Wagon development school, when this time came for us  apprentices to learn developing as a team, on a common project.

The idea was to transcript the project idea into several short and simples sentences (increments), describing the capabilities the product should offer, from the point of view of the targeted user:

As a <ROLE>
I can <ACTION>
So that <VALUE>

The <ROLE> is the person that should be able to execute the <ACTION>. In most cases, it is the visitor, the user, the admin .. but this segment can also allow you to describe your own different personas, your administrative rights …

• For instance: As a User of Onbrowse.io’s session replay feature, …

<ACTION> is the expected outcome of this increment.

• For instance: … I can review every visitor session as if I were behind their screen, …

The <VALUE> is the value you (expect to) deliver: the reason why you build this feature, the problem you solve, and the reason why your targeted user should give you its money:

• For instance: … so that I can understand what goes wrong in their journey (and improve it).

In the end, you write a clear statement about what you your team must develop, and what your user must be able to achieve with it:

As a User of Onbrowse.io’s session replay feature,
I can review every visitor session as if I were behind their screen,
so that I can understand what goes wrong in their journey
(and improve it).

Wait.

The truth is: this is not a correct User Story. The characteristics of each requirement are widely exaggerated, to make their individual value appear.

I also used this example in a deliberate purpose of auto-promotion, to introduce the all-new Session Replay feature of our User Research platform: onbrowse.io !

Subscribe for a free beta test! 🙂

Seriously, there are (at least) 2 simple reasons why this one does not work:

Your User Stories must be short.
You must be able to write them on a sticky note. If they look too long, then probably they should be split into several smaller User Stories.

Your User Stories must be simple and actionable.
The must allow your developers to evaluate at a glance the amount of work for each scenario.

But, I will not teach you how to write User Stories in this post.
There are dozens of articles for this on Google.

 What this post is about, is the interest of User Stories in a Product Team, to share the (same) vision of the value delivered by the product, to the user.

Storytelling for your devs.

I always had a problem with the idea that some developers, in some companies I worked in, were not understanding what the company were actually doing. They were not knowing what the company was selling, nor who were the customers, why they were purchasing this kind of product, and why ours over our competitor’s ones – our competitive advantages.

Their job was to develop, and they were developing.

I don’t say it can not work. Some talented Product Managers I worked with even achieve to do great things with half-human/half-robot developers in their team.

But, in which world is this acceptable to consider such brilliant (and expensive) resources, as executing people, not allowing them to take any initiative? or allowing them not to take any initiative? – mind the subtle difference, ed. note.

There is no better way to build an average product, with average interfaces, that rest on an average technical platform, which just barely meet the needs of the target.

This is not what you want.

Tell your developers WHY over WHAT

Some other definitions given to the User Stories, give a different approach for the <VALUE> item:

As a <ROLE>
I can <ACTION>
...
- So that <WHY>
- So that <SOME REASON>
- …

I do not agree. Same-same, but different.

It can look the same to you. But those definitions do not mention the expected value delivered by the feature – the  benefit for the user. And this is only by insisting on this point that your developers could bring the user at the center of their considerations.

And so on, they can “micro”-develop their assigned increments, with a “macro” business scope.

If you want your developers to adopt the user point of view, tell them the user gain.

With you User Stories.

You are the marketer of your idea.

Before marketing your product or your features to your prospects and users, you must market them to your developers, so they can focus their attention on the user gain, and adopt the point of view of the user in context.

With short and simple User Stories, that explain the delivered value:

• You bring empathy at the heart of the project. I already said why your developers must adopt the point of view of the user. Beyond that, working with no goal leads to disinterest, lack of effort and mediocrity. Associate your developers to your product vision and company vision to make them active contributors in your Product strategy.

• You convey your intention to developers, with a basic, but clear, codification. If developers can not get your intention, then probably an error, or a wrong statement went into your User Story ; better understand it now than later. And ask yourself, what would have happened without the User Story!?

• You help framing the “minimum viable” scope of your product / feature. Put your User Stories on paper will confirm what is inside or outside your minimum viable scope, by inputting in the balance the limited resources you have.

• You help building a sane and upgradeable data model. Aren’t you afraid that one day, to add a new feature to your product, you might have to develop again the whole technical platform? because this one did not anticipate such or such case? telling your User Stories help defining your iterations and their interactions, that make your product more scalable.

• You encourage and can streamline the teamwork, by guiding your devs to work simultaneously, on several different parts. Defining User Stories helps to identify the workload for each part, to share the responsibilities across the team, and to give a cross-visibility to each. They know what the rest of the team is working on, and can work in the same time on interdependent parts.

What to remember?

• User Stories allow you to conceptualize, and convey to your team the expected delivered value for each feature of your product,

• They help your developers to think like your customers and users do,

• They may help in the project management – but will not replace your work methodology, your specifications, etc ..

• Work with User Stories is a flexible and time-effective practice. Why not to give them a chance next time ?

• If it turns out to bring something to your team, note that it is possible to industrialize this practice with the Kanban method and tools.