What is product discovery in Azure DevOps 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 on this work can easily result in a failed product.
Contents
Obstacles of product discovery 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 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 by collecting ideas on sticky notes and discussing them on the whiteboard or the office’s wall.
There are two problems with this method though.
It’s often hard to turn offline solutions into an online backlog and integrate it into the Azure DevOps project. Moreover, it’s impossible to invite all the remote teammates and colleagues to different offices at the same time for a brainstorming session (especially if they are required regularly).
The solution is an online collaborative tool where the participants can join online and discuss the problem in real-time. The outcome can easily be synced to Azure DevOps without losing 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!
Product discovery in Azure DevOps in 9 steps
Product discovery methods can be different, depending on the project’s needs or the 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)
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 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 and screenshots. Sometimes the best ideas come later, that’s why the comments section can be useful. Card titles and card details can be synchronized to Azure DevOps as Epic.
STEP 2 – Define target customer(s)
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 offer 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
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 the main page -» open the 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’ goals). Remember to create short card titles and add details to the description field. This card will be synchronized to Azure DevOps as a Feature.
STEP 4 – Collect Problems
If your team is not experienced in the agile product design process, then you should keep this step. Otherwise, you can leave it out of the product discovery. Covering all problems with the team helps to build a shared understanding of 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 the starting point for finding solutions. This is the point where brainstorming can deliver ample solutions. To keep 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 from new user stories.
[Tweet “All ideas are valuable, so don’t dismiss an idea too early”]
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 them with tags in the card titles. Both solutions work well with the search and filter panel, where you can filter out related cards and boost visuality.
STEP 7 – Prioritize solutions
If your board is full of good ideas, the next obstacle will be deciding 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 from the following point of view:
- the most frequently used feature of the product
- which part is the shortest – but complete – user journey
- the feature that serves the biggest user group
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 they can have different meanings. 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 the product discovery stage, you can use this iteration as a prototype for different user journeys to validate the product.
When building the product the very first release has 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 feedback from real customers you should launch the product as soon as possible. By delivering new features regularly you’ll see clearly what works (and needs 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 in Azure DevOps
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 them 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 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, search for missing steps
- make up new solutions for the problems
- prioritize and group 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 in Azure DevOps as part of the agile product design process
Product discovery is not a one-time activity, you can integrate to your dev process to build software that matters
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 the 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 it into your dev process to build software that matters.