Definition of a product backlog

The product backlog is the grand strategy for the product development war. It’s an ever-evolving list of features, user stories, enhancements, and bug fixes that represent the collective vision and direction of your product.

This list isn’t etched in stone; rather, it needs to be dynamic and you have to adapt it over time as the product evolves. After all, no plan survives contact with the enemy! It’s a list of what your team could work on to make your product better. The Product Owner is typically the guardian of this backlog, prioritizing items based on their strategic, business, and user value.

The key to a successful product backlog is clarity. You should describe each item in a way that anyone, regardless of their technical expertise, can get their head around. These items can be anything from high-level epics (or Ideas in ProdPad), which represent significant product features, to detailed user stories, which break down epics into smaller, more manageable pieces.

Definition of a sprint backlog

If the product backlog is the grand plan for the whole Product team platoon, then the sprint backlog is the battle plan for your crack dev squad on the front lines of each sprint. It’s a tactical to-do list that emerges from the product backlog. It outlines the specific tasks and activities that the dev team is planning to execute during the next sprint, which typically lasts between one to four weeks.

The sprint backlog serves as a plan of action for the upcoming sprint, guiding the team’s efforts and defining what “done” means for each task.

During sprint planning, the Development Team collaboratively selects a set of user stories or backlog items from the product backlog to work on during the sprint. They break these items down into tasks and estimate the work involved. This detailed planning ensures that everyone understands what needs to be done, helping to avoid confusion and keeping the team on track.

What are the key differences between product backlogs vs sprint backlogs?

To put it simply, the product backlog’s focus is to “build the right thing”, while the sprint backlog’s focus is to “build the thing right”.

The product backlog is the Product team’s space. This is where the Product Manager, the Product Owner, the Development team, the Design team, and the UX team do their discovery and validation to figure out which of these things are the right things to build.

Then the sprint backlog is more about execution and delivery than discovery. This is the Development team’s domain. So you’re going to have either a Lead Developer, a Scrum Master, or even a self-led Dev team owning this space.

What is the purpose of a product backlog?

Firstly, your product backlog provides a clear product vision. The main purpose of this backlog is to provide a clear direction for the product’s development and ensure that the team is working on the most valuable features at any given time.

Practically speaking, it’s a repository of ideas, requirements, and feedback from stakeholders and customers, making sure everyone’s on the same page regarding the product’s long-term goals.

It helps to encourage transparency by making your product’s priorities and development direction visible to the entire team. It also should work as a flexible tool that allows you to continuously refine and adapt your approach, ensuring your product stays on target as market conditions and user needs change.

Ultimately, the product backlog is there to support better decision-making by helping the Product Owner to make informed choices about what to build next.

As it’s so important, you want to keep your backlog tidy and well-optimized with good, relevant ideas. This is done through backlog grooming, which you can do effectively in a backlog refinement meeting.

What is the purpose of a sprint backlog?

The sprint backlog is all about the nitty-gritty details of the development process. Its primary purpose is to guide the Development team during the sprint, ensuring they have a clear plan and know precisely what tasks to tackle.

It provides a sense of focus and direction for the team’s efforts, helping them make progress incrementally. The sprint backlog also promotes collaboration and self-organization within the Dev team, as they collectively decide how to achieve the sprint goal. It’s a commitment to completing specific work within a set timeframe, and it helps measure progress during the sprint, making it evident whether the team is on track to meet its goals.

Who creates them?

Product: The product backlog is typically owned and managed by the Product Owner. They work closely with stakeholders and customers to gather input and prioritize items. It’s the Product Owner’s responsibility to keep the product backlog in good shape, ensuring it aligns with the product vision and market needs.

Sprint: The sprint backlog is often collaboratively created by the Development team during sprint planning. The Development team, often guided by the Scrum Master, selects items from the product backlog and breaks them down into tasks. They estimate the work and determine how much they can commit to for the upcoming sprint.

When are they created?

Product: The product backlog is a living artifact that evolves over time as your product develops. It’s continuously refined and reprioritized to accommodate changes in market conditions, user feedback, and business goals. It is usually created before the first sprint takes place, and items selected from this original product backlog will be selected for that initial sprint.

