• 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!

The post Getting the most out of ProdPad + Jira On Demand Webinar and Full Q&A appeared first on ProdPad.

Using Jira for product management is like using a hammer to drive in a screw. It’ll get there, but it’ll be an ugly process and pretty much impossible to unwind.

James Mayes, Co-Founder at Mind the Product

Jira is a great development tool and it does what it’s supposed to do: it helps you to manage the completion of development tasks. Jira is where your dev team plan their sprints based on tickets that are fully formed and ready to go.

As a product manager, your job is different. Along with managing stakeholders and projects, you need to protect your dev team from outside interference. As a product manager, it’s your job to answer the question, “What should we work on next?”

We’ve all used Jira for product management backlogs because there hasn’t been a better way to manage them. However using Jira for product management also means that you create a lot of noise for your dev team to wade through – they don’t need to see what may or may not be built in the next sprint or quarter, or look into ideas that may never see the light of day.

As a product manager, you don’t want a list of stuff to build. Rather you need to figure out the right stuff to build. The right stuff is constantly evolving as you learn and iterate – and Jira is simply not designed to keep up with that.

The problem isn’t Jira. It’s how you’re using Jira. It’s time to think about splitting strategy and execution.

How To Build A Jira Product Management Workflow

The key to nailing product management with Jira is to break your process down into two distinct parts: strategy and execution.

Strategy is when you define what problems need to be solved, establish priorities and collaborate with stakeholders to develop solutions.

It’s your creative phase – the phase in which you collect up the data and information in your product backlog to figure out what to work on and how you want to tackle it. You establish your roadmap, validate ideas and iron out what you plan to accomplish.

This element of your workflow doesn’t play to Jira’s strengths and is better suited to a tool which has been specifically built for the job – like ProdPad.

Execution is when you knuckle down and build.

This is your production phase. You set up sprints, release plans, manage resources and develop what’s been sent over from the product team. This is what Jira is suited to.

In the diagram below the first three boxes show the strategy work that should be done in a tool like ProdPad, and the second three (green) boxes show the execution work that is suited to Jira.

From strategy through to execution

Using a tool like ProdPad that focuses on a product manager’s needs, rather than one that’s been designed for the dev team, means that you can define the differences between strategy and execution.

It’s a process that helps you to stay in control of what gets built and it means that nothing is left to chance. It also addresses one of the biggest problems of product management – that of leaving critical product decisions to the end when the dev team is about to pick up a ticket.

So before you move to execution in Jira for product management, you should be sure that your product specs are more or less solid. Are the ideas fleshed out and approved? Can developers open the task and see clearly and quickly what needs to be done? If the answer to these questions is yes, then you can push your product through to Jira and let the dev team do their stuff.

Using another tool for strategy means that Jira is only used for fully formed ideas. It means that you can work on what’s coming up next, and the dev team can work on what’s being built right now. And Jira is no longer a place where ideas go to die.

Get this strategy phase right and your dev team will know exactly what to build, and have lots of product context. It also gives you as product manager the space to build a roadmap of what’s coming up in the future.

5 Steps to Getting Your Strategy Right

1. Building your roadmap: Define your product vision and objectives

Don’t leave home without a product vision. Because… where are you going exactly? What value do you want to create for your customers? The product vision is the cornerstone of your product strategy and the anchor for every decision you make. That includes your business objectives (or OKRs), or the metrics by which you measure growth and success.

Even though your vision and objectives sit at the very top, they’re an important part of everyday product planning.

They help you to focus on ideas that matter to your business and what ultimately makes it on to your product roadmap. Without a product vision and objectives, your roadmap won’t have a clear focus.

2. Validate ideas in your product backlog

You should always be collecting ideas with a business case for your product backlog. It’s the beginning of the validation process. You always need a business case to understand what’s behind this new idea and what problem it represents. Without this you run the risk of losing focus and product/market fit.

We’ve designed ProdPad to collect ideas with a business case. When someone submits a new idea, ProdPad asks them why they’re submitting it before it creates an Idea Canvas.

The Idea Canvas is a powerful way of validating ideas. You can continue expanding your idea with all the following elements until it’s a fully-formed product spec, ready to take out of the backlog and move to Jira.

