Product Discovery Cheat Sheet

Build software that matters in 9 steps

What is Product Discovery and why is it

important?

Product discovery is the very first activity of a product design, which then

becomes the baseline for decision making. During product discovery you can

collect all the crucial information about any user problems and then provide

solutions for them. Carrying out this process lets you build better prototypes,

useful features and finally, a product that users love. Missing out this work can

easily result in a failed product.

Product discovery obstacles

Azure DevOps is a well-equipped tool for building a product and its

features, and also managing the day to day dev work. Working in this

environment all the time however, keeps you in a singular, developer only

mindset. To break this barrier, I advise you to actually leave certain tools behind

during ideation and come back when you clearly see your objectives. Collecting

ideas and solutions in a flat backlog doesn't serve design thinking and there is no

opportunity for seeing dependencies. In addition, product discovery, like all types

of ideations delivers the most value when you involve the right people in the

design team.

One of the most collaborative and intuitive ways to brainstorm is collecting ideas

on sticky notes and discussing them at the whiteboard or the office's wall. There

are two problems with these method though. It's often hard to turn offline

solutions into an online backlog and integrating it to a project management tool.

Moreover, it's impossible to invite all the remote teammates and colleagues in
different offices at the same time to a brainstorming sessions.

The solution is an online collaborative tool where the participants can join online

and discuss about the problem in real time. The outcome can easily be synced to

JIRA, Azure DevOps, VSTS, Pivotal Tracker or Trello without loosing any data from

the ideation process and you avoid duplicating work.

This online collaborative tool is called StoriesOnBoard, where you can map the

product using virtual sticky notes while all the teammates see the same board. It

works great when everybody is actually in the office too - just get a projector and

the virtual sticky notes appear on the office's wall!

Read more about StoriesOnBoard Features.

Product discovery in 9 steps

Product discovery methods can be different, depending on the projects needs or

on team's best practices. We've collected the most frequent and important ones.

You can upgrade the process by inserting additional flow such as sketching,

validating etc...or you can downgrade it by leaving out unnecessary steps.

STEP 1 - Collect goal(s)

First things first, you should know the

why, the “raison d'etre”. So you have

to collect at least one goal that a user

has that the product solves. A product

can achieve multiple goals that a

users have. Write these goals down

and put them on the top level.

Our advice is to use short titles - they're enough to recognize the discussion. You

can add details if it's necessary, moreover you can attach documents,

screenshots. Sometimes the best ideas come later, that's why the comments

section can be useful.

STEP 2 - Define target customer(s)

Unfortunately, most of the PM tools don’t support user personas yet. Maybe this

isn't necessary for the dev work, but it could be very useful to engage with the

target audience. StoriesOnBoard offers a nice feature to collect your main user

groups and assign them to goals.

It could be crucial to map the relationship between user groups and goals. A user

can be assigned to multiple goals and multiple users can be added to the same

goal. The number of assigned personas on a goal could express priority between

goals. Persona cards offers a nice content structure to describe your audience.

Use the same information groups on every persona card such as “pains”, “goals”,

“interest”, “bio” etc...

Related articles:

What’s on a persona card?

5 formatting tips for personas

Example:

Accommodation Website Example - Personas

STEP 3 - Map the narrative flow

Before coming up with solutions you should map the user journey or the user

steps. These are the activities that the user does on the product to reach their

goal. In most cases the steps can be ordered in a narrative flow eg: open main

page -» open search panel -» browse search results etc...

Put activities on the second level below the related goals. If it's interpretable,