Sprint: The sprint backlog is created at the beginning of each sprint during the sprint planning meeting. Once defined, it generally remains relatively static throughout the sprint. This ensures that the team remains focused on the sprint goal and doesn’t get distracted by new requests or changing priorities in the short term (unless, of course, they are incredibly urgent life-or-death problems).

What types of tasks are included?

Product: The product backlog contains high-level Ideas and user stories, focusing on the overarching goals and features of the product. It emphasizes the strategic value of each backlog item and their alignment with the product vision.

Sprint: The sprint backlog is made up of granular tasks and activities, breaking down selected user stories from the product backlog into actionable steps. It emphasizes the tactical importance of each task for the successful completion of the sprint goal.

What is the scope and priority level of each?

Product: The product backlog has a broad scope, encompassing the entire product vision and long-term objectives. It prioritizes items based on their strategic importance and potential value to the product.

Sprint: The sprint backlog has a much narrower scope, concentrating on the immediate goals and objectives for the current sprint. It prioritizes tasks that are essential for achieving the sprint goal.

How do you estimate the work to be done?

Product: Estimation in the product backlog focuses on high-level estimates, considering the complexity and strategic value of each backlog item. These estimates provide a rough understanding of the work involved.

Sprint: Your sprint backlog demands more detailed estimates, as the team breaks down user stories into tasks. These estimates help the team understand the work involved more precisely and plan the sprint and its associated tasks accordingly.

How is progress measured?

Product: The progress of the product backlog is measured in terms of overall product development and value delivery to the end-users. It tracks how the product evolves over time, how well it aligns with the market’s needs, and how effectively it achieves the product vision.

Sprint: The progress of the sprint backlog is measured within the sprint’s timeframe. It tracks the completion of tasks and the delivery of committed user stories at the end of the sprint. This ensures the team stays on course to meet their sprint goal and commitments.

How do you effectively use a product backlog and sprint backlog together?

The best thing that you can do is to keep them separate, and integrate them together using a tool like Propad. This way, you can have your backlog in a place where the rest of the team can see it and benefit from it.

Your Developers can see what’s coming up the pipeline. You can push things to development when they are approved and ready, and you’re not clogging up your product backlog with stuff that isn’t ready.

One of the things that ProdPad does so well is taking the weight off of project management tools like Jira and Azure. Jira, for example, is a great tool that gets weighed down when it’s filled with a whole bunch of stuff that it’s not good at handling.

ProdPad helps by separating them out, allowing Jira to be good at what it’s good at – task management. That gives your Devs a space where they can relatively autonomously pick through that list of 20 or 50 items in their backlog, and they can work through it as quickly as possible.

The product backlog also often includes things that have moved their way through development, but need to be validated after the Devs have done their work. You need to check that the target outcomes that were outlined in the specs meet the actual outcomes.

This is another way that ProdPad can help to smooth the process – it sits both upstream and downstream from tools like Jira, pushing tasks to development and then collecting feedback and outcomes once the Devs have done their thing. Then you can keep iterating on your work until it’s ticking all the right boxes.

Benefits of using both backlogs together

Together, a well-maintained product backlog and an intelligently managed sprint backlog provide a structured yet flexible approach to product development.

The benefits of having separate backlogs and using them together include:

• Strategic and tactical alignment: The product backlog ensures strategic alignment with long-term product vision, while the sprint backlog keeps the team tactically focused on immediate sprint goals.
• Adaptability: The product backlog allows for continuous refinement based on changing market conditions and customer feedback, while the sprint backlog enables quick adjustments and course corrections during the sprint.
• Efficient communication: The product backlog fosters open communication among stakeholders, the Product Owner, and the Development team, while the sprint backlog encourages collaboration and shared understanding within the development team during the sprint.
• Transparency and accountability: The product backlog promotes transparency regarding the product vision and priorities, encouraging informed decision-making, while the sprint backlog nurtures a culture of accountability and ownership within the development team.
• Holistic approach: Integration of both backlogs creates a balanced approach, combining long-term strategic objectives with short-term tactical execution.
• Quality assurance: The combined insights from both backlogs ensure that the team delivers high-quality products that both meet customer expectations and adapt to evolving market demands, promoting customer satisfaction and retention.
• Efficient resource allocation: Using both backlogs together optimizes your resource utilization by helping you to focus on high-value product features that have been properly validated and spec’d out before the Devs start to work on them.

