Getting the most out of ProdPad + Jira On Demand Webinar and Full Q&A

Creating a great product management process is easy to achieve if you split your strategy and execution between ProdPad and Jira.

We recently hosted a webinar with our CEO Janna Bastow and Customer Engagement Manager Andrea Saez.

They covered everything you need to know to get ProdPad and Jira working together perfectly:

• How to split the backlog between strategy and execution
• How ProdPad and Jira work together within your organisation
• Learn how to validate product features with customer feedback
• The importance of visualisation – the power of the priority chart
• Creating an agile product roadmap

If you’re already using Jira as your backlog tool you might be wondering why you need ProdPad too. The thing is, it isn’t a case of one replacing the other, it’s about creating a slick process where your development team and your product team can work without slowing the other down.

Nailing your product management process is key to being a great product manager, and during the webinar we got asked some awesome questions. We’ve got the full transcript below, let’s dive in:

Q: Why wouldn’t the product backlog be prioritized?

If you think of your entire product backlog, that could be a thousand things to do. That’s why we like the idea of splitting the product backlog from the development backlog. You could spend a lot of time and effort trying to figure out if something sits at number 752 or 753 at the level of granularity Jira asks for and it just doesn’t really make that much sense.

Now what does make sense is to surface things to the top of that list and prioritize those. It makes sense to have the next 20 or 50 items prioritized and specced and ready to go. It doesn’t make sense to put the same amount of effort into ticket number 300 as ticket number 3.

If you are pushing ideas over to Jira when they are fully specced and ready to go, they are then prioritized and you have a very granular view of what is going on. In the same way, on your actual product roadmap, you have the completed column where you can set granular priorities and log results.

But what you are not trying to do and what a lot of tools attempt to make you do with your backlog, is straight away assigning a priority for everything – no matter the stage. That tends to be a waste of time.

You should see your product backlog as a list of opportunities where there can be lots of ways to prioritize and break them up.

It could be:

• How many customers have asked for something
• What revenue potential it has
• Whether it solves a particular problem

When you are actually prioritizing that development backlog, tools like Jira are amazing for the level of granularity the development team need! For high level priorities that’s where you would use your product roadmap.

Q: I absolutely want to get into the product driven roadmap and use “current/near/future”. But, right now, we’re more sales driven and have contractual obligations due by certain dates. Is there a roadmap view that will help communicate that?

Such a good question and it’s one that a lot of people struggle with because you have this sort of tension between teams.

Firstly your sales and support teams and other folks in your team need to understand what things are coming up so they can support the launch successfully. However, the development team and the product team can really struggle to come up with accurate delivery dates without adding lots and lots of buffer time.

The more buffer they add the slower things tend to go, which means your company is not operating in a lean way. So there are a couple of ways where you can give that structure to help people understand what is happening.

1. When the sales & marketing teams need time to prepare for a launch. We recommend separating the soft launch from the hard launch.

So many companies attempt to say “we are going to launch this on Thursday.” Behind the scenes they are coding and scraping the last bits and pieces on the Wednesday afternoon or the Thursday morning. Meanwhile, marketing is waiting to send the press release out the next day which isn’t a great idea.

By doing a soft launch, or dark launch to a subset of your customers, you’ve then got a much easier roll out. Not only are you taking the pressure off the development team who are trying to rush something out the door, you’re also giving your marketing team enough lead time to fully support the release. This soft/dark launch buffer is so helpful especially if something does go wrong (as it often does).

2. If you have contractual obligations, you’ve got customers that have paid you to hit a certain project by a certain date.

Often you’ll find certain companies are operating completely this way. This is not a product driven way it’s more of an agency sort of model where you’re building particular products to deliver on specific dates.

If your company is modelling that way you do need to add that buffer time and you do need a project plan to show why and how you are going to hit those particular dates. Unfortunately that’s more of a project plan problem than it is a product problem.

Where we find the problem lies is companies that have a blended approach, where they are delivering things that are hitting most of their customers or users, but occasionally have things that have specific due dates and deadlines.

For example most of the companies that we speak to these days have a card on the roadmap that reads GDPR, a particular compliance thing that most companies in the world are having to deal with right now. This is something that has a hard delivery date.

In cases like that you can actually put a date on your roadmap and tell people “We are going to have this completed and out by May 25th”. That doesn’t mean the next card or the card after that needs a date on it.

People tend to assume that once you’ve put one date down you have to commit to dates on all upcoming projects. But the more assumptions you are extrapolating from the dates to your roadmap will make it more likely you are building the wrong thing or wasting time on things that shouldn’t be on your roadmap.

If you have contractual items they can have a date which can be articulated to the wider team, but don’t feel the pressure of doing that on every roadmap card. The more long term dates you have, the slower your company is going to be able to operate, move and iterate on new/better opportunities.

This is a long and complicated answer but one that we have a lot.

If you are having problems with dates on your roadmap please do send us an email at hello@prodpad.com to request a 1-on-1 roadmap clinic!

Q: How do I consolidate my existing Jira backlog with ProdPad?

Chances are you don’t have a lovely green field, brand new product, you have an existing backlog full of all these messy things. Don’t worry, we hear you. We’ve worked with hundreds of other companies in this situation.

What you can do is export tickets from Jira that aren’t ready to go or approved and yet to be prioritized in your development backlog. Then import them into ProdPad and turn them into ideas.

That way you can work on those ideas in ProdPad, making sure they have all the user stories and context and know that they are being built for the right reasons. Then push them over to Jira for them to continue on into the development flow.

Often we do meet people who have to clean up their Jira backlog, we’ve got articles and tips on how to do this, which you can find here in our help center and find out how to set up an integration here.

