What is a Product Manager?

If you’re considering hiring a product manager or on a career path for product management you’re probably asking what it’s all about. Or maybe you’ve just landed a job and aren’t sure what to do next? Don’t worry, we’re here to help! 

The job of a product manager is to discover market problems, and then define what should be built within their product to solve these problems. Their goal is to improve outcomes for the people who use their product. They must identify those ideas that should provide value for the business, and then help the rest of the business to turn those ideas into reality. 

Purple Dot is drawing a robot, while Pink Dot is very confused.

Sounds simple enough, right? The problem is that there will always be a wide range of opportunities to pursue, and each one of them will take time, money and effort. So product managers must use their skills, knowledge and the tools at their disposal to help their organization make good decisions about what to do next.

Product managers must ask the questions needed in order to make tough business decisions about new product features or enhancements. Marty Cagan, product management guru and partner at Silicon Valley Product Group, explains that a product manager should always consider value, usability, feasibility and business viability. This means that they should look at the following when deciding what to work on:

  • Will this provide value to our customers?
  • Is this change usable?
  • Can we deliver it – is it feasible?
  • Can our business support this change – is it viable?

The answers to these questions will help the business to decide where to invest in order to get the best return on investment.

What does a Product Manager do?

Day-to-day, a product manager communicates with different people, both inside and outside their organization, either to learn, or to share their learning. This means that it’s important for them to understand the organization’s different business functions, because they must facilitate and broker discussions between technical and business stakeholders. Product managers also need to have conversations with customers and end users of their product, and to be able to communicate at both a strategic and a detailed level, depending on the conversation. Finally, it’s important for product managers to document what they learn as they go, so they can easily use what they’ve learned to make the best decisions.

In general, a product manager is responsible for:

  • Carrying out research on market needs by collecting feedback, reviewing data and examining the market landscape
  • Discovering problems to be solved, based on the research they’ve carried out
  • Identifying the most valuable opportunities for the business – which bets are most likely to pay off?
  • Working with their product team to identify potential solutions to those valuable opportunities
  • Defining what success looks like. For example, what outcomes should be expected, and how can they be measured to assess whether they’ve been achieved
  • Experimenting to determine the most successful solution
  • Measuring success and determining next steps

A product manager’s goal is to provide the best outcomes for customers, with the smallest possible investment. 

This illustrations shows is an interpretation of what is a product manager. Pink Dot has multiple arms, one is drawing, another a roadmap, another a laptop, another a clock, another a clipboard, another a mobile with the ProdPad app login, another a steaming cup of coffee and has a thought bubble above their head thinking about an app.

The day-to-day job

It sounds like a lot, doesn’t it! But there are some key tasks that product managers carry out on a daily basis:

  • Collect feedback on market needs (in person, on zoom, via surveys or via customer-facing team mates)
  • Define the product strategy based on the needs of the market and business objectives – this is known as creating the product roadmap
  • Communicate the strategy to others, and seek to understand how it could be improved
  • Break down the strategy into executable pieces
  • Work with design and development teams to create product specifications
  • Collaborate with customer-facing functions to help with their go-to-market activities
Pink Dot the Product Manager is getting user feedback from Light Pink Dot who loves it, Purple Dot is hopping mad and Grey Dot is very confused.

Product Management vs Project Management

A product manager’s responsibility is discovery rather than delivery. The skills that deliver a successful project – resource management, capacity planning, budgeting – are very different from those needed to uncover opportunities. Product management is not project management – that’s why we also say that a roadmap is not a release plan. In short, a Product Manager defines “what” and “why”, while a project manager defines “when”, “how” and “who”.

What makes a Great Product Manager?

A great product manager brings together a diverse, cross-functional team of people so that they solve a problem. They’re entrepreneurial and know how to to break big problems down. And they can see how to provide value in a way that reduces business risk. They use tools that help them to gain insights and make good decisions. Above all, they’re data driven and are excellent communicators.

If you’re looking for ways to ensure you stay up to date with Product Management best practice within your work start a trial now to see how ProdPad can help you.

The post What is a Product Manager? appeared first on ProdPad | Product Management Software.

What is a Product Team?

At ProdPad, we talk a lot about separating strategy and execution – in fact, in this blog, we call it out as Product Management Rule #1. We know that there is a difference between discovery and delivery, and that the two sides of that “double diamond” involve very different skill sets, met by different people in the product team.

However, there is a danger in creating silos in product development and launch. We have to work out how to ease the transition from inception to real world usage, through every stage, in a way that reduces confusion along the way. It’s natural to believe this requires good project management, and well-defined handover stages, but there’s a better way. You’re more likely to succeed if you work as a collaborative product team including more than just traditional product team roles.

What should the product team structure look like?

We’ve all seen the chaos that can result from a lack of understanding when specifications are handed off from one team to another. There’s an element of “throw it over the wall” that means one team (product management) is finished and the next team (product development) can start.

We see similar issues when development is done and testing/QA starts, and then again when the success and operations teams have to work out how to deliver the new functionality. The problems stem from different functions having different questions about what needs to be done, and a lack of context from other teams. 

A visual representation of a product manager throwing a paper aeroplane over a high wall and a product developer catches it and is reading the note written on the aeroplane.
“Throwing it over the wall”

Let’s think about an example about the product team roles that might be needed. If we’re building a new search function, each team will have different questions.

  • Product Management will spend time on defining the problem that will be solved. Is the purpose to help with discoverability? If so, what value will that provide to the user, and how will building this feature contribute towards the product team’s OKRs?
  • Product Design/UX will want to know who’s using it, and will work with Product to create a user experience that is easy, intuitive and achieves the desired outcome.
  • Product Development will want to understand exactly how the search needs to work in every possible scenario. They’ll need to understand every ‘state’ the UI could be in, the transitions, and any user workflows for interacting with the search bar. They might also want to understand the expected output of the search – is it fuzzy, exact text match or more abstract?
  • QA will want to understand similar information to Development, but with more of a focus on what could go wrong. What will real world usage look like? How could the user encounter problems and how might they be overcome? Does it perform well under pressure or with high volumes of data?
  • Sales & marketing will want to know why people will use this feature, whether there are any pricing implications, what the benefits are, and how they can tell the story of the new feature
  • Success will be thinking about the search in real life, similar to QA, but they’ll want to anticipate what help will be required by the end user. Will they need any training? Are there changes needed to the documentation? How will this change affect existing users vs new users? 
  • Operations will have concerns around how services are delivered and paid for. What will this mean for billing or finance? Will more resources be needed in any way? Does the change affect the way contracts are drawn up?

