Planio Support (english)

# The Product Manager’s Guide to Planio

This guide will bring you through exactly how we use Planio ourselves internally for product management. The reason is that everyone does product management slightly differently, so we didn’t want to give a “one-size-fits-all” guide. Instead, you’ll get some ideas from how we do it that you can adapt to your own situation.

{{>toc}}

Let’s take a second to consider the product management environment at Planio. We have a mature product that’s been around for over 8 years. Thousands of organizations worldwide use Planio on a daily basis. We’re constantly adding new features, refining existing ones, improving our codebase and fixing security issues as they arise.

But we have an interesting twist in our product management. Planio is based on [open-source Redmine](https://plan.io/redmine-and-open-source/), so product decisions made by the open source community impact our product roadmap. In short, we maintain Planio as a long-lived fork of the Redmine project that remains compatible with Redmine.

In this guide, we’ll take an example of a product launch that we had last year. We rolled out an [Android](https://plan.io/android-app/) and [iOS](https://plan.io/iphone-app/) app for Planio. We’ll dig into how we used Planio as our product management tool.

## Task-Level Work as Planio Issues

Issues in Planio are the atomic unit for organization in Planio. You can think of them as work packages, user stories or tasks. In our case, a developer created an issue for individual stories. Then, he’d update the issue with notes based on his progress. He might link to related issues in the case of a specific bug. He often included references to any Git commits that were relevant to the issue.

Here’s what that looks like:

![](story-with-related-issues-revisions@2x.png)  

*Issue in Planio with related tasks and associated revisions*

As you can see above, the beauty of Planio issues in this case is that you have a clear overview in one place. You can see any blockers that need to be resolved. You can jump right to any related information with a single click instead of trying to search for it.

For example, in this case, you can click on *Revision 77fb4ea8*, and you can dive right into the diff for the associated code:

![](revision-diff@2x.png)  

*Repository diff viewer*

## Understanding Issues in Context

As a product manager, you don’t just operate at the task level. You need to be able to zoom out to see the bigger picture. Perhaps you need to give a report to the executives in the C-suite on product. Or you need to sit down with sales and give them insights into where the product is going over the next couple of sprints.

In our example product, we used Milestones as our project management approach. Our Milestones were target releases for the mobile app. Here’s an example of the v2.0 of the mobile app:

![](milestones@2x.png)  

*The overview for the v2.0 milestone*

So, in the screenshot, you can see an overview of all the issues that go into the milestone. In this example, you can see that the majority of the issues are focused on solving bugs. You can see at a glance that this milestone is at 100% completion.

## Working with Agile Boards

As a product manager, you’ll often be using an agile framework such as Scrum or Kanban. In the above project, we didn’t strictly follow a framework such as Scrum, but let’s go through the Agile approach you could use on such a project.

The Agile board will be your daily tool for visualizing progress and communicating the status of individual stories. You’ll have an overview of issues that haven’t been started yet, issues that are in progress and issues that are done. You can use swimlanes to break the board down by individual team members. Here’s an example:

![](agile-board@2x.png)  

*The Agile board with swimlanes for each team member*

The swimlanes are great for seeing whether one team member is overloaded with too much work.

In the Scrum approach, for example, you’ll often use burn-down charts to give you a sense of how well a team is performing on a particular sprint. Here’s an example of the burn-down chart for the milestone we looked at previously:

![](issues-burndown@2x.png)  

*The burndown chart for the v2.0 milestone*

This chart gives you insights into how you’re doing. You can see that this sprint pretty much tracked the ideal burn-down rate. New issues were only added once, so there wasn’t much unexpected work added on. Based on that chart, we can say that the sprint went very well indeed!

## Strategic Product Management

So far, we’ve focused on how we use the task-level features in Planio for product management. The tactical task-level work is a big part of product management. You’ll spend a lot of time deciding which stories go into the next sprint, or you’ll be estimating story sizes and helping team members get through barriers and blockers to finish specific sprint items.

But there’s more to product management than Agile boards and issues. You’ll also need to spend time understanding the market. You’ll do competitor reviews. You’ll track feature requests. You’ll sit down to interview people as part of your research into your users.

**Wikis and Sparkleshare**

In our experience, all these insights and findings get lost in a sea of Word docs, PowerPoint presentations, emails and scraps of paper. The problem is that your team won’t have a clear understanding of all this information, and you’ll find that you aren’t on the same page when discussing the product. You might have had a breakthrough from talking to customers, but if your team doesn’t understand that breakthrough, they might not understand the decisions you want to make on that basis.

At Planio we use the Wiki and Sparkleshare for sharing strategic information.

[Sparkleshare](https://plan.io/sparkleshare/) is a synced folder on your desktop that you can use to store relevant files. For example, you could store a PowerPoint presentation that you gave to senior management, and everyone on your team will have access to it.

We use the wiki for storing more refined information, whereas Sparkleshare is more a collection of documents. For example, you could store your product vision, your key insights from user testing and your key ideas driving your product in your wiki.

Here’s an example from one of our wikis that contains insights from customer interviews we held at Planio:

![](wiki-page@2x.png)  

*A wiki page listing user interviews*

The fact that this information is in the wiki in a structured format means that everyone in your organization from sales to customer support can find and learn from the insights and ideas of others. It’s also great when you’re onboarding new team members. They can learn much of the implicit knowledge of the organization by reading through the wiki.

## Operations and Customer Support in Planio

Some organizations suffer from operations, product management and customer support being siloed functions within the organization. Customer service uses a CRM tool that is separate to operation’s task management tool which is separate to product management’s tools.

So, a customer sends in an email requesting a custom feature that customer support forwards to operations that forwards to the product team, which adds it as a backlog item.

The glue holding all of this together ends up being email, and nobody can quite find out what exactly the customer wanted to achieve from that customization.

We use Planio to handle all of these functions, and we’ve found that it’s amazing to have all this information in one system.

**CRM & Help Desk**

We use the [CRM & Help Desk](https://plan.io/customer-relationship-management-and-helpdesk/) to handle customer support requests, and we can reference a specific customer request in a backlog item in the product project.

We can also quickly get insights from customer support that feed back into our product decisions. For example, we ask new trial accounts why they decided to give Planio a go and what they’re looking for in it. Here's what the email looks like:

![](quick-question@2x.png)  

*The email asking Planio users why they signed up*

We can use the filters on the issue page to quickly dig down and get a list of hundreds of responses to our “Quick question” email:

![](re-quick-question-responses@2x.png)  

*A filter showing responses to the "Quick question" email*

We also ask people why they cancelled their Planio account. We’ve created a wiki page listing the reasons and tallying up the totals, so we know the biggest drivers from cancellations. We also link back to each email with the reason, so we can get some context around the cancellations.

We’ve found that having a tightly integrated system for product management, operations and customer support really reduces the loop between support and operational issues and resolving those via product improvements.

## Planio for Product Management

We hope you’ve found some insights into how we use Planio for product management that you can put into practice. You can also check out our specific guides on using the [Agile board here](https://plan.io/set-up-agile-project-management/) or setting up the [CRM & Help Desk](https://plan.io/setup-crm-and-helpdesk-app/) here.