Product backlog vs sprint backlog – Divide and conquer!

Hopefully, you’re now persuaded that the smart approach to your backlog is to split it up into more manageable chunks. It’s the best way to avoid the dreaded ‘graveyard of ideas’ and to keep your processes flexible in the face of an ever-shifting market.

ProdPad is a really effective way to manage your product backlog, both before and after you send items to the Devs to work on. It keeps things tidy, manageable, transparent, and most importantly, understandable. It can help you collect all of your feedback and related ideas and attach them to the initiatives in your backlog, to help you choose what to work on and when.

However you do it, though, you need to look at separating your backlog. Really, it’s not so much about product backlog vs sprint backlog. They’re complimentary pieces of the same puzzle, the top-down and bottom-up views of the work to be done. Use them well together, and you’ll give everyone a space for their work to breathe.

The post Product Backlog vs Sprint Backlog – The Grand Strategy and the Battle Plan appeared first on ProdPad.

What does a good product roadmap look like?

The litmus test for a good product roadmap template to start from is that it’s visual, accessible, and clear. Anyone should be able to scan it and find answers to the following questions:

• What are we doing?
• Why are we doing it?
• How does this tie back to our OKRs?

This is the fundamental idea behind a theme-based product roadmap – and its benefits are enormous and immediate. It will help you be able to:

• Have way fewer meetings – Your priorities (what and why) are clearly documented on the roadmap. You don’t have to explain things differently to different people.
• Foster healthy team debates – Your roadmap can be the reference point team members use to challenge themselves and one another to link their deliverables back to roadmap goals and OKRs.
• Make product decisions everyone understands – You’re no longer the bad guy batting down ideas. You can actually discuss customer feedback and ideas through the lens of your roadmap and priorities everyone can see.

In the words of product discovery coach Teresa Torres:

“We need to let go of the idea that we can enumerate a list of features that represents what we’ll do in the future. This idea is absurd. Rather than sharing feature lists with the rest of the company, we should be communicating how we will make decisions.”

A theme-based roadmap is designed to do just that: communicate problems to be solved and open up the conversation around how to solve them. 

If you want to dig into this more, I recommend checking out our CEO Janna Bastow’s excellent presentation on using your product roadmap as a communication tool.

Start with this theme-based product roadmap template

You’re probably already familiar with feature roadmaps – they usually look like Gantt charts or release plans. These are useful for planning projects, but they don’t communicate the big picture very well.

Our theme-based roadmap of choice, the Now-Next-Later roadmap, replaces that with time horizons, made up of three columns:

1. Now: Stuff that you are currently working on.
2. Next: Stuff that’s coming up soon.
3. Later: Stuff that you’d like to work on in the future, but need to do a bit more research before you move on.

Note that we aren’t showing any timelines. This is not a release planner, it is a bird’s-eye view of your priorities. Those are always subject to change – there’ll always be something that happens in the future that you can’t meaningfully plan for today.

The point is to leave room to adjust to change. If something you’re working on was current but now you want to push it back, you can.

Define Initiatives for your roadmap

Themes are “a promise to solve problems, not build features,” says Jared Spool, founder of User Interface Engineering.

The idea behind Initiatives is that it’s better to tackle the root of the problem with a single, elegant solution than burden yourself with a growing laundry list of features. You should be working at the problem level, asking what you can do to solve specific issues, rather than plotting out what feature to build next, just for the sake of having a feature to build next.

Developing initiatives for your theme-based roadmap enables you to define priorities in terms of problem areas, which are things that everyone can understand. It also enables you to actively incorporate the daily flow of customer feedback into your product planning.