What is the key to a great Product Team? Collaboration.

The key to the product team’s success is collaboration. When we plan and define a new feature, we need to work with multiple teams to ensure that everyone has a voice. Don’t forget, as a product manager, your role isn’t necessarily to have all the answers, but to ask the right questions

Take it from someone who knows.

Take the time to define the problem being solved. Once you’ve nailed that, you can start asking questions early on.

When leading the product team, a great product manager will ask the Design team to think about how they might design the user experience. They’ll ask the Development team what information they need in order to build the proposed solution. It’s important to have a chat with QA to see what they think might cause problems for the user in real life – get ahead of those problems before they become a surprise. 

Something that’s often overlooked is the need to discuss with the customer-facing folks what solving the problem means for their market, or their customers – how valuable could it be? Could you consider charging more for your product if you solved this problem? How would you position the solution, and what does it mean for your competitive position. Speak to finance and legal about the potential for changes in forecasting, pricing and contracts so they know what’s ahead.

Having these discussions from early in the product process will help to ensure that

  • Everyone knows what’s coming down the development pipeline
  • Each team can get ready for what lies ahead
  • Risk is lowered – you’re less likely to have those last minute panics and changes
  • Launch is smoother

The specifications need to answer any questions which will crop up during the execution/delivery of an idea, regardless of who’s asking the question. Gone are the days of writing up functional and technical specs and thinking you’re done – we need to think about launch readiness and ongoing operations too! 

How does ProdPad help?

Thankfully, ProdPad can help to ensure that the product team roles include representation from every part of your organization, regardless of their role. With unlimited free reviewer licenses, you can open up the product process to everyone to ensure there is visibility into the product roadmap. Discussions, commenting and collaboration features throughout the app means everyone is able to decide what they’re interested in and set their own noise levels.

ProdPad’s integrations with Slack and email mean that conversations can start, continue and reach a conclusion in the most convenient place for everyone involved. Not only that, you’ll get traceability and have a single source of truth for discussions and decisions made along the way – no more going back through old notes to work out who said what.

If you’re about to kick off a new piece of work, have a look at how ProdPad can help you get the best results in the most collaborative way. Get started with a ProdPad trial today!

The post What is a Product Team? appeared first on ProdPad | Product Management Software.

Should Product Managers Say No?

I came across this question in an online product management community I’m part of. Product management is a tough gig – especially when, daily, you have to communicate with multiple teams and everyone thinks their idea is the best solution for making your product better. With stakeholder demands, sales and marketing teams wanting launch dates, as well as your developers coming back to you with more barriers, on the surface at least, I don’t blame product managers for saying ‘no’. 

But despite the hair pulling, the thinking that product managers should say ‘no’ to ideas goes against the grain. A product manager should have the skill set to listen and prioritize ideas that they think will work to solve customer problems. So instead of saying ‘no’, product managers should be focused on saying ‘yes’ to those things that will help make a positive difference, and learn more about the ideas they’re not sure about. 

Saying No Might Damage Your Product Culture

The product team stretches across an entire organization and is very influential. Product managers saying ‘no’ can ultimately have a pretty negative impact on a product and all those involved. This approach inherently teaches the rest of the company that you’re the source of rejecting ideas and suggestions and will have a detrimental impact on your ability to collaborate, manage stakeholders, and engagement with your co-workers. By rejecting ideas or ways of thinking you isolate yourself and your product work. You can forget about those all-important collaborative processes within your company, your customer-facing teams will shy away from you when sharing insights, and your stakeholders will become further removed from your strategy – perhaps even overruling you on large strategic decisions.

Product Managers Should Learn About the Problems, Instead of Saying ‘No’

So what do you do instead of saying no? Easy, focus on how you can say ‘yes’ to the right things:

  • Open up your product process to everyone. Teach everyone what it takes to get an idea from ‘new’ to development. This could involve a product tool like ProdPad which increases visibility over your product development process.
  • On that same path, show everyone what validation looks like. How do you know that working on something will bring success, and how do you measure that success?
  • Have ongoing roadmap sharing sessions. If your team doesn’t understand what problems you are solving and why, it creates more internal friction. When you say yes to things, show why this is.

Boris Krstovic, Senior Product Manager at home goods marketplace Wayfair, also commented on this post about product managers saying ‘no’. His comment really resonated with me and links to what I’m talking about now: 

“Saying ‘no’ is the default for product managers. But the thing is that in 95% of these cases it shouldn’t sound like a “no”. What they need to hear you say isn’t ‘no’ – it’s more along the lines of ‘hey, let’s learn more about it’, ‘let’s cross that bridge when we get there’, ‘how do we support the claim this moves the needle on our objectives the most’, and bajillion of other things.”

When you get a request or someone submits a new idea (no matter how swamped you are) you don’t need to write it off straight away. What might now seem like a bad idea, might not be such a bad idea further down the line – when there are loads of new customer problems that need to be solved. Take the idea and keep it safe in your product backlog, let it be nurtured, worked on, and give it more airtime when you think it might be ready. 

The ideas backlog in ProdPad has three different views to help product managers stay on top of it.
The ideas backlog in ProdPad has three different views to help product managers stay on top of it.

How Should Product Managers Say ‘No’, if They Have To?

The world will never be perfect, even without a global pandemic, so there are a few times when a product manager might need to say ‘no.’ Boris Krstovic sums it up brilliantly:

“Personally, I very rarely say ‘no’. I usually deflect the conflict if there’s a slight chance of deflecting it – 90% of battles aren’t worth battling anyhow, and will just fade away when they find a new shiny object. Of course, a need to have someone back you up when you say ‘no’ is highly dependent on your organization’s culture, and I’ve seen it vary from a very honest and direct communication style (no backup or anything), all the way to extremely political and GoT-ish [Game of Thrones] level 99 corporate diplomacy games.”

Boris Krstovic follows three simple steps which mean he only has to directly say ‘no’ a couple of times a quarter:

  • Make sure you fully understand the other party and their goals. Perhaps your fight isn’t with the one you need to say “no” to, but with their bosses.
  • Always consult with your manager before directly saying no, and inform the team, too. This does not mean escalate, it should be a discussion. 
  • Immediately de-escalate. Keep communication unaggressive and try to sympathize with their need, and potentially offer something that would soothe it.

