The Birth of the Modern Roadmap

As a new decade starts, I want to reflect on the advent and growth of something truly important in our industry: the lean roadmap for product managers.

This is the story of how it was invented in a cafe in south London.

Years ago, when I started as a junior product manager, I fell into the role by accident, like many others did. With little training or guidance, I learnt a lot by doing or Googling.

One of the first things I came across was the concept of the roadmap. All of the examples online were of timeline roadmaps – essentially Gantt charts. This felt pretty intuitive to me, having had a little bit of training in project management. After all, who doesn’t like the sense of control that a Gantt chart gives you?

Creating a roadmap

I set off on creating my own roadmaps – at first, on paper and whiteboards; soon, digitised in various incarnations: PowerPoint, Excel, and even Microsoft Project played a part in my early misguided product management efforts. 

I didn’t realise my efforts were misguided; my bosses certainly didn’t give me any guidance otherwise. As a matter of fact, they essentially gave me a pat on the head for my colourful, visual timelines of the upcoming product plans, and sent me on my way to go deliver. I don’t think they knew any better either.

Many of you reading along probably know what happened next (as product managers): Deadlines whooshed passed and timelines slipped. Turns out that delivery is hard, especially when you’re hanging your assumptions on made up estimates! 

At that stage in my career I didn’t feel comfortable speaking up as a product manager. So I course corrected by adding more buffer and covering for the slipped work. Don’t tell me you haven’t done this too – we all have :see-no-evil:

The net result: The added buffer meant that delivery timelines slowly stretched out. We all know that work expands to fill the time given to it. So, scope would creep and work would slow down just enough to cause further slipping. I’d have to add more buffer or have to explain to my bosses again about why we weren’t delivering on time. It was an insidious, vicious cycle.

And I was sure I was the only product manager who was so bad at her job that she couldn’t deliver a roadmap. I mean, wasn’t everyone else simply making roadmaps, building the features, launching like a boss, and killing it out there?

That’s what it felt like in 2009, and no one was talking about failure in a real way yet.

What changed?

In early 2010, I met Simon Cast, a fellow product manager, at a light-hearted social charity event in London. It was a rarity to run into another product person in those days. We relished the chance to chat and share some stories of our experiences. 

I pointed out that there was a lack of places for product people to meet. Which led me to suggest that we work together on running the first ProductCamp in Europe. We went on to run ProductCamp London along with some other product people, just a few months later. This was how we connected with Martin Eriksson. He was just formulating the idea of ProductTank at that time, and we went on to co-found Mind the Product together.

In the meantime, I’d been harbouring an idea for software to help me streamline my job as a product manager. This included the roadmapping aspect and the even more tedious spec-writing aspect. I’d even gone so far as mocking up some prototypes and giving the software some names. 

Embarrassingly, I’d gone with Spec-ify for the spec-writing tool and Map-ify for the roadmapping tool.

ProdPad prototypes
The initial ProdPad prototypes
Very early stages of ProdPad’s lean roadmap

Simon gave me feedback and advice on the software concept. He helped shape it into a single tool that did both idea backlog management and roadmap management. He brought his skillset in back-end development, combined with my experience with front-end (though my abilities with JQuery are and remain dubious!), and we began building a first version of what was to become ProdPad! 

Simon and I both held roles heading product at different startups in London, and we built ProdPad in our spare time and on our own laptops. We used it to help us do our jobs more effectively.

We had a lot to learn, as this was still a timeline roadmap.

Early version of ProdPad’s roadmap feature.
Early version of ProdPad’s roadmap feature

It wasn’t until we started taking our slightly-more-market-ready version of ProdPad out to the product people we knew in our circles that we spotted our fundamental error.

You see, we still thought that we were the only product people who weren’t delivering on roadmaps. However, when we released an early version of ProdPad, our eyes opened when we got early feedback: About a month in, our most popular request was to be able to shift multiple items on the roadmap at the same time. 

Had we simply listened to our customers at face value, we might have enhanced the functionality of the roadmap with a multi-select drag-and-drop function so that they could do just that.

But instead, we asked a bunch of why’s

When we got to the bottom of it, it became clear that no one was delivering on the roadmap. The request to move and manipulate multiple items on the roadmap at the same time came from the desire to adjust around slipping timelines and missed deadlines. 

So we asked ourselves: If no one is delivering to a timeline roadmap, what’s the point of the roadmap for a product manager?

I’ll admit that we held on to the timeline format for a few extra months longer than we should have. Sunk cost fallacy, you see. We’d invested a lot of our time building this thing, an all-singing, all-dancing JQuery behemoth that allowed you to add features to a timeline roadmap, stretch and shrink them to the appropriate dates, and drag them into swimlanes. It was incredibly hard to admit that we had been doing our product management jobs wrong for years, and that we’d built a useless, misguided tool, and wasted months of work in the process, even as the customer feedback stacked up.

But the feedback was in, and the timeline had to go.

We got together at a cafe that was about halfway between our homes, in south London. Wandsworth, to be precise. (This was long before we had an actual office, after all!) It was nearing the end of 2012. 

We talked about what a roadmap was and what it wasn’t.

A roadmap is a communication tool. It’s strategic. It aims to keep the team aligned and informed about the steps that are needed to reach the product vision. The roadmap needs to show some concept of upcoming initiatives. It should show how it’s connected to the problems the team is meant to solve, the objectives they are meant to hit. 

A roadmap isn’t a list of features and bugs and work in progress down to the day and week and month. That’s a release planner. 

Simon turned over his napkin, and sketched out three columns:
Current | Near term | Future

