How we use Mingle for Product Management

Here on the Mingle team we use Mingle not only as a way to manage our day-to-day software delivery and development, but also as a tool for product management. We’d like to share with you some of the ways that we use Mingle to do that.

Capturing requests and understanding needs

A Mingle Card showing how we use tags to manage requests

We capture requests, ideas and feedback as cards in our main development team project. We tag them with the customer name to keep track of everything a particular customer wants. By filtering on that tag we can understand everything a single customer has talked to us about and asked for. This means that when we talk to them, we can play back what we understand about their needs, which usually helps us learn more about them.

Although we welcome, capture and manage feature requests, we always strive to understand what the underlying problems and issues are that our users are trying to solve before we “build a feature”. To learn more, we use the customers' tags to identify customers and users whom we can work with when we build new things. By involving them in the discovery and implementation process, we better understand what problems they have and the possible solutions to meet our customers’ needs.

Idea management

Mingle’s hierarchy view showing the structure of our Backlog tree

We have thousands of cards in our Mingle project. If we couldn’t organize them simply and easily, they would drive us all mad. Mingle’s trees allow us to avoid the insanity by grouping our ideas, feedback and stories which helps us better organize them (and find them later!). Here are three ways we have found to organize our cards.

1. After initially capturing a request, feedback or story, we use a "Story Backlog" tree to gather all associated cards together into related buckets. The “Story Backlog” tree has three levels: Group, Feature and Story. Groups are high-level themes of ideas such as “Administration”, “Project Creation” and “New User Experience”. Features are lower level “Features” such as “Cards” and “Murmurs” and Stories. By grouping cards in this way, we can easily find related ideas, which helps us during the discovery process.
2. We also use time buckets that help us manage stories in the backlog. When we create stories depending on when we think they will be built, we put them in the "current release", "next release" etc.- buckets which help us filter to find them when planning. We also use the idea of a “Theme” to group related stories in a release together. This helps us communicate internally and externally about the problems we intend to solve in a particular release without drilling into the details.
3. We use tags such as "12.4 potential" to find cards we personally care about. We tag the stories we care about at random times during a release and then we can filter to just that set of cards when we come to prioritize and plan.

Another example of how some of our teams manage their team backlogs with Mingle can be found on our blog. 

Planning and Roadmapping

Mingle Plus’ plan view allows us to easily communicate our plans

Once we have understood that we will solve a particular problem and the expected timeframes of this delivery we use the Plan feature in Mingle Plus to create plans to provide a high-level view of what we are doing to the rest of our organization and customers. We use these plans to track progress against our goals and manage the delivery towards these goals.

Dealing with details

We only delve into details on the problems we are solving and break down our stories into deliverable units once we know that we will tackle them during the current release. This means that many ideas are high level with few, if any stories, associated with them until we plan to play them. If there are stories associated with a particular idea for most of their lives the stories that are not scheduled into the current release only have titles and very brief notes. We do not rank every story in every planning bucket. We use the feature and planning buckets I discussed above to help us keep the stories together but only once a idea or story is scheduled into the current release (or the next release) do we understand the details of a story and rank them in relation to other stories in that release. I hope this gives you some idea of how we use Mingle on our teams. We’d love to hear more about how you use Mingle for Product Management or what you need to help you better use Mingle in this way.

 

See how the newly-release Mingle 12.4 can help you flexibly manage your product