With our 12.4 release, the Mingle team fleshed out its program management functionality by introducing a program backlog feature. This post is our story about how we designed this solution using problem interviews, principles and prototypes to arrive at a new program backlog.
Problem Interviews: Identifying and Understanding the Problem
At the beginning, we had heard requests for “common backlogs” but were unsure what problem a "common backlog" would solve and why it was important. So we set out to understand whether uniting the stories of multiple projects or capturing high-level organizational goals was more painful for our customers.
Turns out that both were painful. Customers who spoke about common story backlogs talked about the pain of managing multiple teams working on the same features. In those cases, we observed backlogs with upwards of 200 stories that were often solely used by product managers to determine story priority and ownership. We also saw that these backlogs of low-level stories tended to prevent teams from seeing and understanding the bigger picture - what problems they were meant to be solving.
With customers who spoke about backlogs for high-level organizational goals, we observed a collaborative process that broke larger goals down into discrete pieces of customer value, which teams could then pull and break down in a way that would work for their unique process. The backlog in this scenario functioned more as the interface between the business and the project teams who would translate the goals into executable work that would eventually realize the business goal.
Our original goal to understand which problem was more important to solve was not as easy as we assumed. About half of the customers we interviewed spoke of a common story backlog, while the other half of a higher-level goal-oriented backlog. Because the latter spoke more to our values about collaboration, preference for a pull (vs. push) system, an interest in the big picture, and desire to empower teams to develop, own and evolve, their own processes, we made the informed decision to tackle the problem we started calling the “program backlog."
Principles: Informing Design
After completing multiple interviews, we reviewed our findings and used our notes to form an activity map with three underlying actions:
- Capturing and discovering objectives
- Prioritizing objectives
- Planning and sharing objectives with teams
This activity map allowed us to easily understand the context in which our users would use our solutions. It helped us both communicate the value we wanted to provide in our product and understand when we were done. (Learn more about how activity maps can help you better track progress toward delivering customer value.)
We then came up with principles for our backlog, which we wanted to give our customers the ability to:
- Keep their backlog lean and execute work in small batches
- Focus on customer value by articulating problems, not implementing solutions
- Analyze work on a just-in-time basis
- Collaborate around backlog prioritization
Like a Product Manifesto, we used these principles as a declaration of what we believed the backlog should be. They provided us with a concise way to frame our solution and make decisions regarding what the feature should actually support.
With these guiding principles, we ventured to the next step: designing and validating solutions with prototypes.
Prototypes: Understanding Possible Solutions
We used our activity map to inform the user actions our backlog feature should support and sketches from a charrette to design a prototype. Our UX Lead and a Dev paired-up to design a prototype within a 3-day timebox using Heroku and Bootstrap. Heroku enabled us to have frequent discussions in front of working code before testing the prototype with actual customers. Bootstrap allowed us to experiment with a variety of interaction ideas very quickly.
We watched and recorded solution interviews to see how effective our prototype was at solving the problem. We observed room for improvement so refined our prototype to integrate feedback and enhance usability. After a second round, our solution interview findings showed us that:
- Value is subjective
- Size and cost vary
- Context is crucial
Observing that we had reached a point of diminishing returns, we decided it was time to start integrating these learnings into our product, and so began building the backlog into Mingle Plus.
Where we are Now
We released the Program Backlog in Mingle 12.4 on 12.12.12. We continued to test our solutions throughout the development process and look forward to feedback now that it’s in the wild.
Using problem interviews, principles and prototypes allowed us to deepen our understanding of customer needs and, as a result, make an informed decision about which direction to take from the beginning and minimize churn along the journey. We’ve integrated these elements into our overall process and continue to employ and refine them as we embark on the next great thing...coming in 13.1!