He talked me through a concept of time horizons, and three ‘buckets’ with initiatives that could group together ideas, features, or experiments. His concept was underpinned by the idea that initiatives in the Current column were more certain, while the ones in the Future were less certain and more fuzzy in scope.

Early sketches of timeline-less roadmaps, using time horizons and ‘certainty’ as axes.
Early sketches of timeline-less roadmaps, using time horizons and ‘certainty’ as axes.
An early wireframe of the Now/Next/Later format of the roadmap
An early wireframe of the Now/Next/Later format of the roadmap

Simon and I both liked the freedom that this format gave, while still delivering on all the points that a roadmap needed to have, to still ‘be’ a roadmap.

We passed the napkin back and forth and made some notes and agreed on a simplified version. I would knock it together with simple front-end code, so Simon could hook it up on the back-end. 

We shuffled the timeline roadmap code to the side. This was an experiment after all, and we had no idea if it would work.

One piece that we didn’t talk about was whether we would still call it a roadmap. We didn’t think about it at first, until we saw the result live on the page – a three-column time-horizon roadmap, meekly standing where a timeline roadmap once stood. We debated renaming it, but didn’t know where to begin. After all, our website said we had roadmap software, and it did technically meet the criteria. Our new roadmap format was just… different.

Somewhere along the line, the napkin was lost. I wish I’d framed it now.


We launched with no fanfare, as you do when you have no paying customers and a simple MVP bootstrapped product that you built from your bedroom. But our early testers took note.

And they actually liked it! 

A timeline-free roadmap for product managers
ProdPad’s first Now/Next/Later roadmap

What we discovered in our next rounds of feedback was that the format allowed product people to communicate the bigger picture. After all, most companies don’t know how big they’ll be in a year’s time, let alone how fast they’ll be able to deliver! 

Our first version was very MVP. It was simply some boxes you could add to one of three columns pragmatically named ‘Current’, ‘Near Term’, and ‘Future’. Frankly, you could have done it in Trello. The basic format that grew into a much richer form of lean roadmapping.

It was right to keep the name ‘Roadmap’ for this new format, even if it didn’t look like the other roadmaps. From feedback, we realised that we were implicitly giving product people permission to step away from the timeline roadmap format. After all, they were giving their team and their bosses a roadmap. It said so, right there at the top of the page, on a real dotcom SaaS product, so it must be legitimate! 

By subverting the format and terminology we changed the way that roadmapping was done. Which we appreciated some time later. It’s a roadmap. But it’s not a usual format roadmap.

We still had a long way to go to find out if our way was any better. We had a lot of listening and learning and iteration ahead of us. 

The Modern Roadmap Evolves

The basic scaffolding of the new roadmap format worked. New testers gave us positive feedback about the time horizon concept regularly. We set out to figure out what we needed, as the functionality of the roadmap was severely lacking.

Since then, over the years, the roadmap has evolved.

  • You can link initiatives to ideas in your backlog, so you can see what experiments your team might run in order to tackle each problem on the roadmap
  • We made these ideas sortable, and then made the workflow stage visible so you could see if it was in discovery or in Jira or wherever else
  • We created colorful labels, so you could associate initiatives with objectives. Later, we gave these labels text fields, and later still, we allowed you to link an initiative to multiple objectives
  • A set of filters lets you carve up your roadmap into specific views suitable for the job at hand
  • We created options to publish and export your roadmap, so you could create versions for your exec team, your sales team, or anyone in between in a flash
  • We introduced the concept of product lines and a portfolio view of your roadmap, allowing ProdPad to scale for use in much larger enterprises

These and many more iterations have allowed us to evolve and improve the roadmap in line with today’s best practices. We’ve learned a lot, and continue to learn as the discipline of product management grows and develops. As we move into a new decade, we’re excited to see what comes next! We do not rush to follow the crowd. Through measured, and considered steps forward, we build the right solution, even if it’s not what is expected.

What’s in a name?

Along with evolving the roadmap functionality itself, we’ve seen a lot of change over the decade in how we talk about this new form of roadmapping.

We didn’t know what to call it when we first launched the new roadmap. We just kept the name as is, simply calling it the Roadmap. Internally, we were calling it the ‘time horizon roadmap’, and in conversations with potential customers we would talk about our ‘dateless roadmap’, but none of these ever had a ring to them.

Later on, as the concept caught on, we started hearing about other terms that rang true to our purpose. In 2013, Bruce McCarthy started talking about the idea of using themes on the roadmap. He launched that term into popular consensus: through conversations he had with Jared Spool, an MTPcon talk and an article. Problem-focused roadmaps had been simmering under the surface for some time. We all knew there was something inherently wrong with the feature-based roadmap. We were lacking the tools and techniques and vocabulary to do something better.

Theme-based roadmapping was a popular term for a while. We watched it evolve into various other names, including Problem Roadmap, Objective Roadmap, Outcome Roadmap, or as we like to call it, as it derives so heavily from the Lean principles of ongoing learning, the Lean Roadmap. Bruce went on to write the very popular and timely book Product Roadmaps Relaunched, with several other product luminaries. I wrote the foreword, which was an honour. Even more thrilling was seeing the ProdPad Now/Next/Later format roadmap touted useful in a full page spread case study. It’s smack in the middle of the book!

ProdPad's  Now/Next/Later is featured in the Roadmap Relaunched book for product managers
ProdPad’s Now/Next/Later is featured in the Roadmap Relaunched book

It’s been a long journey of discovery. But we’re on the right path, and we’re building the tool that actively helps product people do their job better. I can’t wait to see what we learn in the next decade!