• Business case – how this will create value for customers or business?
• Impact vs. Effort – what is the impact on the business and for customers? Is it a huge project? How much time will it take? What about training?
• User stories – what is the user trying to achieve?
• User personas – who are you building this for?
• Designs – what should the final solution look like?
• Customer feedback – what are customers asking for?

The Idea Canvas is also the means by which you can educate your company to talk about the product and get more detail on the ideas in your backlog.

3. Look for themes in your product backlog (still strategy!)

The backlog is never as long as it looks. All those backlog items usually end up representing a handful of problems, which we call themes.

Themes are what you should really be going after. They represent the root of the problem that you want to solve for your customers.

Themes show you the scope of the problem and give you the bigger picture view of what needs to be solved. If you can identify themes, you can dramatically reduce the number of ideas you need to juggle.

For example, look at how these three different product ideas really point to just one problem area: the inline checkout flow.

In this case, Inline Checkout Flow is the theme (and you can see its objective is Revenue).

Now, you’re no longer looking at a pile of features to build. Instead, you’re looking for ways to solve a problem.

As you identify more themes, you’ll have to decide which ones to prioritize for your product roadmap. Remember to keep an eye on your product vision and objectives!

Your product roadmap will look something like this:

4. Prioritize the ideas that matter (still strategy!)

Analysing your backlog can be a daunting task – it’s often a just long list of tasks and wishes and it can be hard to sort out what should come next. But it doesn’t have to be this way.

ProdPad has designed a priority chart which allows you to sort your backlog in a number of different ways. It lays out all ideas in the backlog, based on the impact/effort scoring that you give each one, so that you get a visual of the health of your backlog.

In the priority chart shown below each dot represents an idea. The size of the dot shows you how well spec’d the idea is, the color shows you when the last update was (hot pink is the most recent). So you can see that the chart enables you to make decisions on what you do next, where you might make a quick win, and so on.

5. Get the team involved in writing product specs

Writing product specs is a process in itself – and it needs as much care and attention as you can give it.

If you’re working in a bigger company or large teams, you should err on the side of over-communication: more context and more deeply detailed specs. As a rule of thumb, the more moving parts that are involved, the less you want to leave up to interpretation.

There’s a lot at stake here. In this stage, you’ll find edge cases, surprise requirements, misunderstood functionality and even realize you’ve misjudged the scope of the task.

So catch these issues now before you move into development.

Bring in teams and individuals with relevant expertise to help you write user stories. Ask for stakeholder input. Hold product discussions. Design and test some quick prototypes. Do some user testing.

Jira doesn’t give you the space to collaborate with people across your company, but don’t skip it, as it gives your development team critical context. Developers can’t be efficient when their backlog piles up with a bunch of half-baked product specs.

When you’ve done your due diligence and the product spec is ready, you’re finally ready to push to Jira.

Push to Jira

Once you’re ready to execute, the ProdPad Jira product management integration makes it easy for you to push the work to your dev team in Jira. This integration means you can still control the following:

• You can choose how things go over to your Jira team: you have flexibility over issue type creation
• Status syncing keeps you posted on the progress of issues
• Push to your custom and required fields in Jira

Final thoughts

Clogging up Jira with your product backlog slows people down. Making a busy dev team pick through these tasks forces them to slow down their production pace to pick through tasks. And it doesn’t allow you to have the bigger picture you need either.

So think of Jira as the final destination instead, and approach your product backlog in terms of strategy and execution. Use another tool to define the problems that need to be solved and to prioritise, and once you’ve got this strategy right, then you can move to execution in Jira.

Need more info on working with ProdPad and Jira? Check out our Help Centre

Enjoyed this article? Check out our product management blog for more key insights.

The post How To Nail Your Jira Product Management Process appeared first on ProdPad.

Product Managers vs Developers