For example, if you’re getting a lot of feedback for Single Sign On, then now’s not the time to drop everything and build 10 new ways to sign into your app. Rather, it’s time to set up a new roadmap card (like the ones you see below) and start pulling all this feedback together to help you explore the best way to start solving this problem (Fun fact: ProdPad’s AI assistant can help do this for you!).

This enables you to communicate with your company that you’re aware of the problem and that you’re thinking about it, but you don’t have to provide anyone with the exact solution at this stage.

Each of the following roadmap cards represents an initiative except the last one.

Why has the last one been crossed out? Because roadmap cards should always be strategic, not tactical. “Rewriting transactional emails” is too specific to be a strategy. It’s a task rather than an initiative.

At this high-level view, those are details you don’t have to worry about yet. Save the granularity for when you get into the details of each card.

Build the case for each Initiative

Once you have your Initiatives down, you can attach more supporting details for anyone who wants to drill further down. These details help us strengthen what we’re putting on our roadmap, which again, could include useful information for those reading it:

• What are we doing?
• Why are we doing it?
• How does this tie back to our OKRs?

Internally, your team will have access to detailed information which will help prepare them and guide them through your workflow. These details include:

• Ideas – Tactical suggestions for improvement. These ideas answer a simple business case: What problem are you trying to solve?
• Customer feedback – We attach feedback directly to ideas in ProdPad, so they can be linked to potential improvements and we can easily track what our clients are asking for.
• User stories – Use case scenarios for ideas: As a user, I want to X in order to Y.

Cards sitting in the Later column don’t have to have all those answers yet, but as a card moves closer to the Now horizon, they should become a lot more detailed.

Assemble Initiatives into a product strategy

As you build your theme-based roadmap, you can color code and tag them to allow the viewer to sort through and filter down based on a particular interest. Kind of like you do with Post-it notes!

How about that basic usability, huh? This keeps it visually easy and engaging, and everyone will be happy you didn’t make them sort through herds of cards to find what they came for.

Instead of staring blankly at one big roadmap, your colleagues can focus on the ones that are relevant to them.

Now tie it all together with ‘The Guide to Roadmapping’

Cool, nice roadmap! But what do you do with it? Our CEO, Janna Bastow, gave the most comprehensive talk out there about how you can introduce your new product roadmap template across your business. It’s just 20 minutes – a perfect companion to the flexible roadmapping method you’ve just learned.

We’ve also crafted a free course which takes you through all the steps to move your organization from a timeline roadmapping approach to a Now-Next-Later theme-based roadmap.

And to really get the job done, we’ve even created a ready-made presentation deck that you can download and present to your stakeholders to convince them that moving to a theme-based approach is better for business!

Start building your new theme-based roadmap in ProdPad

Hit the button below to start your free trial today! Discover how to build a product roadmap in a tool that’s designed by product managers, for product managers.

Start your free trial

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

The post Theme-Based Product Roadmaps: Something Everyone Can Understand appeared first on ProdPad.