Are you a Product Manager? If you have any burning questions or want to talk all-things-product, then get in touch. Or, give ProdPad a try by signing up to a free trial.

The post The Birth of the Modern Roadmap appeared first on ProdPad | Product Management Software.

Changing the Way Product Managers Speak to Stakeholders

Changing the way we talk to stakeholders and executives can make a world of difference, both for them and for us as product managers. We can’t expect them to simply understand the way we work, we need to bring them into the product process and open the door to our world. With this comes teaching them our lingo, and rearranging their view on what product is and how it works.

Below are a few terms to kick-start and change the way we frame things to others:

Feature Roadmap = Product Roadmap 

When will it be done? Do you have a timeline for this?

Due dates and timelines should never be promised – as product people we all know this. And yet, it seems to be the one question we always get. 

The first step to changing this conversation is to make sure everyone has access to the product roadmap. Hiding it as a Hootsuite dashboard is a huge mistake.

Reframe the conversation from “time” to “strategy.” At first it may seem daunting and that no one will accept this, but it’s actually pretty simple. 

Think about it this way:

Imagine that you’re going on a road trip, and you tell someone you will get from point A to point B in three days with no further context. They will expect you to fulfil what you’ve said.

Now imagine you prepare them for possible changes, and give them the whole context of the road trip, such as pit-stops and side roads. Your road trip buddy will now be more forgiving with time changes.

It’s the same with presenting a product roadmap without timelines. You’re presenting the whole strategy, not just the time constraints you’ve boxed yourself into. Once you remove the tunnel vision and explain the entirety of what is happening, better conversations will be had. 

Second, make sure no one refers to it as a ‘feature roadmap’, and start calling it what it is. It’s a roadmap for your product. It is not a timeline, it is not a gantt chart, it is not a list of features. A product roadmap is a document that allow product managers to explain what they’re working on and why. 

If you need a little help on building a product roadmap everyone understands, start here.

Outcomes > Outputs

A product roadmap focuses on outcomes – what, why, for whom. What are the goals that your product team are aiming for? What problems are the product managers trying to solve?

Outputs come after you have gone through the product validation process – after the idea has been reviewed, validated and spec’d out. That’s when you pass this on to development and focus on the output. 

And this is where the release plan comes into play. This is an entirely different document that focuses on how fast something will get done, after you have defined what the possible outcome is. Also, be sure you’re not referring to your release plan as a release roadmap or a technology roadmap. A product roadmap and a release plan are two documents that support each other in the whole product development cycle, but they’re not the same document, and terms should be kept clear.

ProdPad Dots representing the roadmap and release plan, coming together
Roadmap and release plan

Feature Backlog = Opportunity Backlog

A feature encompasses an area of your product. It simply states that your product does something, but doesn’t focus on what the benefit is. So let’s change the conversation around that first.

Once your entire team understands the benefits your product gives your customers, you can start talking about opportunities or ways you can improve those benefits. These opportunities, or ideas as we call them in ProdPad, make up your opportunity backlog.

What problems can you solve? What value would these provide if solved?

Once your team starts talking about problems to be solved in the opportunity backlog, it becomes less about ripping off the competition, and more about how you can provide value to customers. At the end of the day, you’re not building a product to compete with others, but to provide value to your target market.

Feature Request = Customer Feedback

A request implies something will be done. Will you do every single item that comes through? If you did, you’d just be a feature factory!

Change the language to customer feedback. This implies that it is coming in as an observation from your customer, rather than a request you must fulfil. Product managers shouldn’t focus on feedback being positive or negative, but rather as input for areas you can improve in your product. 

This will also give you a leg up on how your team responds and handles the feedback that comes in. If your team isn’t currently focusing on something that’s requested, they can share your product roadmap (wink wink) to talk about current priorities, and how these will benefit (wink wink) the customer. Thank the customer for their feedback, link it to your opportunity backlog, and as time goes by, understand the impact of that feedback for the problems you aim to solve. Do I have to wink again? I’m sure you guys get it by now.

The post Changing the Way Product Managers Speak to Stakeholders appeared first on ProdPad | Product Management Software.

The one where Janna Bastow went in hard on Twitter

Earlier this week, Janna Bastow, Co-founder and CEO at ProdPad, took to Twitter and published her very own self-proclaimed TED Talk, on why timeline roadmaps suck.

And the product management world loved it.

Janna Bastow kicks off her Twitter thread on Monday, September 2nd.
Janna Bastow kicked off her Twitter thread on Monday this week

What did Janna’s 19-tweet thread include?

The tweet thread began with an expert explanation on why timeline roadmaps set product managers up to fail. She then continued with a step-by-step guide on why ‘product people of the world’ should ditch these types of roadmaps. And to conclude, Janna revealed why everyone should be using lean product roadmaps instead.

Oozing with product-passion, a wealth of experience, and a few carefully chosen emojis – Janna’s tweets went viral. Above all, this resulted in some great conversations and discussions on product management.

Janna hadn’t planned the Twitter thread. However, she was prompted to do so after trying out a new eco-friendly search engine:

“I was testing Ecosia, a search engine that plants trees with its ad revenue, as opposed to lining Google’s pockets. I checked the search results for ‘product roadmap,’ as I wanted to see if Ecosia showed the same thing Google does. Oh yes, same problem – timelines everywhere. However, it spurred me on to revive a talk I gave on why lean product roadmaps are the way forward.” Janna Bastow, ProdPad.

Let’s learn about lean roadmapping

Here’s why product managers need to be embracing a lean, outcome focused roadmap in order to become better product people. Please get in touch, or book a ProdPad demo if you’re looking to discuss your own product strategy. 

