top of page

Building a Data Driven Backlog

Cover.png
⚠️ This project is under a Non-Disclosure Agreement. The visuals and copy are a simplified version of the final solution.

My Role

Lead product designer responsible for creating the research plan, driving the interviews, and structuring the solution.

The Client

Silicon Valley based Fortune 500 company developing tech products globally.

Context

The application is an internal desktop/mobile responsive web application tool to help track the product building lifecycle, from its concept to market release.

To track the product’s development, the user creates timelines, reports problems, shares notes, upload files and bubble up status updates to management. With its diverse set of features and different user roles, the application became very diverse over time, making it a versatile option for different styles of management and different needs of several projects among the client's teams.

The Problem

The application had many interested parties from different projects with different priorities, therefore the focus was scattered in terms of what features we needed to make improvements and which new features were necessary. The client needed a prioritized backlog for the application that would bring the most value to the product for the most number of users. 

The Process
Listen to Users

• Qualitative Research

• Online Survey

• Backlog Analysis

Analyze Data
Create Backlog

• Current Features Usability

• New Critical Features

• Overall App Usage

• Centralize Information

• Intuitive usage for multiple roles

• Simple Maintenance

Research Process

Qualitative Research

Since there wasn't a target feature to be analyzed, I decided to perform an exploratory research. Thus I assembled open ended questions for a semi-structured interview for users to openly discuss about the application usage, elaborating on individual practices to later gather requirements and insights about their workflow.

To provide insight on the main features importance for the user, a card-sorting activity was performed. Users needed to categorize the features in “Must Have”, “Nice to Have” and “Not Relevant”. This creates a rank of the main features giving us an idea which main features are more important according to the users.

Research Artifacts.png
User Satisfaction Score 2.png

The survey was created with a few goals in mind.

We needed to gather more details about the pool of users at the time. The users would answer questions like which projects they belonged, their roles, frequency of access, etc.

Frequency of Access 2.png
Online Survey

Which current features we should improve. We presented the main current feature for the users to classify them in a scale of how critical they were for their workflow and how easy they were to use.

Feature Importance Score 2.png

Which future features should be created. With the new suggested features from the qualitative research, we asked users to classify these features in a scale of how critical they would be to their workflow.

Backlog Analysis

The product is in use since 2018 so it already had a robust backlog of requests opened by users. The product had evolved since its beginning so these request needed to be analyzed and validated to determine if they were applicable in the current scenario.

To process this data I drove user entries review meetings with the QA team, filtering the requests by keyword, categorizing them in features and identifying patterns.

The Challenge

The most challenging part about this process was definitely the amount of data. Since the app was originated several years before, the backlog was very dense and diverse, the qualitative research and survey brought up a lot more feature insights than it was anticipated. That provided us a lot of data to process and turn them into useful insights in a roadmap format.

Results

After analyzing all the sources, we cross-referenced the data and decided to categorize the features insights and group them in what we called “themes” (integrations, e-mail notifications, data visualization, e.g.), so each main area of the application had several identified themes with a different set of features gathered from the qualitative research, the survey and the current product backlog.

Given the amount of features and different types of roles that would require to consult the new prioritized backlog, I created a document with different levels of information density for the solution.

The first part of the document was “Backlog Overview”. This area would provide a holistic view of the themes and features divided by the product main areas, also highlighting the most mentioned features for those areas according to the amount of mentions and requests for that feature across all data sources. This part was directed towards high level managers who needed a quick way to asses the most important backlog features for the product at a glance. 

overview 2.png

The second part of the document was “Theme Deep Dive”. In this section the product main areas were further detailed with their identified themes and how many features each theme had. This area was mostly directed to PMs (Project Managers) that needed to get a grasp of which facets of the product needed to be worked on the most.

Theme Deep Dive 2.png

The third and final part of the document was “Feature Details”. Here is where the features are listed divided by the product areas, along side their names I also wrote their business value, similar to a “elevator pitch” type of description which brings the key goal that the feature will aim to accomplish. This part is more so directed to POs (Product Owners) and product designers that actually needs to get hands on with the product backlog.

Feature Details 2.png

Takeaways

This was a very gratifying process for me to drive because it gave me a bigger understanding of the product I was working on and empowered me with a lot of information to be owner of the product and its backlog of features.

Another interesting part of this process was collaborating with the data science team. They helped processing the data and acted as consultants regarding data visualization.

 

This initiative and final solution were very well received, the client asked me to present the process to other managers of different teams to serve as a framework for other projects in our clients ecosystem of applications.

 

It goes to show how important it is to take a step back and evaluate our products to create the most valuable roadmap as possible and avoid spending time and effort on not so important features for the users.

bottom of page