Try To Refrain From Saying ‘No’

Product managers see the bigger picture. It’s our job to communicate what and why things get prioritized, and how the problems we choose to solve benefit both our customers and our business decisions. Simply saying ‘no’ to things adds friction to team communication. If you’re looking to improve company transparency and make sure everyone is aligned on solving the same problems then try out our product management tool, ProdPad. Explore our free Sandbox to get a feel for how it will help you become a positive, customer-focused product manager. 

The post Should Product Managers Say No? appeared first on ProdPad | Product Management Software.

Six New Year Resolutions for Product Managers

It’s 2021, a new year, a new hope. Here are six new year resolutions for product managers to help you make positive changes for the way you think about product management as a practice and for how you do your job.

Check out our suggestions below, you never know something might help you get your team behind a better way of working, get that promotion you’re way past due, or give you something to talk about at that job interview you’re going to smash.

2020 was a stinker of a year. Look up damp squib in the dictionary, and 2020 is the definition, but there are so many things to make 2021 a much better year.

So let’s dive in and see what new year resolutions for product managers we’ve come up with.

1) Level Up Your Product Management Game

This product management resolution should probably be on your to-do list all year round. It’s super important to look for ways you can iterate and improve – much like you would for the products you’re building. 

“Continuous learning, iterative improvements, and applying a product mindset in more and more situations before you get to an ideal state.” The words from our very own Wes Galliher on how to become a better product manager. You could also make time to upskill and check out some of the awesome training courses our friends at Mind the Product offer. 

2) Become Outcome Focused

If 2020 taught us anything, it is that sometimes, no matter how detailed and researched your date-covered roadmap is, something can come out of the left field and change everything. Why not learn from 2020 and use this new year as an opportunity to take a step forward and become outcome-focused?

Defining clear objectives and key results (OKRs) helps to align your teams around the same set of goals and understand what needs to be built next. Our CEO and Co-founder, Janna Bastow, has outlined ProdPad’s OKRs feature in a handy how-to video.

Aligning your team around the same set of goals should be on your product management resolution list.

3) Make Every Team the Product Team

One of the more important product management resolutions, particularly for those of you working at product-led companies. 

Now with more companies remote working, we need to find ways to fill silos and get everyone working the same way and creating cross-team transparency. “But I am a product manager how can I make big cultural changes?”, I hear you say! Let’s break it down into three parts.

  • Your leadership team won’t want to waste any more time so if they are still on the fence about becoming product led now is the time to show them the light.
  • The product approach should be stretching across all teams including development, product design, and marketing.
  • Get the whole team together (virtually of course) and play the Product Tree Game – it is a great way to get the juices flowing amongst groups.

4) Build a Better Roadmap

It should really go without saying, shouldn’t it? A lean, outcome-focused roadmap is a great place to start when you want to kick-start your product strategy for the new year. 

If you haven’t done so already, jump into our free Sandbox and have a play around with ProdPad’s product roadmap (without having to input your own data). You’ll also find this blog post on how to build a roadmap really useful, too. Or, why not crank it up a notch and have one of our product experts take a look at your roadmap for you by booking in for one of our popular roadmap clinics?

Embracing a lean roadmap should be a leading new years resolution for product managers in 2021.

5) Connect With the Wider Product Management Community

The product management community is a friendly bunch and there are so many great folks out there that you can connect with and learn from. So whether you’re on the hunt for some advice, what to hear about new and improved ways of thinking, or just have a laugh with some classic product in-jokes, please make it one of your product management resolutions to immerse yourself in our community. We’d suggest following these product thought leaders:

  • Our CEO and Co-founder, Janna Bastow, invented the Now, Next, Later roadmap. One of the leading product management influencers, Janna’s not only there to offer sound advice but is a great go-to for the latest developments and approach to the product management craft.
  • If you want to talk and learn about product management best practices then Liz Love is the Twitter account for you. Liz knows the ins and outs for minimizing risk and ensuring you’re thinking about product management in the right way.  
  • If you’re looking to improve your understanding of continuous discovery then give Teresa Torres a follow. Teresa’s account is bursting with insights on how you and your teams should grow your product and ways of thinking.
  • John Cutler is a leading personality in the product community. He shares plenty of advice around product development, as well as high-level strategic thinking and approaches to some of the most complex product management pain points. 
  • If you’re after some social media content from a product leader who also has a real passion for addressing the world’s climate emergency then Matt Stratford’s account is where you need to be. Learn how to save the planet and be a well-rounded product person.

6) Look After Yourself – 2021 Is a Marathon Not a Sprint

Now more than ever, we need to take time to make sure we’re okay. We’ve all struggled in the last year with a variety of worries and losses. In between these new year resolutions for product managers make sure you are taking the time to check in with yourself. Look after yourself because you’re awesome and there is only one you and that’s something to celebrate.

We asked the team at ProdPad what self-care means to them and what tips they would recommend adding in to your day to make sure you’re feeling tip-top and ready to face each day. 

There You Have It – Six New Year Resolutions for Product Managers

Thanks for reading folks! We hope you’ve found this helpful and that it got you champing at the bit to make 2021 a great year. We’d love to hear what you think – if you have any suggestions then sound off in the comments.

Some of these new year resolutions for product managers are easier to embrace with the help of our product management tool, ProdPad. Start a free trial to learn what we’re all about. 

The post Six New Year Resolutions for Product Managers appeared first on ProdPad | Product Management Software.

The Ghosts of Christmas Past, Present and Future for Product Managers

As we approach Christmas, teams everywhere are getting into the festive feeling. But for many product people out there, the three ghosts of Christmas past, present, and future are coming to visit in the guise of tech debt, bad incentives, and timeline roadmaps. Each one comes with a cautionary tale as we enter the new year, and having banished our own ghosts here at ProdPad, we come with tips on how you can banish yours.

The first ghost of Christmas to visit is a ghost from the past: your insidious, shadowy tech debt

The Ghost of Christmas Past – Tech Debt

Tech debt is like any other sort of debt, even financial debt. It’s a fact of life, and you’re always going to have some. But like financial debt, it gets out of hand if you keep stacking it up and never making the effort to pay it off. 

