Product Discovery in Azure DevOps

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 in Azure DevOps

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 the Azure DevOps project. Moreover, it’s impossible to invite all the remote teammates and colleagues in different offices at the same time to a brainstorming sessions (especially if they required regularly).
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 Azure DevOps without loosing any data from the ideation process and you avoid duplicating work.

Product Discovery At The Wall
product discovery at the wall

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!

Product discovery in 9 steps

Product discovery methods can be different, depending on the projects needs or on team’s best practices. I’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)

Product Goals

First things first, you should know the why, the “raison d’etre”. So you have to collect at least one goal to be solved by the product. A product can achieve multiple goals that a users have.

Write these goals down and put them on the top level. My 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. Card title, and card details can be synchronized to Azure DevOps as Epic.

Collect Product Goals
Collect goals

STEP 2 – Define target customer(s)

User Persona Bio

Unfortunately, Azure DevOps doesn’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. My suggestion is to use the same information groups on every persona card such as “pains”, “goals”, “interest”, “bio” etc…

STEP 3 – Map the narrative flow

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. Moreover, 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. These card will be synchronized to Azure DevOps as Feature.

Goals and Narrative flow at product discovery
User goals and the narrative flow

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. The third level cards are synchronized as User Stories to Azure DevOps. 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.

Real-time synchronized details

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.

STEP 7 – Prioritize solutions

Prioritization

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
User stories prioritization
Prioritize user stories

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.

Organize user stories into releases
Organize user stories into releases

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.

Prioritize iterations
Prioritize iterations

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 product as soon as possible. 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.

Azure DevOps structure sync
Structure sync

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. My advice is – as always – 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.

Continuous product discovery
Continuous product discovery

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. It can significantly boost all the subsequent phases. Azure DevOps offers the finest features for developing the product. On the other hand, development should be supported with a high level product discovery tool. It should be 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.

Try this at home! Sing in your StoriesOnBoard Workspace

Not yet registered? Try it for FREE

Handpicked related content:

10 benefits of synchronizing the story map to Azure DevOps or TFS
Iteration planning in 5 steps in Azure DevOps
Product rediscovery using story mapping

Read more about product discovery:

Product discovery tips for product owners