One way to understand the difference between ProdPad and JIRA is to look at who these tools are used by. Essentially, your developers will live in JIRA while everybody else in your company uses ProdPad. Product Managers require a tool that allows them to capture everything they could do from many different sources. However developers need visibility of every task that will be done, and to follow the operational progress of those tasks. Only tickets that are spec’ed and approved for development have a place in JIRA, the developer’s world. Integrations allow each team to benefit from the information held in each system without having to leave their own sphere of activity.
[bctt tweet= “Only tickets that are spec’ed and approved for development have a place in JIRA – #prodmgmt”]

Finite Tasks vs Fuzzy Backlog

So what qualifies JIRA for development tickets and ProdPad for product ideas? One advantage presents itself as soon as you separate finite, confirmed tasks and a fuzzy backlog. JIRA is designed for task management, and ProdPad for idea management – each of which has a very different working approach. There’s nothing more de-motivating for a developer than to find 500 tickets in their queue, knowing they can barely scratch the surface. JIRA is designed to see tasks through to completion; when you limit the number of tickets in JIRA to only these actionable tasks your development team can work confidently to clear them.

Nothing ‘fuzzy’ or undefined should make its way to JIRA, and anything that does should be sent right back to ProdPad. This is the holding place for everything you could do, that helps you decide whether your development team should build it. ProdPad has a low barrier to entry that allows you and your team to capture ideas at their earliest stage, and tools to help you easily review where details need to be fleshed out. There’s no harm in having 700 items in your ProdPad backlog, as with powerful search and filtering, nothing can ever be lost. Work in ProdPad is an ongoing process to surface the next viable ideas for your developers to build.

By keeping your undefined maybe’s in your ProdPad backlog, you’re keeping your development team happy and sane in their own day-to-day lives.

Tech-savvy vs open collaboration

The core design of ProdPad and JIRA makes them differently suited to different people in your team.

Evidently, developers work well with high-tech tools. And given that project management tasks should be ready for execution, there’s not a great need for collaborative features in JIRA itself. In fact, bringing a wider team (ie. your commercial or exec teams) into JIRA will likely only cause confusion and disruption for all parties. However, a product management tool needs to be much more open to company-wide communication. ProdPad has an accessible interface that’s easy for anyone on your team to understand, with collaborative tools throughout that allow you to spark up a conversation on just about anything. 

Systems Talking

A solid integration is of course key to ProdPad and JIRA working together seamlessly. Product Managers can control the synchronization of only ready-to-build ideas from ProdPad to JIRA with the click of a button. Links in each system allow developers to find out more detail when they wish to, without being inundated with unnecessary information. And status syncs between the two tools means that each team can find out everything they need to know from a single location. With the help of an effective technological relationship between ProdPad and JIRA, you can build an effective relationship between product and project management.

You can read more about the ProdPad and JIRA integration here. 

Or if you’d like to see for yourself how ProdPad is designed for better product management, sign up for a 14 day free trial here. 

The post Why JIRA Alone Can’t Help You To Do Better Product Management appeared first on ProdPad.

Flag up relevant ideas

Your product backlog should be an open and transparent environment where ideas go to flourish, not to die. However, not every prospective product spec is relevant for your entire team. ProdPad helps you to flag up ideas to the attention specific colleagues using idea following and @mentions. Daily and weekly email digests mean that your team can remain in the loop on what’s happening with the backlog and follow up should anything pique their interest.

Quick ballot collaboration

At any stage in the idea management process, voting can be a direct and simple way to collect the opinions of your team on whether an idea should be prioritized for development. ‘Yea’s or ‘nay’s should always be qualified by a reason to help product managers make collaborative but informed decisions. ProdPad attaches an easy-to-use voting mechanism to every idea canvas to provide an easy way for your team to give feedback on the product backlog.

Open, easy roadmapping

Once priorities have been set, it’s important that you can share your planned product direction with colleagues and customers alike. A roadmap should be reactive to change and continually up to date, but at the same time accessible to all. In ProdPad you can demonstrate the impact of changes to your roadmap with a drag and drop interface, and export the most recent version to PNG or PDF to send around. You can even embed private and public versions of your roadmaps into any live site. Giving users and team members an instant and dependable location to seek out the most up-to-date plans.

A complete feedback loop

If businesses are ever to coordinate on product changes, it’s important to register who has staked interest in different product ideas.  Tracking the progress of an idea is important all the way through to implementation and ProdPad helps product managers to do this in a number of different ways. Communication with customers is made easier via traceable links from idea canvases to pieces of user feedback, with fields for contact details. The feedback loop can even be automated via two-way integrations between statuses in ProdPad and other systems. With colleagues and customers kept comfortably in the loop, product managers can finally reduce the number of daily requests for new information.

Catch up on how ProdPad fits into building product specs here, and next week read about how ProdPad supports the transition to implementation. 

If you’d like to hear more about how ProdPad can help product managers to better collaborate with team members and customers, get in touch or sign up for a 14 day free trial here. 

The post How ProdPad Fits In: Sharing Ideas appeared first on ProdPad.

Now, more than ever before, your development team, your product folks, and the rest of your company, can all be on the same page when it comes to what’s working through the pipeline.

Custom, flexible status mapping

We work with the custom statuses you already use in ProdPad, allowing you to map them up with the issue statuses you use in JIRA. Essentially, when the status changes on JIRA, it updates on ProdPad, allowing the rest of the team to see where their ideas are in the development cycle.

A prod/dev flow that makes sense

So now, you can expect to work like this:
1) Capture ideas and start fleshing them out into product specs in ProdPad.
2) Once you know what you want to build (see our handy roadmap tool for that), push the idea over to JIRA to create a ticket out of it.
3) Now that your dev team is on the case, whenever they update the status of the idea from, let’s say, “In development” to “Testing”, you and your team can see that update on the idea in ProdPad.