Now, this might seem obvious to anyone with a shred of financial sense, yet it’s often the status quo for how we run our development teams. We give a fixed amount of time for an engineering job to be done, and set expectations on the scope and acceptance criteria. 

Because time is fickle and hard to estimate, we’re always up against a deadline crunch. Parkinson’s Law, which everyone’s very familiar with at least in concept, if not by name, states that work always expands to fill the time given. Scope creeps and procrastination always happens, purely by nature. 

That deadline crunch puts pressure on the developer, and if they’re given a hard choice between making it look like it meets all the criteria (scope ✅) versus making it work as well as it really should (quality ✅), scope usually wins out. After all, it’s the more visible of the criteria, and it’s what the end clients and other stakeholders see. Oftentimes, the missing quality is ‘just’ that the code isn’t as elegant or scalable or reusable as it could have been, or that documentation, tests, or commenting is left out. 

Very often, these are things that aren’t even flagged, and so the project is marked as complete, and work moves on to the next thing, where there’s inevitably another deadline crunch coming. Crunch after crunch like this stacks up tech debt, and it also stresses out your developers, who never get a chance to build to the quality they perceive as good, and never get a breather. 

Over time, your codebase has racked up so much tech debt it needs a full refactor, and your developers have all left for greener pastures. This pattern is doomed to repeat itself, like a ghost from the past, echoing around the hallways. 

To banish tech debt, you need to look it in the eye, and say ‘no more’. No more deadline crunches that force our developers to trade off quality, time and time again. No more building up of the cobwebs in the corner. Once you’ve cornered one of the main sources of tech debt, you’ve got to make it part of your plan to pay it off. If your company aspires to have a product that’s stable and maintainable, and a team that releases frequently and smoothly, you’ll need to make tackling tech debt a strategic objective, and bake it into your new year plans. In practice, this means giving the engineering team some extra slack to dive into problem areas and untangle old code that was previously rushed out the door to make it more stable and reusable. This usually translates into giving some sort of percentage of time towards bug and code maintenance. Tackling tech debt means measuring and acknowledging what you have already, and carving out enough time to pay down the existing problems, while improving processes so that new debt doesn’t rack up in the meantime.

Your ghost of Christmas past might seem scary now, but tech debt can be banished and kept at bay.

Now listen, dear readers, as there are still two ghosts to come. 

As Christmas approaches, the joy jingles in the air. But for some product people, the ghost of Christmas present is creeping around the corner masked as bad incentives. 

The Ghost of Christmas Present – Bad Incentives

Bad incentives are at the core of just about every disagreement and dysfunction you can find in an organization. 

Incentives are what drive people to work. Sometimes these are tangible, and sometimes they are less so. The problems stem from the fact that people have different motivators, and sometimes there are different types of incentives set up for different sets of people within an organization. This leads to all manner of chaos and arguments at worst, or ineffective work at best. 

Sometimes these bad incentives can be traced to the business model itself. Have you ever worked for a company that’s operating more as an agency than a product company, even though you’ve been given a product management role? You’ll sometimes spot these as companies who end up doing lots of custom development work, always that ‘one feature’ that needs to be done in order to complete the sale or retain a customer. You’re the product manager, and yet the sales team is driving the roadmap. In these cases, the business is being incentivized to, and is falling for, short term cash, in lieu of opportunities to build long term value.  

To get out of this agency trap, it’s important to face this ghost head on, and acknowledge the gap between what the company’s goals are (to build a long term, high value product for a wide market) and its actions (selling its people’s time for short term revenue gains). Oftentimes, this problem can be eased by separating the agency side of the business from the product side, allowing agency work to be priced and marketed accordingly, and giving the product team room to spend on discovery, casting a wide net to find and solve the chunkier, more lucrative problems found in the market. Over time, you can decrease your company’s dependence on project-related work, and get rid of this ghost altogether.

The ghost of bad incentives has more than one face, however, and is often seen in our more day-to-day work too. When you’ve got a stressful deadline or project in play, you’ll often see team tension. Very often, you’ll see two people clash. Commonly, you’ll see a developer or product person who’s advocating for quality, and a business person who’s asking for something to be done on time and on budget. These people aren’t clashing because of personal tensions – in fact, they’ll almost certainly share a drink and a laugh together at the holiday party! – they are clashing over misaligned incentives. The development team is measured and incentivized to create high quality work, while the business side is incentivized to control costs while maximizing revenue. Or in the case of a clash with sales, the sales division is under high pressure to close deals by certain dates, and looks to the development team to deliver! Both parties are under pressure to give something up that goes against what they are incentivized to do, and this creates the tension. 

This pressure can be relieved by aligning incentives across the business, up front, before projects kick off, and keeping open communication about what trade-offs can and can’t be made to get to the end goal. Perhaps agreements around only selling what’s currently available can be reached, in exchange for time put towards limited scope experiments that can be used by customer-facing team members to help validate that the right problems are being solved, while showing progress in the right direction. Everyone in the business has the same ultimate goals, but these often get obscured when broken down into individual or team motivations. Getting these out in the open and talking about what levers can be moved and pulled allows everyone to find happy middle grounds that work for the business and for the business, and ultimately, helps your team banish the ghost of bad incentives to the ether. 

Christmas and New Years comes around every year, and with it, comes our final ghost, the ghost of Christmas future: The Timeline Roadmap.

The Ghost of Christmas Future – The Timeline Roadmap

Here we are, standing at the precipice of another year. Another year that countless product people faithfully line up their work to be done, quarter by quarter, month by month, on what looks to be beautiful and visually appealing product roadmaps, their timelines stretching off into the future. 

But these timeline roadmaps are going to come back to haunt them. 

The problem with the timeline roadmap sits within its very core, the format, and that insistent timeline at the top, that’s always marching forward. It means that everything you put on your roadmap automatically has a date and a deadline, whether you explicitly mean to give it one or not. 

No matter how big of a caveat you give, shouting in all caps from the sidebar of your Powerpoint that these dates are not final, these are almost always taken as promises that you don’t want to have to keep.

The problem with making and keeping promises of what you’ll build for the year ahead is that it assumes you know what’s best for your product already, and that nothing is going to change that. If 2020 taught us anything, it’s that we should be ready for anything. Each item tied to a timeline is delivery work, and it’s carved out of your time that you could be spending in discovery. Discovery is where the magic happens. Discovery is where you cast a net wide, and find the most interesting problems to solve, and figure out how your team can solve them in a way that’s profitable for your company. If you’re constantly busy delivering on what you thought was a good idea at the beginning of the year, you’ll never get a chance to look outside and figure out what more interesting problems could be solved. You’ll end up missing market opportunities and building the wrong thing! 