Janna will be putting together a Q&A – which will answer the most popular questions from this Twitter thread. Watch this space.

The post The one where Janna Bastow went in hard on Twitter appeared first on ProdPad | Product Management Software.

Feature Friday: Empower your Team with Product Ownership

Having multiple initiatives going at the same time can be overwhelming for any team. Multiply this across several products, and it can be easy to lose focus quickly. To avoid this, you can introduce some product ownership to your team.

Assigning a Product Manager to a card means one person will take ownership of leading the product. This will enable the rest of your team to keep the focus on the work at hand.

To increase transparency, we have introduced Product Managers and Roadmap Card Owners. These new assignments let the company know who is accountable for moving things along and who to ask questions to.

Product Managers add a level of selective functionality access within the application. You can assign the Product Manager status to any admin or editor within the app. Therefore, the user will have exclusive access to make changes to the product and roadmap, deciding how and when the Roadmap is edited and managed.

Roadmap Card Owners allow you to highlight who is responsible for a particular initiative within the team. By having this level of visibility on who’s leading an initiative, it can enable you to work better as a team and move things forward quicker!

Ownership within products adds a level granularity without overwhelming the roadmap and the work getting done.

How to assign a Product Owner

Assigning a Product Manager

When creating a new product, on the attributes panel you will be asked to select Product Managers. A list of existing admins and editors will be available.

The attributes panel with multiple product managers.

Once assigned, the users will appear as part of the product and within the Product Canvas.

Assigning a Roadmap Card Owner

To add owners to a roadmap card, click on the card to prompt the slide out.
Under the owner icon, select the users leading the initiative.

Selected and non-selected users from a drop down on the card.

Once the user is selected and the attributes saved, you will find the selected user’s profile picture at the bottom left corner of the card.

Selected user's profile in a circle at the bottom left corner of the card.

Voila! Now your team knows who will be leading the charge and who will be needed to get on with things to take your product forward.

The post Feature Friday: Empower your Team with Product Ownership appeared first on ProdPad | Product Management Software.

Feature Friday: How to Communicate Blockers by Showing Dependencies

As the ProdPad team have learned more about the challenges faced by product teams, we’ve heard about the need to represent dependencies in ProdPad.

Logistical dependencies (where work on one initiative could be blocked by delays with a separate initiative) are useful to see on the roadmap when planning out your strategy, making sure that the outcomes you expect to achieve are feasible.

This is particularly important when working with a high volume of product roadmaps (maybe where your product roadmap is split by delivery team), as dependencies like this could be spread across multiple roadmaps.


Here’s how to show dependencies on your ProdPad roadmap:

Find the blocker card, prompt the slideout and grab the card’s URL

Image 2019-01-23 at 7.51.21 am.png

Add the URL to the relevant blocked card, with a note to say what’s blocking it. For a little extra flair, use some emojis!

Image 2019-01-23 at 7.53.48 am.png

Add a “blocked” tag and use the filters to make sure you have the visibility needed.

When communicating strategy to your leadership team; you can now easily show which initiatives are dependent on each other; and clearly present all the relevant information needed to move forward. Risks? What risks? You’ve got a hold on this now.

Specialis Revelio! ✨

The post Feature Friday: How to Communicate Blockers by Showing Dependencies appeared first on ProdPad | Product Management Software.

Getting the most out of ProdPad + JiraOn 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 that 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 lunch 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 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 specific due dates and deadlines.

For example most of the companies that we speak to these days has 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 to add all these 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 the slower you 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 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 100’s of other companies in this situation.

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

That way you can work on those ideas in ProdPad, make sure they have all the user stories, context, 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 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.

What you can do is when you have an idea you have the choice to push 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, here 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 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 be straight forward but 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 point.

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 through being delivered and 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.

But 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 developers 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 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 from the link provided on the ticket in Jira. Then the would be free to work on that ticket in Jira and ad 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 to 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 spec’d 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</br>On Demand Webinar and Full Q&A appeared first on ProdPad | Product Management Software.

The Perfect Pairing – Trello + ProdPad, on Demand Webinar and full Q&A!

This Valentines we’re crushing on Trello and ProdPad. Why? Because Trello + ProdPad = ❤

Our CEO Janna Bastow & Head of Customer Success Andrea Sáez, hosted a very successful webinar this month. They showed the audience how to bridge the gap between strategy and execution, using ProdPad and Trello.Trello and ProdPadJanna covered:

  • How ProdPad and Trello 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

We were blown away by the number of questions we received during the webinar, so we decided to share them with you!

Q: How do I actually split my backlog if it is all in one tool?

We talk to a lot of people who have backlogs that exist in spreadsheets, trello or these long to-do lists. But finding ways to manage these epic lists can be overwhelming. We recommend starting by asking is this ticket or idea approved? Ready to go? Can a dev pick it up and start working on it right away?

If it isn’t any of the above take it out of your backlog. It’s not ready to push to dev.

Export this list as a CSV or XLS file and import it into ProdPad. Don’t worry you won’t lose any work moving it from one place to the next, but now it’s in a place where you can work on them without confusing your to do development list.

Once these ideas are in your ProdPad backlog you can begin to spec out the ideas to push back into trello for your Dev team to begin working on it!

Q: Where do you log your bugs, in Trello or ProdPad? How can you prioritize it?

We get this one a lot, it’s a good question. A fault is basically a bug. A bug shouldn’t be tracked in something like ProdPad, because a bug is a task to do.

You need to give steps to replicate and find out what’s actually happening and where. It’s one of those tasks that the dev team should be able to pick up and work on at any time.