then organize the goals into a narrative flow too. (Sometimes there is no logical

order among goals eg: different users's goals). Remember to create short card

titles and add details into description field.

STEP 4 - Collect problems

If your team is not experienced in agile product design process, then you should

definitely keep this step. Otherwise, you can leave it out from the product

discovery. Covering all problems with the team helps to build the shared

understanding among the steps. Pay attention to note this information on the

second level cards' description.

STEP 5 - Explore solutions

Goals and the user steps create the product's backbone, this is starting point to

find solutions. This is the point where the brainstorming can deliver ample

solutions. To keep the pace you can use different brainstorming methods, eg:

silent brainstorming.

All ideas are valuable, so don't dismiss an idea too early. Try to find at least one

solution for every user step. Card formatting rules are the same - keep the title
short and detail it in the description. Don't regret the time used to go through

and discuss all the cards. These conversations can result new user stories.

Related article:

5 awesome brainstorming techniques to boost planning

STEP 6 - Define user journeys

Revise the product discovery process by retelling the user journey in different

ways. It's a perfect opportunity to search for:

• missing steps in the journey

• broken journeys

• solutions that aren't part of a journey

You can visualize user journeys by using different card colors, in addition you can

combine it with tags in the card titles. Both solution works well with the search

and filter panel, where you can filter out related cards and boost visuality.

Related article:

How to visualize personas and journeys

Example:

Accommodation Website Example - Journeys

STEP 7 - Prioritize solutions

If your board is full of good ideas, the next obstacle will be to decide where to

start prototyping or developing. There are several ways to arrange user stories

into priority order. Based on your project needs or customer requests you can

rank user stories by the following point of views:

• the most frequently used feature of

the product

• which part is the shortest – but

complete – user journey

• feature that serves the biggest user

group

Related article

Learn to prioritize user stories from UX designers

STEP 8 - Create MVP, prototypes or further iterations

One of the main reasons to prioritize user stories is to find out where to start

and to slice the backlog into iterations. I wrote iterations, because it can have

different meaning. You can organize user stories into a release when you need to

group them into working features. You can also group user stories into sprints,

when the dev team works in scrum. And here at product discovery stage, you can

use this iterations as a prototype for different user journeys to validate the

product.

When building the product the very first release has a special importance. This

Minimum Viable Product is the smallest usable product version. It should fulfill at

least one user journey under a goal. So keep it as little and as simple as possible.
Rearranging the cards or whole releases is tremendously easy by drag and drop.

Step 9 - Start prototyping / executing

No matter how thorough the product discovery was, the best feedback is the

market validation. To get powerful feedbacks from real customers you should

launch the prototype or the product as soon as possible, and develop it

continuously.

By delivering new features regularly you'll see clearly what works (and in need of

additional development) and what is unnecessary (and should be stopped).

Iteration planning is much easier in StoriesOnBoard where you can rearrange

existing user stories and add new ones. Involve the dev team to specify the user

stories with story points and/or add acceptance criteria too. After pushing the

iteration to Azure DevOps all the details are synced and everything is ready to

execute.
Continuous product discovery

The work on the story map won't stop after the product discovery phase. It's not

a static backlog, you have several chances to reuse it later on.

It's a perfect place to collect new ideas and store it until the next pre-planning

session. The best practice is to create an iteration for the unprioritized ideas and

force the design team to drop all emerging ideas. Then you should organize a

regular brainstorming sessions to discuss and prioritize.. Put prioritized but not

scheduled user stories into priority “iterations” such as MoSCoW categories.

If you have all the new ideas in priority order in the backlog, then you shouldn't

miss the awesome opportunity to do the iteration planning right here, and push

them to Azure DevOps. Iteration details such as description and release date can

be added and synchronized too.

What if a project is already started without any product discovery phase? Can we

use this method somehow to improve the development process? Of course! I call

it product re-discovery. If your Azure DevOps project is full of epics, features and

user stories you can reuse them to build the product backlog in StoriesOnBoard.

How? In two ways:

The easiest way is to import the whole backlog - with structure synchronization -

to StoriesOnBoard. After presenting the story map to the design team you have

massive opportunities such as:

• revise the narrative flow, searching for missing steps

• make up new solutions for the problems

• prioritizing and grouping unscheduled user stories

The second way to re-discover the product is to import all the issues without

structure sync and rebuild the backlog manually. Rethinking the whole product

gives you more chances to discover new stories.

Product discovery as part of the agile product

design process

To sum up, product discovery is a crucial part of the whole design process which

can significantly boost all the subsequent phases. Project Management tools

offers the finest features for developing the product, but it should be supported

with a high level product discovery tool which is intuitive enough to involve all

the stakeholders including customers, users, UX designers and developers too.

The steps of product discovery process are not carved in stone, you can improve

or shorten the above described sample. And remember, product discovery is not

a one-time activity, you can integrate to your dev process to build a software that

matters.
 Copyright © 2019 DevMads Ltd.

All Rights Reserved. No part of this book may be reproduced or

used in any manner without written permission of the copyright
ower except for the use of quotations in a book review.

Published by DevMads Ltd.