What’s more, timeline roadmap planning is tedious, and results in slower work! For each item you’ve had to put on there, you’ve had to gather estimates of how big it might be, and how long it might take. To be on the safe side, you’ve added a little bit of buffer, so there’s some extra room to fix it up and make it right if you come up short on time. But this is where Parkinson’s Law comes into play again. That extra time given is a self-fulfilling prophecy. Because you gave it extra time, the work actually takes longer than it should! This is why, no matter how much time you give, you always seem to be up against a deadline crunch.  And a timeline roadmap never has one deadline. It’s chock-full of them, one after the other. So wave after wave of deadlines come crashing down. It might be okay in the short term, but the further into your year you go, the more ghastly you realise this timeline roadmap actually is. Every year, this ghost of Christmas future sneaks up on us, and yet every year, we get lured into the trap of creating a beautiful looking roadmap that’s full of promise, but empty on potential. This is the year you can break that cycle. 2021 is the year you can move to a truly lean approach, where you prioritize at the problem level, and focus your attention on hitting your business objectives above all else. At the end of 2021 you’ll look back on the year and see that you completed an enormous number of experiments and solved countless problems, though it wasn’t done by standing at the front of 2021 and drawing an exact timeline map of what that looked like. Your lean, experimentation process is what allows you to banish the final ghost of Christmas future, the timeline roadmap, for good.

Listen to the christmas ghosts and try an outcome focused roadmap to help you solve the right product problems
Try an outcome-focused roadmap to help you solve the right product problems.

The Ghosts Have Spoken

Fortunately, our team of product experts can talk you through these points in even greater detail and inform you how ProdPad can help you bring your product management A-game in 2021. If you’d like to learn a little more, then book a demo. If you feel that the Ghosts of Christmas Past, Present and Future have said enough, then put  what they’ve said into action by starting a free trial today. 

The post The Ghosts of Christmas Past, Present and Future for Product Managers appeared first on ProdPad | Product Management Software.

Avoiding the Feature Factory: How to Measure Product Success

Why do we need to measure product success?

We may keep hearing the phrases “feature factory” and “build trap”, but what do these terms really mean and why is measuring product success now such a key part of the product management process?

For some product teams, the product roadmap is simply a list of features to build. Product managers act as gatekeepers – they make decisions on which feature the development team should work on next, provide the information necessary for the development team to pick up tickets and push features out the door. It feels really efficient when you’re doing it – after all, you can measure how many features/story points/tickets are completed and you can refine your processes to get quicker and quicker. And if that sounds like a production line, that’s because it is.

Product management isn't a production line, it's about improving outcomes
Product management isn’t a production line, it’s about improving outcomes.

A production line is great for creating repeat copies of one thing. However, your goal when developing products isn’t to repeat previous work more efficiently, it’s to improve your product and make it more valuable. Measuring output isn’t relevant to a product’s success – you need to measure outcomes, and have confidence that you’ve solved the problem you intended to solve. 

Rather than a “build, build, build” mode, you need a “build, measure, learn” mindset, to give yourself time to go back and improve what you’ve done and get the best return on your investment.

Make the time to go back and learn from what you've built.
Make the time to go back and learn from what you’ve built.

What should product management success criteria look like?

The concept of outcome measurement isn’t easy. You can’t use the same metrics each time, as measuring the outcome requires an understanding of the benefits to be gained when the problem is solved. To truly measure outcomes, you should define success criteria before the problem is solved, by asking “how will we be able to see when the problem is solved?”. 

The way you measure success may be different depending on the granularity of the problem. Let’s consider an example like having a high amount of churn/cancellations. This is a product-level problem, and is easy to measure. There are lots of tools available to allow us easily to keep track of the number/value of customers who cancel each month. However, the ways in which we solve the problem are less defined – it could be more educational tools, in-app help, improved onboarding or a myriad other options. If we decide on educational tools, there are multiple options, such as videos, help articles, or live chat. We need to measure success at different levels. In ProdPad, we would represent this by creating a roadmap that is structured around objectives and key results, initiatives and ideas.

Objective

Setting clear objectives helps you measure product success.
Setting clear objectives helps you measure product success.

This is the objective (also called the OKR). We can add information over time to see whether our various efforts to address churn are working and it’s moving in the right direction. It’s the bellwether.

Initiative

Each initiative in ProdPad has space to document success criteria.
Each initiative in ProdPad has space to document success criteria.

This is the initiative. It is a problem definition, linked to the OKR so we can see that the work we are planning on our roadmap is helping us to achieve our company objectives. We can also see how we’re measuring success for this initiative in particular (other initiatives could be linked to the same key result).

Ideas

And finally, this is one idea for solving the problem represented in our initiative. There will be lots of ideas we could try, and each will have different success criteria, as we’re building different solutions. We might try one or many ideas in the process of solving the problem. The idea is really an experiment, something which we’re trying in as minimal a way as possible, in order to learn what works and what doesn’t.

In each case, we’re measuring the success of what we’ve defined, but the level of granularity is different. For ideas, we check to see if the change worked as expected. For the initiative, we check to see if the change solved the problem. And for the objective, we’re measuring to see if solving the problem helped us to reach our objectives.

Managing the process of measuring success

As there are different levels of granularity in the measurement of success, we also need to find different ways of recording the outcomes. Much of this will depend on how frequently changes are released. If you release small changes daily or weekly, you should check on their success on a very regular basis, and maybe keep an eye on how well you’re solving the bigger problems quite regularly too. 

It’s likely that you’ll want to check progress towards your OKRs on a monthly basis. If your release frequency is much longer, then success measurement is a less frequent process too. It’s why most companies aim to release small and often, so they can see the effectiveness of the changes they make. If you only release once a year, and can’t measure success along the way, how will you be confident that your changes will work?

There is always space at every level in ProdPad to record how effective your bets were. This starts at the idea level.

Go back and record the outcome on the ProdPad idea.
Go back and record the outcome on the ProdPad idea.

You can record the success of your initiatives…

Once each roadmap card is completed there is space to measure the performance against your pre-planned success criteria.
There is space to measure the performance against your success criteria.