Integration with JIRA made easy

So to get this all set up, it’s pretty simple.

Jump into your account and head to the Integrations & API page, or follow along our helpful step-by-step guide showing you every click of the way.

It takes just moments, but once you’re done, your product and development teams will be more in harmony than ever before.

If you’re not already on ProdPad, you can start your free trial today!

We love getting feedback, and we’d love to hear about how this improves your workflow or what you’d like to see come out next. Get in touch any time at hello@prodpad.com.

The post Two-way integration with JIRA appeared first on ProdPad.

Using Statuses to Manage a Product Backlog

Part of keeping your product backlog nice and tidy is being able to identify where your old ideas and feature requests currently reside.

Is a feature in development? Then mark it as ‘In Development’.  Is it nearly out there? Then mark it as ‘In QA’.

We’ve just launched ‘Custom Statuses’ for ProdPad, allowing you to add statuses like ‘In Development’, ‘In QA’ or whatever else you see fit.

You can even use these statuses to capture the reason behind archiving an idea. When you archive an idea, it stays in ProdPad (though not in your active backlog), so you can still find it later.
When you archive your next idea, use the status field to denote as to whether it was ‘Released’ or if you’re ‘Not Doing It’. That way, if someone comes up with a similar idea, they can see the fate of the previous one!
We’ve created a few default statuses for you, but you can change these as you see fit. Simply go to your ‘Account Settings’ and add or update the existing statuses to fit your workflow.

Head into your ProdPad account now and check it out. If you don’t have an account, then why not start your free trial today!

Agile Project Management with JIRA? Call for Beta Testers!

Are you using JIRA? We’d love to get you set up with our two-way JIRA integration, which allows you to map your statuses in ProdPad to those in JIRA. That way, your ProdPad account always reflects the latest status of all of your ideas.

The post Set a Status, Set a Course for Agile Project Management appeared first on ProdPad.

As we announced recently, we’ve integrated ProdPad with JIRA. This allows you to push ideas and user stories across to JIRA, creating a link back and forth between the two apps.

In the process of building this, I found the documentation for authentication in JIRA to be… let’s say lacking. It was a process of trial and error (and finally stumbling across this helpful page) that helped me get the OAuth integration for JIRA up and working.

Instead of keeping this to ourselves, I’ve decided to write a little tutorial to help others trying to setup JIRA OAuth. This tutorial applies to both the hosted “OnDemand” version and standalone installations. If you’re looking to build your own JIRA integration, we hope this helps!

Understanding JIRA OAuth

The key to understanding JIRA OAuth setup is that:
a. There is no central repository of consumer applications (unlike say Twitter or Trello), and
b. JIRA uses RSA encryption as part of its OAuth setup.

Before you can do the authentication, you have to set up a consumer app in the JIRA install. Note: each JIRA instance that you are connecting to will need a consumer app to be set up, whether that JIRA instance is hosted or standalone.