Once it is in your trello account it’s up to you how you would like to split it up – I have seen people who chose to take a week a month where the team works through the bugs, or those who factor in a set number of story points to work on during each sprint for bugs or tech debt.

It’s not just bugs it can be general dev-ops tasks that need to happen on the technical side that don’t affect the product and don’t need the oversight of the product manager’s – things for the lead dev to organize. A Trello board should be a list of tasks; stories to be built (new features), bugs, faults and that sort of thing.

Q: What are the benefits of using a Trello + ProdPad combo vs. managing these as improvements & story issues in a dev tool like JIRA?

JIRA, like Trello is a great tool for managing individual tasks from build through to completion. But like Trello, JIRA falls down when it comes to managing that big fuzzy backlog of ideas.

In JIRA you might have more than that one column stacked up and down of your priorities, it’s also not the place where your team is willing to go to add ideas, it’s difficult to use someone who is not technically focused.

It often forces you to think about things in terms of features to be done. We all know lots of features do not make good products. So by pulling them out and putting them into something like ProdPad, which is more than just a backlog tool, it connects you to your company goals, and the strategic objectives you have.

It’s also a place where the majority of your team are happy to go and add ideas, which makes the most sense for any business.

Q: Is there an API / SDK to integrate ProdPad and Trello together so there is no manual moving of backlogs?

There is absolutely an integration! It allows you to push items to Trello (or any other dev tool) and we’ll sync the status back so you know how it’s progressing.

Q: Why should my team move from (Clubhouse + Trello) to (Trello + ProdPad) or just ProdPad standalone?

Clubhouse is very similar to Trello and is a development/task management tool, which means you’ll be doubling your efforts into the same sort of tool without having a tool where you can focus on your tasks as a Product Manager like you can in ProdPad.

Q: Opening the product backlog to the whole team can result in a huge/unmanageable backlog… also, people might get frustrated if you never get to their ideas/suggestions. How does ProdPad help with that?

We have something called the unsorted tab, this works as a silo for ideas before they get into your backlog, and it gives you an opportunity to validate those issues and combine those with a couple of workflow statuses.

This lets your team know what your process looks like, what it takes for an idea to make it into your backlog and we are also very big on asking the question what problem are you trying to solve.

So instead of your team popping in to say “the button should be blue” you can understand why the button should be blue which is part of where those issues come from of people getting frustrated. Because they do not supply the product manager with the right information.

We make it easy for people to add ideas to ProdPad you don’t want your team to get frustrated and not tell you when they have good ideas. So they can email ideas, use the chrome extension or our slack bot. These go into the unsorted tab, where you can add basic information and metadata to then sort into your backlog.

We also make sure there are enough tools for Product Managers to manage the unsorted tab one of those tools is triage mode – so you can work through everything really quickly – you can read about that here.

Q: How can you manage the design and UX process through ProdPad?

You could create a workflow status called ‘with UX’ or ‘R&D’ to let everyone know where it sits. All designs and research can be added to the idea as documentation, and then moved on to the next step in the process when ready.

Q: How do you combine related ideas into a single item in ProdPad without losing the original ideas?

We are working on a merge/fork option – is coming soon, it’s on our roadmap under “idea management workflow“! For now I suggest using a workflow status called ‘duplicate’ and using the shortcode #+ID to link to the other idea(s).

Q: Can you create different objectives per product rather than company level?

Coming soon 😉

Q: Why would your product objectives differ from company objectives?

Multiple product lines, multiple products. Some teams have different objectives, depending on what kind of research/areas of focus they may have.

Q: My understanding is that roadmap cards should map pretty closely to your objectives/OKRs. How does that fit with ‘validating’ a roadmap card?

All your cards should be mapped to an objective, that way when you add it to the completed column you can check to see if it worked. It’s one thing to say yay we built that feature, it’s another thing entirely to say – Not only did we build the feature we increased revenue by 20% or reduced churn by 10%.

It’s really important to tie these cards back to your objectives and ProdPad allows you to do that!

Q: Can you track history of development, so you don’t buckle back to a previous problem you have already overcome (lessons learned) and is there a way to track those aspects that require continuous improvement?

That’s where the completed column comes in! Originally when we built ProdPad we didn’t have something like that, and what we found was that people were deleting cards, so when they were done with something they would get rid of it to make way for new cards.

That’s a bad habit we see with a lot of people, for example once they’re done they’ll remove items from JIRA or from their Trello board and just move on to new things. But that doesn’t tell you what worked and what didn’t work – which is why we created the completed column, so you can go back and see.

It’s not just about celebrating your successes, because not everything you built is going to be successful.
Click To Tweet

This is a section to talk about what did work but also what didn’t work, and what you learned from solving those problems. It’s a little bit like being in Math class, you get half the points for just showing your work!

Product managers shouldn’t be judged on just big features, but they should also be capturing this work they’re doing and keep a record of what has worked and hasn’t worked so they can apply that in the future as well.

Completed column

Q: Do you recommend tracking business objectives (e.g. reduce churn) over customer objectives (e.g. easier to collaborate)?

That’s a really deep question, and it depends on what your company objectives are. There is no right or wrong answer it’s just important you have something you can measure.

Reducing churn is much easier to track than easier to collaborate so you might want to expand and tie that back to something you can measure. There might be ways that you can measure that, there are lots of that are qualitative or quantitative – like with anything it is based on what you are trying to get out of it.

So make sure when you are setting your objectives there are things you can say “did we improve this?” I think that’s the key point.

Q: How do you manage customer feedback and how do you decide which ones should become ideas?