Q: Can the field and workflow mappings be modified after they’ve been set up?

Absolutely, feel free to customize your workflow. The integration owner will be able to take care of this!

Q: Can I have the idea as an epic with a workflow that matches workflow in ProdPad, so if I move the epic through the flow it updates on both?

Workflows are 100% customizable, so you can map them to what’s in Jira. We usually recommend keeping the same language so that all teams understand what you mean when something is ‘in progress’ or ‘in development.’

Q: What if I push User Stories without pushing the whole Idea?

Ideas can be broken down into individual user stories, those ideas and user stories can either work in tandem or independently.

So you can take a whole idea and put it on the roadmap and track the progress there or you can take individual user stories and put them on the roadmap or send to development.

They have different use cases, it might be that you’ve got an idea that is being delivered by two different teams. You might have a set of 5 user stories attached to an idea for team one and another 5 for team 2 in a different integration.

The other use case is you might have part of the idea being done now as a V1 and the other part planned to be done sometime in the future. In that case the later user stories could be attached to an idea on the future column of your roadmap to be sent over to Jira at a different time.

When you have an idea you have the choice to push just the idea to Jira or the entire idea with the user stories or the individual user stories.

If you push an idea, whether or not it has user stories attached, it will create the epic in Jira. If you then push that idea again with the user stories attached it won’t create a new epic but simply add the user stories to the original epic.

That’s the use case for the team that need to send over a high level ticket first and then bring in the more granular detail with the user stories later. Often there are times where there are new details or features that were missed at the beginning and need to be synced with the epic later on.

Q: How do you do high-level estimates of ideas/stories before they get pushed to dev in Jira? Why is there no estimate of effort at the story level?

Yes you can do high level estimates before they get pushed. In ProdPad we have what we call the impact and effort score. There are three different scales, one that is from 0-100, another is a simple 1-10 and the third is t-shirt sizing (small through to extra large.)

What we recommend for these is not your detailed development estimates but more of that product manager gut feel. When someone comes to you with an idea you instantly get that gut feel for if it is going to be really difficult so you set it to a high effort score. If you think it will be simple and straightforward you can set it to a lower scoring.

It’s not meant to be an exact science but it does give you this nice relative sizing of effort.

One thing that is good to remember when setting these effort scores in ProdPad is that you are thinking about not just how many days or dollars, this is going to take to get through development but how much effort this is going to take for the entire company to pull this off.

Something that might be straightforward to develop might have implications for the legal team or the sales team or the support team to make successful. Whereas other things might be straightforward for the business but much more difficult for development.

So keep in mind the entire effort when you are setting the impact and effort, that way when it is pushed to Jira that’s where it is pushed down into more detailed development specs.

For that I recommend using tools like Planning Poker which is a great tool for exercises you can do with your team to get estimates on things. This is a great way for you to get everyone on the same page with how to create estimates on a story.

At the end of the day any estimates that are made for development should be made for setting internal milestones and goals not for setting external due dates and deadlines, because we all know how complex and nonlinear development can be!

Any reflection of how many points existed for a story might not reflect back on original estimates once they have been built and understood and delivered by the development team.

Q: What is the minimum version of Jira that this integration supports?

Officially 7.2.x, but the API still works with v5 and v6 and we’ve had no complaints from customers who use these older versions.

Q: How do you get an existing Jira epic or story linked to an idea/story in ProdPad?

If you have existing tickets in Jira, you can export and remove them from Jira and import them back into ProdPad.

When you push them back into Jira it will create a new ticket but will have the new information or whatever has been updated within ProdPad now attached to that ticket.

That allows you to track it through from conception through to the delivery side.

If you’ve got something that is in Jira that is partly delivered but it doesn’t yet exist in ProdPad we don’t have a way to retrospectively connect those ones, but you can create a link manually between the two by creating a link in both Jira and ProdPad so you can keep an eye on the progress there.

Over the course of the next few sprints everything in Jira should be coming from ProdPad using the automatic syncing.

Q: Does the Jira ticket ref show up in ProdPad so you know exactly what ticket was created after you push?

Yes! References are added on both ends so you know the originating idea as well as the ticket created in Jira.

Q: How do I see which Ideas and which User Stories have already been pushed to Jira?

The workflow view will indicate where those ideas are. It will look like this:

Q: Do changes in Jira sync back to ProdPad?

The status of the ticket syncs back into ProdPad using the mapping, but we don’t do syncing of the fields themselves and there is a really good reason for that.

When you push something over to Jira that ticket might take on a different form as it is being moved through, the developers might break it down into more detail or add more technical notes.

We don’t want to have their notes accidentally overwriting the data on ProdPad that supplies the context of the idea, likewise we don’t want to re-sync from ProdPad and overwrite the developer’s work.

This comes down to data conflict management, it’s hard enough to manage conflicts if you’ve got two people typing in the same page in the same tool, let alone when you’ve got a five minute delay between tools. We don’t want to put your data at risk.

What tends to happen is that when you push something over to Jira, they have the original context of the idea in ProdPad if they need to look back at it from the link provided on the ticket in Jira. Then they would be free to work on that ticket in Jira and add more information as they move the ticket through the development workflow.

Q: Can you update ideas in ProdPad that are already epics in Jira, or should ideas be absolutely ready for dev when pushed?

Try to have as much information filled out before passing it over. Think of ProdPad as the source of truth, so it should be specced out before being pushed to Jira!

Missed the webinar? Watch it now.

If there are any other subjects you’re interesting in learning about please do let us know via comments, emails or tweets and we will be sure to add it to our webinar calendar!