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.
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.
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
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.
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.
“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.
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!
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.
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.
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.
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.
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: TheTimeline 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.
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.
It’s no understatement to say 2020 has been tough for everyone. As you move into the new year and focus on what can be controlled, you can help your product team prepare for success by exercising those product leadership muscles and implementing product management best practices. Here are our top tips for how you can lay the right foundations and get your product strategy off to a flying start.
1) Dust Off Your Product Vision
When was the last time you reviewed your product vision? Are you still aiming in the right direction? The product vision is the north star around which your product team aligns themselves. Just imagine the chaos that could ensue if you arrange to meet a group of friends without specifying a destination? Your vision is exactly that – it’s the information everyone needs so they know where they’re headed, and why.
If you find yourself needing any inspiration, why not try our product vision template, designed to help you ask yourself the important questions and create a vision that inspires your team.
Product management best practices need to start with the product vision.
Don’t forget, once you’ve defined your vision, you need to make sure everyone can see it. ProdPad’s product and portfolio canvases helps you keep the vision front and center, right where everyone needs it. By aligning everyone around the long term goal, you’ll reduce misunderstandings and help your team stay on track.
2) Define Your Objectives and Key Results
If your vision defines the destination, your objectives and key results (also known as OKRs) help you to set boundaries around how you’ll get there. It’s product management best practice for objectives to be qualitative – what are you going to improve? Maybe it’s adoption, usability, scalability or similar. Key results should be measurable – how will you know you’ve made improvements? What metrics can you check which will show you’ve made a positive impact?
Write up your OKRs, make sure they’re documented somewhere everyone can see them and you’ll find it much easier to see if what you’re doing is actually working as you execute against your roadmap. If you need a bit more guidance on how to go about it, we’ve written about OKRs here. Not only that, ProdPad gives you a place to document your OKRs and tie them directly to the plans on your lean roadmap so they’re always considered in your plans.
3) Get Your Product Strategy in Order
Vision and objectives are key to ensuring everyone is aligned around the destination and direction. Your strategy helps them know which steps to take along the way and is otherwise known as the product roadmap.
We’ve written extensively on this topic, and encourage the use of a lean roadmap to help stakeholders understand the problems you’re hoping to solve in a way that’s flexible and allows for innovation. Your roadmap should be a living, breathing document which provides transparency into the market problems you’re solving, allowing your teams to experiment to find the right solutions. Customers love a problem-based roadmap, it gives credibility that they are being listened to and understood, and gives them the chance to provide feedback on ways those problems can be solved without upsetting your strategy.
So, take a little time to review your current roadmap. Does it focus on solving high priority problems? Do you have ideas on how you might solve them? Is it linked back to your objectives? Is it flexible enough to allow you to pivot as needed? Is it easy for everyone to understand? Most importantly, does it give context around why you’ve focused on those problems? If you find yourself saying no to these questions, maybe it’s time you moved to a lean roadmap – which we’d certainly advocate as product management best practice.
A lean, outcome-focused roadmap is a prototype of your product strategy.
4) Empower Your Team
The chances are you’re surrounded by a team of talented individuals who all have suggestions for how your product could be better. It’s easy for your colleagues to become demotivated if they’re not being listened to or are detached from the product process. It’s also hard for product managers to define the right solutions if they don’t evaluate all the options. This is where empowering your team can help.
By giving your colleagues a place to contribute to the product strategy, you’re killing two birds with one stone. A centralized idea backlog (or “opportunity backlog” as Marty Cagan calls it) gives everyone the chance to contribute their thoughts and get visibility into where they sit in the ideation process. Product managers benefit from the guidance that their team can provide, and can share the responsibility for decision making with those around them. By de-risking that decision process, hitting the market with the right solution is much more likely.
ProdPad’s collaboration features allow you to exemplify product management best practice by allowing all of your internal stakeholders to be involved, and free Reviewer licenses mean you don’t need to worry about how much that extra help will cost. Not only that, your discussions and decisions will be documented and easy to refer back to. Even your slack and email chats can be captured along the way, making it much easier to backtrack and remind yourself how you reached a conclusion.
All teams can stay up to date with ideas, feedback and conversations with our Slack integration.
5) Involve Your Customers
One of the earliest product management phrases I learned was “Nihito” – Nothing Important Happens In The Office. While we might need to update that to say “home office”, the concept is still valid – it’s product management best practice to look outside of your own organization to learn about your market and understand the problems you should be solving.
The best way to do this is by talking to your customers yourself, but you can also take advantage of the conversations your colleagues are having with their contacts, too. By bringing feedback into a single place, it’s easier to spot themes and identify the kinds of problems that rear their heads on a repeated basis.
ProdPad’s customer feedback tools and integration capabilities allow you to collect feedback from all the disparate places they’re circulating and link them to the ideas you have in your backlog to help understand the most valuable ideas. Not only that, you’re able to engage your customers by involving them in testing the solutions they’ve asked for much earlier in the process, leading to better products and increased adoption rates.
Bringing Product Management Best Practices Together
We get it, product management is hard! Sometimes it helps to reset and give yourself confidence that you’re working on the right things. These product management best practices combined with ProdPad’s unique structure will help you bring together your thinking into something that’s easy to share with the team.
Dust off your product vision
Define your objectives and key results
Get your product strategy in order
Empower your team
Involve your customers
ProdPad’s structure will help you execute product management best practices.
Are you ready to take off? Start your free trial in ProdPad and get everyone ready for the journey ahead.
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.
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.
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.
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.
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.
You can record the success of your initiatives…
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.
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.
“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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
) versus making it work as well as it really should (quality 