The customer feedback section in ProdPad has just about as many controls as the tagging and the sorting and the filtering as the ideas section itself, so you can use that to figure out where there’s groupings.

You can use that to start figuring out how many customers have asked for integrations, for example, and start grouping those. As you do so, it increments the amount of people who have asked for a particular idea in the backlog, so you can see which ideas are wanted by certain types of users.

You can see the same with feedback, for example: show me the requests from large valued customers, or enterprise customers as opposed to smaller businesses.

What you ask and what you do with that information depends on the objectives that you have and what it is you’re trying to do, but we give you all the tools you need to make sense of all that feedback and all of those ideas in your backlog.

Q: How do you prioritize ideas in ProdPad? Can you apply multiple strategies?

There is no silver bullet when it comes to prioritization.

You’ll have a top ten list of the highest priority ideas and you’ll start working on the twelfth – you know that customer will churn if you don’t deliver their request next, or there is a conference next month that bumps something up the list.

That’s why the priority chart within ProdPad is so handy, it gives you lots of ways to cut up and fliter your ideas in your backlog and compare that to what’s in your product roadmap and connect those ideas to the roadmap.

Product Management will always be more of an art than a science, which is why companies need people like us to ask the right questions, so we’re able to build great products!

Customer feedback

Q: Totally love the practice this Trello integration supports – in the past I’ve had to have 2 backlogs, one for discovery and another delivery. Is there a way to capture acceptance criteria/scenarios in ProdPad and link through to Trello?

Absolutely! Each idea has user stories you can add to, and those ideas have a title, description and acceptance criteria. Boom!

Q: The integrations (with JIRA for example) seem to be only mapped to a single dev project. In our ProdPad instance we 6 or so product managers managing suites of products. How can we link ideas and roadmap items to different projects within JIRA?

You can set up multiple Trello boards/JIRA projects. This is totally normal! When you then need to push to development, you select the project and off it goes!

Q: How do you develop an overarching Voice of the Customer framework using ProdPad?

Collecting customer feedback gives you everything you need to create a voice of the customer framework. You don’t want to build a set of features or products just because someone internally has come up with it – you want to be able to tie it back to what the customers have asked for.

Within ProdPad we have an entire section called customer feedback where you can capture what individual users have asked for, then link the feedback to different ideas.

What this allows you to do is understand the context of why someone asked for a feature. For example you could have a group of customers asking for colour coding on tabs and another set asking for hierarchy in tags – at this point it will give you the context that people simply want a way to organize their tags better.

By logging this in ProdPad you can then close the loop, once the feature is built you can contact those users and tell them – hey the feature you wanted is here!

Q: One of the challenges we’ve had with the Trello integration is that the Idea card is often large, and the dev teams break them down into smaller cards. Unfortunately, these aren’t connected back to the big one. How can we handle this case?

Idea cards can start out large – but what we have in ProdPad, is the ability to break those big ideas down into individual user stories. By creating user stories you turn the big idea card into smaller spec’ed out chunks which can become manageable development tickets.

Ideally if you are following basic sprint rules you shouldn’t be pushing in tasks that take longer than a couple of hours, If you find that an idea is too large to tackle it might represent a larger release which can be converted into smaller user stories.

The good thing about user stories is that they are actually connected to ideas and you either can push the whole idea over with all the user stories to development, or you can actually take individual user stories over to dev. Let’s say you have 20 user stories attached to an idea you can take five of those and push them to the Trello board to be worked on and validated, then you can push the next five or ten or whatever else you need to do to complete the full idea.

User stories can be used to break things up into smaller pieces and you can continue the flow over to Trello where you have a nice easy task list ready for your developers to tackle within the next sprint.

Q: Is there a way to keep updated tracking for those aspects that require continuous improvement from the workgroups?

The integration works well with that! Remember that product is about strategy, not execution. You can absolutely keep an eye on how things are progressing with Trello, getting a view from ProdPad. Roadmap cards then act as a container to understand why those items are in continuous development and how it maps to your overall strategy.

Q: We use ProdPad and Trello together. Everything works fine on the first spiral of Product Definition and when we start moving the tasks to Trello for development. The challenge starts occurring when changes to the idea start coming up as a result of the development. Any tips on that?

It’s not uncommon for an idea to be pushed to Trello, and as the developers are working on it in their sprint they’ll still have questions. Typically speaking, the idea should now be broken down into something smaller, sizeable and estimable, which is something that ideally they should be able to ask you as the product manager directly so they can work on them.

Sometimes they’ll get partway through a sprint and realise it was a bad idea or it doesn’t have enough specs or details, and that’s normal too! It happens to the best of us. At which point you have the option of either pausing that one and going back to the idea in ProdPad and spec it out and redefine it and see if it is still a priority. If so, you can press a button and send it back to Trello again whenever it is they have the time to pick it up again perhaps next sprint.

It is not uncommon for things to stop, there is always going to be a fuzzy line between product and development, but having these two tools allows you to communicate between quite easily between them, while making sure that what is going into Trello is more actionable than what typically exists there.

Q: How can we give engineering leads the ability to “score” ideas (costs) without giving them full editor status (roadmaps, etc, etc)?

Reviewers cannot score ideas or make any changes, that would require an editor status.

Missed the webinar? Watch it now.

We were really excited to see so many of you on the webinar, as you know it was focused on how ProdPad and Trello work together. But there are a lot of tools that manage development so for those of you who asked we will be doing a JIRA integration webinar this is likely going to be in March of this year. VSTS was also suggested so watch this space.

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 The Perfect Pairing – Trello + ProdPad, on Demand Webinar and full Q&A! appeared first on ProdPad | Product Management Software.