…and whether your OKRs are on track, behind, or at risk.

Measure whether your product teams are on track for success.
Measure whether your product teams are on track for success.

Why measuring product success makes you a successful product manager

The most effective product managers learn from their successes and failures, learning from failure and iterating until they reach success. A short feedback cycle and breaking the work down into the smallest valuable piece (even if that’s an experimental prototype) allows a PM to learn quickly and offers them the best possible chance for success. It’s much better to learn how something doesn’t work at an early and inexpensive stage than when a major feature is released!

When you’re considering how you can be a successful product manager, and how you can help your business succeed too, there’s really only one answer – the build, measure, learn formula that is integral to ProdPad. Give it a try and see for yourself how it prevents product teams from falling into the “feature factory” trap.

The post Avoiding the Feature Factory: How to Measure Product Success appeared first on ProdPad | Product Management Software.

Using the Agile Methodology to Create Transparency for Product Teams

“We need agile since we tend to wrongly estimate the time needed, engineers often get sidetracked into other features and the overall team needs more visibility on the tasks at hand.  What is a good, free and simple tool to start with? I have used Excel in the past but the planning becomes manual.”

Upon reading the question above I can see that there’s quite a lot to address. This is a pain faced not just by startups, it also rears its head for larger organizations, too. The Agile methodology is perfect for creating transparency and keeping product teams aligned, but (as always) I’d like to break this question down into bits to get to the core issue.

Agile vs Agility

The first bit that caught my attention was the opening statement:“We need agile since we tend to wrongly estimate the time needed…”

Using the Agile methodology is not the same thing as being agile. 

When it comes to estimations and timelines, the Agile methodology won’t help you work any faster, or allow you to estimate better timelines. If anything, timelines are against the very core of what Agile stands for. Agile is about this continuous loop of learning and iteration, and setting due dates goes against that flow. 

I’d recommend looking at an Agile framework that allows for better estimations for work. This isn’t about time, but rather understanding the capacity your team has to work on things in a given sprint. The types of frameworks you could adopt are Scrum, Kanban, or the hybrid Scrumban. 

ProdPad's Kanban workflow supports the Agile methodology.
ProdPad’s Kanban workflow supports the Agile methodology.

Setting Direction and Creating Transparency for Your Product Teams

Agile methodology is great for moving things along, and coupled with a framework that will allow you to understand the capacity of work and setting a structure will certainly help you. However, this is all focused on the output (delivery) process.

If what you want is to make sure that your team knows what they’re working on without getting sidetracked on random features, as well as create overall transparency for your team, you need to also set an outcome (strategy) process. In other words, you’re helping your team understand what the current focus is.

This will include:

  • What you are doing
  • Why you are doing those things
  • What objectives you’re looking to impact and achieve by working on those items
  • How you will measure success 
  • What are the benefits of working on those items
  • Who benefits from you working on those items

These are all things a product manager takes care of, and a project tool won’t help you out with that. This is why product tools exist. Our product management tool, ProdPad, will help you manage strategy (outcomes) while a project tool helps you manage execution (output).

Once you’ve established your strategy process, then you can focus on the execution process. These are the two sides of product development – first you understand what and why you are working on things, then you execute on those things.

Using tools that support Agile methodology 

The reason Excel isn’t a solution is because spreadsheets aren’t really meant to manage this type of work. I’d recommend looking at two separate tools: a product management tool like ProdPad integrated with an execution tool, such as Trello or JIRA. This will enable you to establish the process separately and join them together as needed. As a product person you’re then able to focus on the problem space, while your team has a space to focus on the execution space.

A product manager who is looking to successfully incorporate this methodology into their product and software development teams should book a personal demo with one of our product experts. They’ll show how ProdPad supports the Agile frameworks to provide more transparency… and much fewer spreadsheets.

The post Using the Agile Methodology to Create Transparency for Product Teams appeared first on ProdPad | Product Management Software.

The Path to Becoming a Better Product Manager

A product manager’s role (especially for those new to an organization) is never straightforward or simple. It’s a role that means you have to constantly juggle multiple contexts, deal with different personalities and maturity across teams, and understand and assimilate so many different things just to keep your head above water. It’s therefore hugely encouraging to see that so many product people consistently self-evaluate and seek continuous improvement so that they can become better product managers. 

Move along the spectrum to becoming a better product manager

You can’t become an outstanding product manager overnight, but becoming one is almost always obtainable – as long as you understand your goal and take incremental steps to improve in order to get there. These steps include continuous learning, iterative improvements, and applying a product mindset in more and more situations before you get to an “ideal state”. Moving along the spectrum is important; there are principles and strategies you can adopt now and gradually feed into your own workload, without having to make any drastic changes or relying on huge organizational shifts in entrenched processes. 

Teresa Torres uses recommendations for continuous discovery to illustrate what this spectrum of improvement might look like in a product person’s day-to-day work. In an ideal world, she recommends a product manager talks to customers at least once a week. This might seem overwhelming, especially if your week is already bursting with meetings. But if you’re striving to improve your work, then gradually increasing the amount of time spent with customers so you speak to them a couple of times a quarter is a valuable step in the right direction. Then move this to a few times a month and eventually you’ll be speaking to customers every week. By shifting carefully along this spectrum and taking a methodical approach, you can achieve your objective.

Move to the next level with ProdPad’s help

Supporting you as product managers to be the best you can be, both as individuals and within your organization, is integral to ProdPad’s ideology. We provide you with the tools you need to push towards success. I’ve broken down how ProdPad helps you to transform into the type of product manager who consistently and effectively manages products that generate positive outcomes for both your customers and your business. 

Move from opinion-based decisions to customer-based decisions 

Innovation expert Steve Blank highlights the importance of customer-based decision making by saying: “No facts exist inside the building, only opinions.” You need to listen to what your customers are experiencing by collecting feedback on your product. Don’t rely on what you or your key stakeholders think when you have a catalog of customer perspectives and needs at your fingertips. Without customer validation, how do you know how your product is holding up? Is it truly solving customer problems? Without a customer-centric approach, you will build stuff that you think your customers want instead of what they actually need, resulting in mountains of tech debt and wasted development costs. 

With ProdPad, you can easily link ideas and feedback together to ensure the right decisions are made. 

Embrace time horizons and ditch timeline roadmaps