I’ll be honest with you: this is not a good practice. (In fact, it’s #5 on my list of roadmap things to avoid.)

The roadmap is not a list of things that you will do. It’s a list of things that you could do.

More than anything, it’s an experimentation tool – a place to lay out the solutions that you can test, in order to address the most important problems facing your company.

Once you’ve identified the main problems according to the business’ OKRs, then you brainstorm potential solutions. There are usually many, varied paths toward your goal. Each problem could have 5 to 10 potential solutions attached to it. Narrowing them down and selecting the best one requires experimentation.

The product roadmap records what these experiments are, how they’re going, and what’s been learned.

All of your ideas are hypotheses

All of your ideas are hypotheses, and as a PM, your job is actually to invalidate most of them! That said, product ideas don’t pop out of the blue, and your hypotheses aren’t created in a vacuum.

Product ideas are derived from OKRs, top-level objectives that are defined by the business. The product team sets out to solve a problem around churn, retention, revenue, etc. For example, as a PM you can say, “Okay, the problem we’re tackling this month is — we need to get conversion rates up, and the issue is around our sign-in flow area. We need to move people into the purchase flow. How can we do that?”

From there, you might brainstorm three to ten different ideas or potential solutions. Some will succeed and some will fail – that’s a fact. But you don’t know which ones until you test them. And to test them effectively, you need hypotheses.

How to phrase a product hypothesis: If we [try this idea], it could solve [this problem] and it could uplift [this metric] by [N].

Cool, that’s the experiment to run! Then you see how the new feature performs and take steps from there. But while we’re here, a quick note about new features…

What counts as a potential solution? Think wider.

Product solutions aren’t necessarily new features. What about changing a feature – or even removing a feature? Either of these might improve usability or impact other metrics and objectives that you’re working toward.

Some solutions might not involve code at all! The trick could be changing the price or the packaging or the value proposition. Shift how you talk about a benefit on the homepage or rethink how you present certain information to the customer. Adjustments like these can transform the way people interact with your product – which, in turn, could solve some of the problems on your product roadmap.

The point is: experimentation doesn’t always require the development team. Instead, it might require marketing, sales, customer success, and support. PMs should take a step back and think more holistically about what it is they’re actually solving so that the rest of the team can be involved as well.

What counts as a product roadmap experiment? Think leaner.

Again, by “experiment” I don’t necessarily mean build full-on code. Experiments can also be fast litmus tests to check what’s viable or not before devoting any real resources to it. There are many ways to do customer decision discovery, do quick prototypes, and put in place little tests. It could even be a prototype on paper that you test with select customers. 

As you do these tests, you identify the experiment options that you think are going to be easy, the low-effort, high-impact ones, and float those to the top. Work through the list and see how close you come to solving the problem. 80% is close enough. Move on.

Most importantly, record everything.

The product roadmap is a record of learning

As a product team, one of the most important things you can do is log your decisions – for future you and future team members who join. This starts with each of your tests.

Logging experiments in the roadmap

You can use the product roadmap to display how you’re actually progressing with experiments, such as:

• This one is something that we’re still discovering. 
• This one shows promise, and we’re going to do some design prototyping. 
• This one failed.
• This one was successful.

But for any idea that you have, which is to say any experiment that you’ll run, you should also log your target outcomes along with the actual results. This is crucial for understanding the solution’s viability at the moment, and it also helps prevent repeating any work (or mistakes) down the line.

Let’s say there’s a delta between expected and actual outcomes, such as, “We thought Idea X would get us 100 new users each month, but it actually only brought in 20.” Well, obviously you won’t move forward with Idea X right now. And this result is recorded in case the idea comes up again.

How to preserve what you’ve learned

ProdPad is basically a log of all the decisions made and all the lessons learned over time. In addition to your working product roadmap, which is in the Now-Next-Later format, you also have a “completed roadmap.” Any initiatives that you’ve completed are shown, in reverse chronological order, with all the experiments that were attached and how well you did with them.

After all, a product manager’s impact isn’t just features that they’ve built. It’s also the problems they’ve tried to solve and the experiments they’ve tried to run, whether they worked or not. Designers have Behance, developers have Github. What do PMs have? That’s one reason we created Prodpad.

Set the stage for product roadmap experimentation in your team

Want to encourage this approach among your colleagues? Shifting to experimentation mode requires changing the language that you use. Here are a couple of ways to help your team embrace experimentation:

1. Continuously reframe conversations that become too feature-focused or committed to one solution. An excellent reframe is to ask: “What problem are we trying to solve?”

Ask these sorts of questions and give them time to think things through. Give them space to talk through how they might solve a problem. This requires vulnerability and some psychological safety among the team, so they can let go of needing to be right. This brings us to…

2. Talk about ideas as “hypotheses” or even “bets.” This invites people to get into that scientific, almost playful mindset.

Failed hypotheses and lost bets don’t really exist in product management, because you’re always learning something from the experiment. Besides, you aren’t trying to prove your idea right. You don’t have the answer, and no one does! You’re trying to find answers as a team.

The post Your Product Roadmap is a Tool for Experimenting appeared first on ProdPad.

Take advantage of pre-set filters

Needs more detail

These ideas are just one-liners that could be fleshed out further. They probably need a little more detail so the rest of the team understands what was asked. Feel free to @mention colleagues to pull them into the conversation and get their feedback on the beginnings of the idea.

New Ideas Today

These ideas have been submitted in the last 24 hours. They probably need you to have a quick look, add your thoughts, or maybe get it on the roadmap.

Not updated recently

These ideas are at risk of being forgotten. Just have a quick look through at the end of each week. Even if you just add a tag or a comment, or answer something simple like ‘What problem is this idea solving’ in the business case, it’s a good step in grooming your product backlog effectively.

Potential Quick Wins

These ideas have a high impact and low effort. These are the ideas you should consider getting spec’d out and sent to development!

Alternatively, you also have access to create your own filters. If there’s a particular product or trend you want to keep your eyes on, save it as a filter and enter triage mode to decide which items you will be moving forward.

Investing in your product backlog pays off. Not only can you attack this vast repository of ideas with a bit more sanity, but you can shake its reputation as a place where ideas go to die.

At ProdPad we practice what we preach. Great feedback and user stories are at the heart of what we build. Tell us about your routine for taking care of the product backlog in the comments below.

The post Re-Introducing Triage Mode for a Tidier Product Backlog appeared first on ProdPad.

Step 1: Pick a date

Pick a regular time to prune your backlog. We do it once a month – so pick a date and time of day (we recommend a full morning or afternoon) that’s the least likely to get pushed around by other *urgent* needs.

Step 2: Cull it all

This is your turbo-charged attack on your backlog. You’re aiming for a quick, but thorough scan of all ideas to remove or merge irrelevant and duplicate entries. We recommend doing this to an inspirational, powerful playlist.

Step 3: Find the holes

Identify the ideas that are held in stasis because they are missing information. As this is a monthly activity, pay close attention to those ideas you know you haven’t touched during the past month. This might be business case, user case or even a simple detailing of what problem the feature should address.

Step 4: Write up a to-do list

Once you’ve identified everything that needs attention, don’t just leave it there. From the ideas you’ve selected create follow-up tasks and add them to whatever to-do list you already manage. Make these specific and realistic so that you don’t find yourself picking out and noting down the same unfinished backlog chores next month too.

Step 5: Smugly celebrate

As well as actually cracking on with that to do list – we recommend making you REWARD YOURSELF. That was long an arduous thing you just did. When backlog day comes around, make sure you’ve got a treat stocked in the office that you can congratulate yourself with when you finish. Candy. Ice cream sandwich. Whiskey. Whatever floats your boat.

This exercise was taken from the ProdPad Handy Guide for Product People. Sign up for a free trial and request your own copy for plenty more tips and tricks for great product management.

The post The Leanest Way To Organize Your Product Backlog appeared first on ProdPad.

“When is an idea too small?”

The bug reports. The minor tweaks. Are the little things important enough to count as an idea?

I will answer that question with another question: Is the proposed change up for debate?

If it is, you should count it as an idea and send it into ProdPad.

If something just needs to be done and is dev-ready, it doesn’t need to be logged as an idea. It’s not a suggested improvement, it’s a necessary fix. For example, bugs are typically considered a development ‘to do’ item. When you’re simply looking at a broken piece of software that needs to be fixed, this should go straight into the development backlog and be scheduled accordingly.

But when you get into the realm of other “little things”, the question gets a little more complicated. A “little thing” might be a UX fix for something that’s confusing customers, a detail your team realizes really should have been included in a previous release.

Use the following to help you decide whether you should add an idea or just push it straight to development:

• Is there a chance this change will spark a debate as to whether it’s a good idea or not?
• Are you able to provide JIRA with enough information right away for a developer to pick up this task without any further support?
• Can this change realistically be delivered in the next few sprints?

Keep in mind these decisions ultimately come down to how you communicate and how you draw the line between ProdPad and project management tools like JIRA. Questions like these can help you establish a set of guidelines, so important fixes don’t end up waiting for approval in ProdPad.

If you have any insight you can share on the ins and outs of how you manage a workflow between ProdPad and your development tools, drop a comment below!

The post How Small Is Too Small For Idea Management? appeared first on ProdPad.

Surface the timeliest feedback

Your customer support team are the first port of call for your users’ frustrations and challenges. Customer feedback of course might come from many different sources, but here your customers’ most pressing pain points (those they are pushed to reach out to you about) can highlight some of the changes you absolutely must make if you are to keep their business. When customer representatives make use of user feedback capture tools in ProdPad, you can be sure that each of these instances are recorded and that no threatening issue is overlooked.

Delight customers

As well as fixing their pain, good customer service is also about delighting users. When customer service teams and product management teams work together effectively, they can identify new opportunities to delight users with quick product wins. At ProdPad, we ourselves use tags such as ‘fun’ on ideas dedicated purely to making customers happy.

Making use of ProdPad’s features and integrations, it’s easy to communicate those changes back to relevant customers too. A complete feedback loop is made simpler by either recording customer contact details directly against feedback and ideas, or by integrating tools such as UserVoice to automate updates to customers when their suggestions have been taken on board.

Build a workable case

When customer service data is shared with product management, problems can be better solved and value more easily created. But how does this work? If you are to avoid the frustration of customer reps who feel their feedback is going ignored, or the stress of product managers who are bombarded by the same enquiries day in and day out, good process is key.

In ProdPad, user feedback is logged separately from fully formed product ideas. This way customer service teams aren’t limited in the number of times they log a piece of feedback, in fact comprehensive coverage of this important information should be encouraged. Yet in linking feedback to a single product idea each time the issue is surfaced, product managers can avoid repetition and keep track on the traction of an idea in a measured way.  Service teams can help to build a workable case for a new idea and champion their customers’ needs, keeping everyone happy.

[Tweet “Any good product manager should put customer needs at the heart of their daily decisions.”]

If you’d like to find out more about how ProdPad can facilitate collaboration between product management and customer support teams, get in touch for a chat or sign up for a free trial

The post How Product Managers Can Work With Customer Support 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.

Share customer insight

Your marketing team holds important customer insight that can be invaluable in understanding both particular product needs and the big picture of your target users.  Alongside the specific prospect feedback you collect from your sales team, your marketers – specifically any colleagues focused on customer or product marketing – have additional information to share from competitive research to customer interviews.

There are a number of ways in which ProdPad allows them to do so easily – from adding customer feedback and new ideas, to commenting on existing suggestions and even directly on user persona pages. Product Managers can call in marketing opinion at any time using @mentions, and marketers can follow ideas of interest to stay involved in their development.

Support the business case 

Once you’ve found a promising idea, there’s still more work to do before you can start to prioritize. Every idea canvas should have a validated business case to help you evaluate whether the new product or change will merit the resources required.  For certain product developments, marketing will be able to help form commercial objectives, such as awareness or new registration numbers. Accessible collaboration tools are key at this stage where defining – and ultimately delivering on – success criteria is dependent on the involvement of team members company-wide. 

Plan coordinated product launches

Although we don’t believe in fixing specific dates to your roadmap, communication is still key to coordinating product and commercial strategies. As your new products move closer and closer to implementation, the marketing team will have plenty of work to do from press to sales materials. When roadmapping you may wish to attach broad timeframes to ‘current’ and ‘near-term’ products and features so that your marketing team can start to plan out launches for these new releases. As ideas make their way into development, make sure that your marketing team is following their progress. With the help of systems integrations and email notifications, there are no unexpected surprises.

Bring consistency to product messaging

Finally, new and updated products can be supported with marketing-approved resources, all centralized in a single location – your ProdPad product pages. Materials can be uploaded so they can be accessed by your entire team, helping product managers to keep product management in one place, and marketing teams to rest assured only on-message content is being shared externally.

If you’d like to find out more about how marketers and product managers can work together using ProdPad, get in touch with us here

Catch up on how to involve your executive team in product management decisions here, and stay tuned next week for how ProdPad can help you to keep compliance and legal happy. 

The post Product Planning with Product Marketing Teams appeared first on ProdPad.