Trello vs. ProdPad: How They’re Different and Why You Need Both

If you’re using Trello already, you might be asking “Trello vs ProdPad? What’s the difference? Why do I need them both?”

Good question, and one we can answer because we use ProdPad and Trello together to build our own products!

Push to TrelloIt’s not a matter of one versus the other.

They each solve completely different problems: ProdPad helps you figure out your product strategy – what to build and why, while Trello takes over to help your engineering team build it well – the execution.

A good development process focuses on execution. It should give your developers the autonomy they crave, but it shouldn’t overwhelm them with an untidy backlog of half-formed ideas and not-yet-approved specs.

This is where Trello excels.

Almost every development board on Trello has some variation of the Doing, Testing, and Done columns. As long as you’re watching Work-In-Progress (the number of cards in each column at any time), work will progress pretty smoothly. The visual board makes it easy to see where things are getting stuck.

But what about that ever-growing list of things piling up in your “To Do” column?

Left unattended, it’ll grow and grow, and make it harder to make informed decisions on your priorities. It’ll also muddy up your developers’ ability to clearly see what they need to work on next.

We’ve seen some… creative… ways to keep it from getting unwieldy, from tags to extra columns, but the reality is that your product backlog is more than an ordered list of cards.

If you want to make sure you’re building the right things, you’ll need a better space to manage your product backlog.

Separating Strategy from Execution

How do you track customer problems? How do you manage the influx of input and opinions coming in from across your organization? How do you handle business and revenue objectives that influence your priorities?

ProdPad picks up where Trello leaves off: managing the complex and tangled interests of customers and stakeholders while keeping you on track to meet your product vision.

It gives you the tools to answer questions about the future of your business:

  • “What problems do we need to solve?”
  • “What should we work on next to move this metric?”
  • “What’s our long-term strategy?”

ProdPad helps product managers identify where to take your product next, Trello helps teams execute the plan. Keeping these functions separate means you’ll be better at both.

Separate strategy from execution

Follow this rule of thumb: Every card in Trello should be an actionable and approved task, ready for a developer to pick up and move to the Doing pile.

As for all of the things that are still being spec’d, validated and approved?

Keep that separate. You’ll need to size up your backlog in a variety of ways in order to make informed decisions on what gets built next.

After all, if we were, to sum up the role of the Product Manager, it’s to be the person who decides what to prioritize. Not by making blind decisions based on their own opinion, but by asking the right questions and weighing up all options.

And there’s a lot of things that will influence what goes next.

There are things in your backlog that might be important to your product vision. There are things that will move certain metrics that will mean you hit your company objectives. There are things that your customers are asking for all the time. There are things that’ll get you revenue, or user growth, or a more stable platform to build on.

You’re never going to sort through all of this in one narrow list of cards.

Instead, use these two approaches to figure out what goes next: the roadmap and the ideas backlog.


Trello is great for tracking progress at the feature level, but you’ll need a roadmap to tell the bigger story of your product strategy. Your roadmap will shift in granularity and scope as it goes further into the future, represented as the time horizons. We like to call these Current, Near term, and Future.

Current, Near term and Future

In each of these columns, you’ll have roadmap cards. Each of the cards on your roadmap represent high-level initiatives or projects. These are at a higher level than the Trello cards in your development board that represent features or stories. Instead, your roadmap cards in ProdPad will actually contain links to the Trello cards encapsulated in them!

Think of these roadmap cards as problems to be solved. Each of these cards might have a number of linked ideas or specs, representing features or experiments that will be created to try to solve the problem.

Since the development process of coding, testing and releasing is just a small part of the overall product management flow, most of what’s happening in your Trello board will be represented by cards in your Current column.

Completed Column

The Near term and the Future column will contain cards that represent initiatives further away on the horizon, that’ll be validated and broken down into more detailed specs later. The Completed column will contain cards that represent projects that have been completed and released. On your Trello board, these will have been archived so your development team can focus on their current and upcoming work, but we all know that just because a feature has been released, it doesn’t mean it’s proven to solve a problem. You’ll keep tracking these projects in order to validate whether they worked or not, and capture your findings in the Completed column in your ProdPad roadmap.

This time horizon format is essential to agile roadmapping:

“Breakthrough products don’t come from thinking small. They don’t come from the fear of losing ground, either. They come from thinking big and responding to change better than everyone else.”

Now, of course, you can’t just work right from your roadmap. While it’s great for giving you oversight and keeping your team focused on the vision, you’ll still need something to help you spot new opportunities that might affect your strategy.

For this, you’ll need to look at your backlog.


Here’s where a lot of people get confused, because ‘backlog’ is a broad term. Let’s differentiate:

Development backlog

The stack of specs that are ready and approved for development, and are just waiting for someone to start building. This backlog should be relatively short and tidy, and will live in a Trello board in a column called Queued for Dev, or similar. Its input will be prioritised, ready-to-go specs from your roadmap, pushed directly over from ProdPad.

Product backlog (or Opportunity Backlog, as Marty Cagan calls it)

The list of all of the things you could do in order to build the right product. Naturally, you’ll never complete everything on this list, but it’s chock full of insights and opportunities for product innovation. Its inputs are far-reaching, from customer requests to suggestions from the team to insights from experiments and prototypes, and more. This backlog is the one that lives in ProdPad, ready to be sorted, spec’d and signed off by the product team. We call them Ideas.

The Ideas list in ProdPad forms the product backlog. You can view this list in a standard List View, great for straight sorting and quick triaging, but you might prefer a more holistic view of the backlog.