We’ve said this time and again at ProdPad – remember when our CEO, Janna Bastow, did a thing on Twitter? – but a roadmap full of dates will not do you or the product team any favors. I appreciate that a shift from deadlines and features to time horizons and themes won’t happen overnight, so why not start by setting work to be completed by each quarter, and then gradually phase out time restraints altogether? Fortunately, it’s still possible to show time on ProdPad’s lean, outcome-focused roadmap  so you can emphasize the problems being solved both now (with more detail and certainty) and in the future (with less detail and certainty).

Better product managers embrace time horizons on lean roadmaps.
Better product managers embrace time horizons on lean roadmaps.

Measure success based on impact and outcomes rather than features 

Considerably more important than the number of features your team ships each development cycle is the impact those features have on your customers and the outcomes they help to generate. Josh Seiden defines an outcome as “a change in human behavior that drives business results”. Rather than adopt a “feature factory” approach whose primary goal is to churn out as many features as possible (with questionable assumptions about their ultimate value), ask yourself what problem you’re trying to solve and how confident you are that the delivered feature will solve it. Adopting this mindset means you’ll become more focused on prioritizing work that is valuable and worthwhile. ProdPad’s Ideas feature allows product people to chart all ideas on an Impact vs Effort matrix to aid in relative prioritization of those ideas.

Use ProdPad to prioritize the right ideas to work on.
Use ProdPad to prioritize the right ideas to work on.

Be transparent with your organization as well as with your customers 

Your organization needs to know what you’re working on and the outcomes you’ve generated. Stakeholders need to see that the strategy is being executed, the sales team needs an idea of what features are coming out soon, but you should also make sure you’re transparent with your customer base. Let them know you’re listening: tell them when you’re working on solutions to their problem or when you’ve released something that addresses feedback they’ve given you. In ProdPad you can create multiple versions of your roadmap, tailored to each of your different audiences and with appropriate levels of detail for each, which is perfect for transparency, visibility, and gathering input on features under consideration.  

Learn from the functionality you’ve just released 

I’ve seen too many product roadmaps that end once the code for a feature gets pushed to production. A product manager’s job shouldn’t simply stop once something has been released. It’s critical to learn from the freshly released functionality so you can iterate and improve accordingly. When crafting an initial idea and building it out for development, make it a practice to predefine a set of success criteria and how you might measure them so you can easily determine whether it achieved the desired outcomes. Start documenting these outcomes so you and others on your team can incorporate what you learn into future work. It’s these learnings that may go on to shape, or even adapt, the rest of your product strategy. The completed roadmap cards in ProdPad contain fields for tracking how well the shipped ideas met the desired objectives. 

Use ProdPad's Objectives and Key Results to keep your organization aligned.
Use ProdPad’s Objectives and Key Results to keep your organization aligned.

Consider both business and customer outcomes

It’s all about striking a balance. Of course your customers need to be at the forefront of your product strategy, they are the ones for whom you need to deliver value. But a great product manager is able to ensure that they’re aligned with the rest of the organization and working towards the same objectives. In ProdPad, user outcomes are incorporated by tying customer feedback and problems to the ideas making up every product initiative. Additionally, ProdPad has an Objectives and Key Results (OKRs) feature to ensure that the desired outcomes (both business and customer) are identified and to measure progress towards those objectives facilitated by the relevant initiatives. 

Signing up for a free ProdPad trial will allow you to take your product management game to the next level by incrementally, or even significantly, improving on a regular basis. Remember to refer back to this blog post and consider how each point can be applied to your current context in our awesome product management tool – you’ll go from good to amazing in no time at all. Good luck.

The post The Path to Becoming a Better Product Manager appeared first on ProdPad | Product Management Software.

The Path to Becoming a Better Product Manager

A product manager’s role (especially for those new to an organization) is never straightforward or simple. It’s a role that means you have to constantly juggle multiple contexts, deal with different personalities and maturity across teams, and understand and assimilate so many different things just to keep your head above water. It’s therefore hugely encouraging to see that so many product people consistently self-evaluate and seek continuous improvement so that they can become better product managers. 

Move along the spectrum to becoming a better product manager

You can’t become an outstanding product manager overnight, but becoming one is almost always obtainable – as long as you understand your goal and take incremental steps to improve in order to get there. These steps include continuous learning, iterative improvements, and applying a product mindset in more and more situations before you get to an “ideal state”. Moving along the spectrum is important; there are principles and strategies you can adopt now and gradually feed into your own workload, without having to make any drastic changes or relying on huge organizational shifts in entrenched processes. 

Teresa Torres uses recommendations for continuous discovery to illustrate what this spectrum of improvement might look like in a product person’s day-to-day work. In an ideal world, she recommends a product manager talks to customers at least once a week. This might seem overwhelming, especially if your week is already bursting with meetings. But if you’re striving to improve your work, then gradually increasing the amount of time spent with customers so you speak to them a couple of times a quarter is a valuable step in the right direction. Then move this to a few times a month and eventually you’ll be speaking to customers every week. By shifting carefully along this spectrum and taking a methodical approach, you can achieve your objective.

Move to the next level with ProdPad’s help

Supporting you as product managers to be the best you can be, both as individuals and within your organization, is integral to ProdPad’s ideology. We provide you with the tools you need to push towards success. I’ve broken down how ProdPad helps you to transform into the type of product manager who consistently and effectively manages products that generate positive outcomes for both your customers and your business. 

Move from opinion-based decisions to customer-based decisions 

Innovation expert Steve Blank highlights the importance of customer-based decision making by saying: “No facts exist inside the building, only opinions.” You need to listen to what your customers are experiencing by collecting feedback on your product. Don’t rely on what you or your key stakeholders think when you have a catalog of customer perspectives and needs at your fingertips. Without customer validation, how do you know how your product is holding up? Is it truly solving customer problems? Without a customer-centric approach, you will build stuff that you think your customers want instead of what they actually need, resulting in mountains of tech debt and wasted development costs. 

With ProdPad, you can easily link ideas and feedback together to ensure the right decisions are made. 

Embrace time horizons and ditch timeline roadmaps

We’ve said this time and again at ProdPad – remember when our CEO, Janna Bastow, did a thing on Twitter? – but a roadmap full of dates will not do you or the product team any favors. I appreciate that a shift from deadlines and features to time horizons and themes won’t happen overnight, so why not start by setting work to be completed by each quarter, and then gradually phase out time restraints altogether? Fortunately, it’s still possible to show time on ProdPad’s lean, outcome-focused roadmap  so you can emphasize the problems being solved both now (with more detail and certainty) and in the future (with less detail and certainty).

