Telling the Epic – Starting with a User Story Map

In the previous post, I presented the product vision. In this post I am going to lay out the product story. The main product idea will be framed by the first draft of a user story map. It includes a description of the persona ‘Anton’ and a couple of major user tasks. This is the first post in the first Build-Measure-Learn feedback loop.

Mapping the Product Story

How can someone create a successful product based on a very vague idea? This is the essential question every product development has to answer. For this kind of task, I will rely on lean and agile methods, and especially for the product development I will apply User Story Mapping by Jeff Patton (see [Patton2014]).

A “User Story Map” provides a mean to visualize and reason about the story you tell about your software. According to Jeff Patton the process of creating a story map consists of the following steps:

  1. Frame the product, e.g. by creating a short product brief
  2. Map the big picture to get the whole story
  3. Explore the story by breaking down the big user tasks
  4. Slice out viable releases
  5. Slice out a development strategy

As you may notice, the first step “Frame the product” was already taken in the previous post. This post focusses on the second step, painting the big picture of the Text Analyzer Platform (TAP). Future posts will deal with the other steps.

A User Story Map

To get a first impression of the big picture, I analysed the product brief for major functions blocks of the system. The product brief talks about different kinds of document types and to upload those files. Uploading and storing text files is a major user task. Analysing content is another major user task, because the product brief speaks of text annotation and matching text snippets to a topic. There is at least a third major task of sharing the analysis results. The product brief calls this knowledge sharing.

To summarise the preceding considerations, the product brief for the Text Analyzer Platform results in the following major user tasks:

  • Storing text and document files
  • Analysing content
  • Sharing results

These three user tasks give us the backbone of the product story. They tell the story about how to use the Text Analyzer Platform. However, who performs the tasks? What kind of users we are talking about?

A First User Type

Every successful product needs a thorough picture of the user types. I am going to start with the user type ‘Student’. As a representative for the students, I created a persona called ‘Anton’. The persona is a fictional character created to represent a user type, see [PersonaWiki]. Here is the description of persona ‘Anton’:

– Male, 24 years’ old
– Computer Science Student
– Working on his diploma thesis on NoSQL databases
“I need a central place where to store my investigation results. During the investigation phase, I will be collecting a lot of papers, articles and other documents from the internet or other sources. After collecting them, I need to analyse the information contained in the text. Analysis includes searching the documents, annotating information and connecting them with different aspects of my work.”

The Map Tells a Story

A user type and major user tasks tells us a story. The following picture shows the user story, map which illustrates the story of Anton, how he will use the Text Analyzer Platform.

Moreover, here is Anton’s story. During his work on the diploma thesis on NoSQL databases, he has collected many documents from the internet. The documents contain a valuable information, which he needs to process. He has decided to store the document files on the Text Analyzer Platform.

Recently, Anton found an interesting introductory article on the internet. He downloaded the article in PDF format and stored it on his computer. Then he opened the website from the Text Analyzer Platform and navigated to the file upload page. On this page, he uploads the PDF file. To facilitate a later retrieval, he annotates the text with the label ‘introduction’.

At a later point in time, Anton has started an analysis on the newly uploaded text. He reads the text online while he is taking the bus to his university. He opens the text in the document viewer. There he finds an interesting text passage about the different kinds of NoSQL databases. This information is valuable to him, so he marks the passage in the viewer and adds an annotation ‘types of NoSQL databases’.

After uploading some documents and performing the analysis, Anton’s work has reached an intermediate stage. He wants to share the current state of his work with his supervisor. To share his work on the Text Analyzer Platform he sends an invitation to his supervisor. The invitation is send by an email, which contains a link for the supervisor to view Anton’s work. The supervisor accepts the invitation and was able to read the current investigation results.

Starting the First Build-Measure-Learn Feedback Loop

As already explained in the first post, I am using the Lean Startup methodology to build the Text Analyzer Platform iteratively. The development of the platform will happen in iterations on a Build-Measure-Learn feedback loop. This blog post sets the starting point.

What’s next?

The previous passages presented a rough outline of the basic functionality of the Text Analyzer Platform. It will be necessary to substantiate the major user tasks step by step. In the next post, I will detail the major user task for storing a text file.


[Patton2014] Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product (1st edn, O’Reilly Media 2014)

[PersonaWiki] Wikipedia, The Free Encyclopedia, s.v. “Persona (user experience)”, (accessed April 29, 2017),

Leave a Reply