Take a step back and look at the Priority Chart view of your backlog.

Idea Chart

The Priority Chart communicates key details about your backlog quickly.

Just from a glance of this chart, you can see:

  • How well spec’d out the ideas are (size of the dots)
  • When they were last updated (color of the dots)
  • How do all ideas relate to each other in terms of impact and effort (placement of the dots)

This is all based on data you’re collecting for each product idea, so you can query your own backlog and filter down to answer questions like:

  • What are all the product ideas submitted around a certain area? (e.g. onboarding, checkout process, analytics, dashboard)
  • Which ideas haven’t been looked at in a while?
  • Which ideas have high-value customers indicated are valuable to them?

For example, if you want to find the ideas that are most popular with customers, you can narrow down your backlog to a list of those ideas. If you want a list of the newest ideas that customers are interested in, you can pull up an even narrower list.

That ability to nail down problem areas quickly, and identify matching ideas from your backlog, is essential to deciding what needs to be prioritized on the roadmap.

Your window into the development pipeline

Your product is made up of more than just your product and engineering teams. You have marketing, customer support, sales and many others who are responsible for supporting the business.

Each team has a stake in the product: they submit ideas, hear complaints and suggestions directly from the customers. They want and need to know what is going on within the product and development team. But for someone who’s not in engineering, the Trello development board can be confusing and overly complicated.

After all, most Trello boards have more than Doing, Testing, Done. There’s often a multitude of different steps in between that are crucial for the developers to track, but actually don’t impact the rest of the business.

By having the wider team adding their needs to ProdPad, they can focus on what’s important, explain the problem, and back it up with customer feedback and any other screenshots or data. This helps build a full picture for the development team to work on.

And as the Trello card moves through the process, the status reflects back in the unique ProdPad Workflow view. In this view, everyone can look up the status of the ideas they care about, including the ones that are already in Trello. By mapping the statuses of your ideas in ProdPad to your cards in Trello, you create a window into your development process. The options for mapping are flexible, but crucially, it allows you to create a simplified view of the development process, fit for communication with the rest of the team, while still perfectly synced with the progression of the feature in development.

Workflow view

Keep up with what’s going on in ProdPad and Trello

Launching a product or feature successfully requires a great deal of coordination across teams. With this view, your teams can keep up with what’s going on across the product pipeline and access the details as needed.

That knocks out the time you normally spend bringing different teams up to speed. ProdPad is everyone’s single source of truth for what the product team plans to roll out next.

Idea Canvas

It’s by combining the guidance of the roadmap with the opportunities surfaced from your backlog, that you can make informed decisions about what should be built next. These ideas are attached to cards in the roadmap before being sent to Trello for development.

Here’s why ProdPad and Trello are a real dream team

Together you’re able to seamlessly sync your product backlog – now enriched with all the key data points to make the right decisions, and keep an eye on how the project progresses through development.

Your developers get to regain some sanity with a tidier board in Trello, and you have tighter control and visibility of what’s being built, for the right reasons.

With our Trello integration, all you have to do is push the specs you’ve approved to development.

What next?

Trello and ProdPad are not in competition, they are a perfect partnership of strategy and execution.

Trello boards are great for developers, as they need to manage the day-to-day flow of stories, bugs and tasks in progress – it’s their essential task manager. ProdPad is designed by product managers for product managers, allowing you to focus beyond just execution of tasks, but on the big picture.

That’s why, like hundreds of other companies, you should use both. It gives you access to a brand new range of functionality, without disrupting the development process you already have in place.

Additional functionality:
  • Customer Feedback
  • Priority Chart
  • Stakeholder Management
  • User personas
  • Design annotations and versioning

Our free Trello integration is one of the most popular integrations on our platform – and it takes just minutes to set up. Sign up for a free trial today!

The post Trello vs. ProdPad: How They’re Different and Why You Need Both appeared first on ProdPad | Product Management Software.

What 7 Product Leaders Want You To Know About Phased Rollouts

“Ship early, ship often” is the kind of mantra that that makes launching new products seem almost intuitive. Launch first, iterate later; move fast and break things.

But if what you’re taking on is big and cumbersome – updating from older technology to a new codebase, for example –  that kind of advice has never really cut it.

When we surveyed a handful of experienced product managers, we found that when the stakes are high, they’re busy answering bigger questions:

  • “Is the cost of taking significantly longer to roll this out worth the time we lose in market?”
  • “Are customers willing to sacrifice having an incomplete solution when there is a promise of more to come?”
  • “Are there any potential downsides to not shipping the whole feature at once?”

And when an important new feature is too big to fit neatly into one complete release, they start planning a phased rollout. continue reading

Finally, A Customer Feedback Tool Product Managers Want

Last week, we made our first entry into the world of customer feedback with our new Customer Feedback Portal. It’s gotten quite the welcome!

Until now, we’ve been hacking away on product planning tools for product managers: Build a product roadmap! Organize your product backlog! Find your priorities! That sort of thing. But a customer customer feedback tool was never really part of our plan.

“There are lots of tools out on the market,” we told customers who were requesting it. “The world doesn’t need us to make another customer feedback tool.”

But still, our customers kept turning up a few weeks later to ask for the exact same thing.

Why? Once we dug in, we realized the product managers we were talking to had exactly the right instinct. These tools weren’t made for them.

Even at $500 a month, not one of them is designed to help answer the most important question in the product management process: “What should we work on next?”

Prioritization is what keeps product managers up at night – and it’s exactly where every customer feedback tool we’ve seen comes to a dead end.
continue reading