Better product managers embrace time horizons on lean roadmaps.
Better product managers embrace time horizons on lean roadmaps.

Measure success based on impact and outcomes rather than features 

Considerably more important than the number of features your team ships each development cycle is the impact those features have on your customers and the outcomes they help to generate. Josh Seiden defines an outcome as “a change in human behavior that drives business results”. Rather than adopt a “feature factory” approach whose primary goal is to churn out as many features as possible (with questionable assumptions about their ultimate value), ask yourself what problem you’re trying to solve and how confident you are that the delivered feature will solve it. Adopting this mindset means you’ll become more focused on prioritizing work that is valuable and worthwhile. ProdPad’s Ideas feature allows product people to chart all ideas on an Impact vs Effort matrix to aid in relative prioritization of those ideas.

Use ProdPad to prioritize the right ideas to work on.
Use ProdPad to prioritize the right ideas to work on.

Be transparent with your organization as well as with your customers 

Your organization needs to know what you’re working on and the outcomes you’ve generated. Stakeholders need to see that the strategy is being executed, the sales team needs an idea of what features are coming out soon, but you should also make sure you’re transparent with your customer base. Let them know you’re listening: tell them when you’re working on solutions to their problem or when you’ve released something that addresses feedback they’ve given you. In ProdPad you can create multiple versions of your roadmap, tailored to each of your different audiences and with appropriate levels of detail for each, which is perfect for transparency, visibility, and gathering input on features under consideration.  

Learn from the functionality you’ve just released 

I’ve seen too many product roadmaps that end once the code for a feature gets pushed to production. A product manager’s job shouldn’t simply stop once something has been released. It’s critical to learn from the freshly released functionality so you can iterate and improve accordingly. When crafting an initial idea and building it out for development, make it a practice to predefine a set of success criteria and how you might measure them so you can easily determine whether it achieved the desired outcomes. Start documenting these outcomes so you and others on your team can incorporate what you learn into future work. It’s these learnings that may go on to shape, or even adapt, the rest of your product strategy. The completed roadmap cards in ProdPad contain fields for tracking how well the shipped ideas met the desired objectives. 

Use ProdPad's Objectives and Key Results to keep your organization aligned.
Use ProdPad’s Objectives and Key Results to keep your organization aligned.

Consider both business and customer outcomes

It’s all about striking a balance. Of course your customers need to be at the forefront of your product strategy, they are the ones for whom you need to deliver value. But a great product manager is able to ensure that they’re aligned with the rest of the organization and working towards the same objectives. In ProdPad, user outcomes are incorporated by tying customer feedback and problems to the ideas making up every product initiative. Additionally, ProdPad has an Objectives and Key Results (OKRs) feature to ensure that the desired outcomes (both business and customer) are identified and to measure progress towards those objectives facilitated by the relevant initiatives. 

Signing up for a free ProdPad trial will allow you to take your product management game to the next level by incrementally, or even significantly, improving on a regular basis. Remember to refer back to this blog post and consider how each point can be applied to your current context in our awesome product management tool – you’ll go from good to amazing in no time at all. Good luck.

The post The Path to Becoming a Better Product Manager appeared first on ProdPad | Product Management Software.

Managing Customer Feedback Within Product Management Teams

The below question on managing customer feedback got my attention when I was going through one of the product management forums, mostly because I totally feel their pain:

“How do you manage feedback? Is everyone else tired of spreadsheets?

When I worked in support, it was so hard to give my product manager the right information, and usually, it all came down to trying to understand a spreadsheet dump. So let’s kick this off by saying yes – there absolutely is a better way, but I’d like to take a step back first and break this down into different buckets of information.

Do Not Call Customer Feedback “Feature Requests”

This is your opportunity to change the conversation. What you’re receiving is feedback on how you might improve your product and what your customers are struggling with. A “request” implies you will have to work on every item that comes in, whereas feedback gives you more flexibility as to how you handle things. Whether it’s positive or negative, it’s then up to your product team to manage this customer feedback and handle things appropriately.

Gathering vs Tracking

I like to separate the concept of gathering vs tracking. Gathering is something you should do with as many tools as possible – don’t limit yourself. Whether it’s through social, email, conversations, or your different customer-facing teams – open up as many channels as possible. This makes it easier for people to actually want to engage with you. There certainly isn’t a lack of tools that will help you do this.

Tracking is a separate step of the process, and in my opinion the most important part, as it will determine how things impact your product backlog and eventually how items get prioritized. For this, we built and use ProdPad. Why? Because customer feedback is what helps validate your product backlog, so having it in a separate tool makes absolutely no sense. You need to understand the qualitative and quantitative aspects of it.

Responding

Saying thank you is a first great step. But for every piece that comes in, we make sure the person handling understands how to respond – that is, always asking why. Why do they feel they need this feature they’re asking for? How might it help them do their job? This is significant in two ways: one, it trains our team member in understanding what the product needs and how the product works and two, it lets the customer know we’re not just taking the piece of feedback and dropping it off to be lost, but that we actually want to (and need to) understand what they’re struggling with.

Post-implementation Comms

This is a biggie as it closes the feedback loop. Just answering and saying “thanks” isn’t where it ends, you then need to get back to the customer and close the feedback loop once the idea is implemented. This will give you the opportunity to bring back lost leads, but also create an atmosphere of trust. Just getting back to someone and thanking them for making a difference in your product makes them feel like it matters. Again, we use ProdPad for this. All feedback links back to a contact who we can then reach out to when the item is released. We generally include a quick thank you note as well as either a video or a how-to doc as to how the feature works. Boom, you’re a superhero.

Managing your customer feedback in a system (not a spreadsheet) that allows you to understand who the feedback came from, why, and how it’s impacting your product backlog, is not only making things easier for yourself but for your team. Your customer-facing teams will have an easier time speaking to your customers, you’ll have a better way of understanding and prioritizing feedback, and you’ll be on your way to building great products.

How do you manage customer feedback? Drop us a comment below and let us know. Or why not book yourself in for a demo with one of our product experts to learn how ProdPad can help you overcome this problem. 

The post Managing Customer Feedback Within Product Management Teams appeared first on ProdPad | Product Management Software.