JIRA calls the OAuth consumer app “Application Link”, which requires RSA keys for signing the API calls. Before you can authenticate or communicate with a JIRA instance, you need to set up this “Application Link” and the RSA keys to be used for signing.

Set up a Consumer App in JIRA

To set up the consumer app, do the following (Note: You will need to have administrator access to your JIRA account):

1a. Log in to JIRA and, in the Administration list (click on the cog icon in the top right), head to Add-ons. (Figure 1a)

1b. Click on Manage add-ons. (Figure 1b)

2. Click on Application Links.  (Figure 2)

3. Enter https://app.prodpad.com into the field at the top of the “Configure Applications Link” page, and click Create new link. (Figure 3)

4. In the “Link Applications” modal window, enter the name of your app, ProdPad and select Generic Application from the “Application Type” dropdown. Repeat the name of the app, ProdPad, for the “Service Provider Name”, and enter prodpad for the “Consumer key” and the “Shared secret”. For the “Request Token URL”, “Access token URL” and the “Authorize URL”, enter https://app.prodpad.com. Check the checkbox for “Create incoming link”.

5. Enter Consumer Key (alphanumeric) and a Consumer Name, and paste the RSA public key into the “Public Key” field

6. Click Continue.

You’ve now created an “Application Link” (consumer app) in the JIRA instance with which you can authenticate against.

Code for the Authentication

The next step is to write the code to do the authentication of the user. I’ll show you an outline that is based on using the Zend OAuth classes, but the basic principal should be the same with whatever OAuth library you use.

The first method is to send a call to get the request token which you can then exchange for an access token. Each call using OAuth needs to be signed by the RSA keys and you need to configure the call.

$private_key = new Zend_Crypt_Rsa_Key_Private([your private key]);
$public_key = new Zend_Crypt_Rsa_Key_Public([your public key]);
$config = array(
'callbackUrl' => 'https://api.example.com/oauth',
'requestTokenUrl' => 'http://some.jira.host/plugins/servlet/oauth/request-token',
'authorizeUrl' => 'http://some.jira.host/plugins/servlet/oauth/authorize',
'accessTokenUrl' => 'http://some.jira.host/plugins/servlet/oauth/access-token',
'consumerKey' => [secret key],
'signatureMethod' => 'RSA',
'rsaPrivateKey' => $private_key,
'rsaPublicKey' => $public_key,
);

Getting the config right is important – otherwise you will spend a lot of time banging your head against a brick wall. Let’s go through each setting:

In the case of Zend Oauth classes it needs to convert the strings that are the public & private RSA keys into specific classes in order to be used. This is done in the first two lines of code above.

The config object is then array of information and classes.

The first element, callbackUrl, represents the URL in your system or application that JIRA will send the user back to during the authentication dance.

requestTokenUrl is the URL in the JIRA instance that is called to get the request token. The URL begins with the JIRA instance host in this case represented by http://some.jira.host/. This will be distinct for each JIRA instance. The plugins/servlet/oauth/request-token is common to all JIRA instances.

authorizeUrl is the URL that the user is sent to in order to authorise access to their account in a JIRA instance. Like requestTokenUrl, the URL begins with the host of the JIRA instance and then plugins/servlet/oauth/authorize. The last part is common across all JIRA installs.

accessTokenUrl is the URL that your system will call to convert the request token into an access token once the user has authorised access to their account. Like the requestTokenUrl the URL begins with the host of the JIRA instance and then plugins/servlet/oauth/access-token. This last part is common across all JIRA installs.

consumerKey is the alphanumeric string you entered in the Consumer Key field during the setup of the “Application Link” in JIRA.

signatureMethod, in this case, tells the Zend OAuth class to use RSA signing instead of the Zend OAuth class default.

rsaPrivateKey and rsaPublicKey hold the $private_key and $public_key classes respectively. The Zend OAuth uses these keys to sign the API calls it makes. Note: these keys must match the ones you set up in the “Application Link”

Once you’ve got the config set up, you need to call the method to fetch the request token. In the case of Zend, this is done this way:

$consumer = new Zend_Oauth_Consumer($config);
try {
$token = $consumer->getRequestToken();
} catch (Zend_Oauth_Exception $e) {
//some exception handling
}
//store the token for the next step (DB, SESSION etc)
$_SESSION['REQUEST_TOKEN'] = serialize($token);
$consumer->redirect();


In this snippet of code, the Zend OAuth class calls the requestTokenUrl and returns a token that is then used in the next step of the OAuth process. You’ll need to persist the $token in some manner, whether in the database, the session, or a cache. I suggest database as the JIRA token has a long life.

Once you’ve persisted the $token, you now need to redirect the user to the authorizeUrl so they can grant access to their account. This is done by the method $consumer->redirect(); at the bottom of the snippet.

Assuming the user grants your app access to their account, they are then redirected back to your app to the URL specified in callbackUrl. This end point should be the one that then does the next step of the OAuth dance: exchanging the request token for the access token.

Again, you’ll need to configure the Zend OAuth class using exactly the same method above. Once you’ve setup the config array you can then use the Zend OAuth class to exchange the request token you got in the first step with the access token that will then allow you to make API calls to the user’s account in the JIRA instance.


$config array(//as per above);
$consumer = new Zend_Oauth_Consumer($config);
try {
$token = $consumer->getAccessToken($_GET,unserialize($_SESSION['REQUEST_TOKEN']);
} catch(Zend_Oauth_Exception $e) {
//exception handling
}
$_SESSION['ACCESS_TOKEN'] = serialize($token);

In the above code, we are using the getAccessToken method of the Zend OAuth class to exchange the request token we got previously for the access token we need to access the API. Note that the method requires you to pass in the GET parameters as well as the unserialized request token.

What variable that contains the GET variable will depend on what MVC framework you are using (if any).

You will now have an access token that is persisted. This access token can then be used to access the user’s account on the JIRA instance. For further reading, check out using the Zend OAuth to make authenticated calls to APIs.

Hopefully this has saved you some time! If you can see anything I’ve missed or have any suggestions to improve on it, please leave a comment below.

The post Tech Tutorial: OAuth in JIRA appeared first on ProdPad.

Why these integrations?

Our goal is to make the lives of Product Managers and their teams easier. We know that our users are already using a variety of project management, development management, and task management tools. ProdPad helps teams decide which projects or development tasks need to be worked on next, so it was a natural progression to allow an idea in ProdPad to be pushed directly to a project management tool so development can take it from there.

Transparency in Development

While the immediate benefit of these integrations means that you no longer need to manually copy over a finished spec from ProdPad into JIRA, Trello, or Pivotal tracker, it does more than that.

Your development team will always work best if they know why they are building out a specific feature. They need to know what problem they are solving, and what impact it’ll have on the company.

Because ProdPad pushes through a record of the product spec as well as a link back to the original idea, your developers using JIRA, Pivotal Tracker or Trello will be able to track back a request to it’s core. Who requested it (was it the CEO or a client?) and what was their original intention?

This will help ensure your devs are building the right thing and know who to ask if the spec isn’t clear.

Transparency in Business

Your sales team is a great source of new ideas, and so is your marketing team, your support team and even your CEO. However, when they tell you a great new idea, they usually have no way of knowing where it ended up.

With a direct integration set up, they can see whether it landed in Trello, JIRA, or Pivotal Tracker to be worked on by the development team, or whether it’s still sitting in ProdPad waiting for a little more feedback.

Keep your team in the loop from end-to-end by integrating ProdPad with your development tool.

What are you waiting for? Start your free trial today!

API and more integrations

While JIRA, Trello and Pivotal Tracker are our first direct integrations, we’re on the lookout for new integration ideas. Our API is being built out for developer access, and we’re open to suggestions on what else you’d love to see ProdPad integrated with.

Get in touch at hello@prodpad.com if you’ve got a particular integration in mind.

Using a different tool?

If JIRA, Pivotal Tracker and Trello aren’t your bag, don’t worry! We might already have you covered with our Zapier integration! Have a look at their full list of integrations available, now up to more than 240 3rd-party services you probably already use.

The post Integrate with JIRA, Trello, and Pivotal Tracker appeared first on ProdPad.