• The job definitions vary from company to company – What a product manager does at Company X could be quite different from the product manager at Company Y.
• The job titles and terms themselves are tricky – Does “owner” really make sense?
• The actual day-to-day work doesn’t always match the job title – Classic company issue!

We’ll get into these reasons as we go along.

But first, let’s break down what the product manager (PM) and product owner (PO) do, both the daily responsibilities they have and the roles they play in the bigger picture.

Then we’ll explore where the confusion comes from and how to clarify these two titles so that your team functions like a well-oiled machine — or, you know, like a happy ecosystem of smart people!

What is a Product Owner?

The product owner is like a project manager for a sprint. This is the person who makes sure the product backlog is in tiptop shape before any tickets are handed off to the development team.

The PO represents the voice of the customer, understands user needs, and communicates requirements to the dev team by writing great user stories or product specs. In some cases, they’re also in charge of prioritizing the backlog for each sprint.

It’s helpful to think of PO as a responsibility rather than an exclusive role for a single person, although many companies have someone on the team with the PO title!

I describe it as “a hat that someone wears” — anyone could wear it! In fact, the classic definition of a PO is a roaming role, which changes with each sprint or as needed. It could even be someone on the development team itself doing the product owner responsibilities.

That’s why the term “owner” can be misleading, because the person in this role could be temporary. Plus, this role doesn’t actually have final say on the overall product or its direction.

Bottom line: No matter who wears the PO hat (or title), their purpose is to represent the voice of the customer in each spec and handle backlog grooming before the sprint begins.

Sometimes the work of a product owner is included in the job of a PM, which brings us to…

What is a Product Manager?

The product manager is a wider-reaching role. This is the person focused on overall product strategy, collecting feedback, discovering the problems facing the business and its customers, and figuring out how to bring vetted solutions into reality.

The PM generally leads and works across teams to get the product designed, built, and launched. The work involves cross-functional collaboration with design, business development, marketing, customer support, you name it! And of course, the PM is in charge of building a product roadmap that is not only useful and reliable, but generates buy-in among these teams.

The PM role is much more strategic and people-oriented than strictly technical or sprint-focused. We’ve even documented some surprising skills needed to master the Product Manager role.

Bottom line: The PM is a researcher, strategizer, and decision maker, with authority on product direction and the responsibility to bring people on board and manage those stakeholder expectations.

Why the confusion around Product Owner Vs Product Manager?

Like we said up top, it’s nearly impossible to compare titles across companies. Someone could be called “product manager” but doing work that’s unrelated — or, on the flip side, they could be doing PM work but not have the title. Someone called the “product owner” could absolutely be executing the whole gamut of the PM role.

Inconsistency across companies isn’t much of a problem so long as within your team, you understand clearly which role has which defined responsibilities, and how they can work best together.

Whenever roles aren’t clearly defined, there’s a risk of tension on a team. In the product context, the handover and cadence between PO and PM is important. My recommendation is that you focus first on the functions (such as each person’s role, responsibilities, remits, workflows, etc.) then figure out appropriate titles.

How a Product Owner and Product Manager can work together?

Indeed, the work is closely linked! The PM captures all ideas, suggestions, and feedback. The PO helps flesh these out, so that a decision can be made: What takes priority? What just isn’t feasible? The two share a product backlog and often must manage it together.

With ProdPad, we’ve built a tool that helps each role (or anyone who might be doing both roles at once!) carry out daily tasks, without losing sight of the big picture and while keeping other teams in the loop.

The PM can store all feedback or potential ideas in one place, work on their backlog in their own time, create a space that’s transparent for the whole team, and show how solutions or priorities meet overall business objectives.

Meanwhile, the PO can prioritize ideas or spec out prioritized tickets to be “ready for dev.” ProdPad offers a final touchpoint before handoff, where the PM and other teammates can view what’s coming down the pipeline.

The result? Aligned teams, smooth sprints, and happier users.

The post Product Owner Vs Product Manager – What’s the difference? appeared first on ProdPad.

For every change, new feature, improvement, or rework, you should be doing Product Discovery so that you can constantly validate that there is a real problem to solve, that it is a real problem, and that solving it is worthwhile. Most importantly, you can see that solving this problem fits within the product vision and strategy.

Understanding this last point is crucial. There’s no point tacking on a new feature if it doesn’t fit the product’s vision and strategy. It won’t help you reach the product vision, and it’s likely to be a feature that only a few people, if any, use, since it has nothing to do with the reason that they use your product in the first place.

Continuous Product Discovery differs from initial Product Discovery because you already (hopefully) have customers and users with whom you can validate a problem. Of course you should also look at validating problems with potential and former users to ensure a wide range of opinions.

Continuous Product Discovery – Mining Your Feedback

In some ways Continuous Product Discovery is easier than initial Product Discovery. As users already have your product, you should be collecting the reams and reams of feedback they provide (you are, aren’t you?). This feedback is your raw material to mine for new problems, unresolved problems, and resolved problems that change as the market and wider environment evolve.

A downside of this feedback is it’s sheer volume – it can be hard to keep up with. And it will inevitably include a lot of noise as people provide feedback specific to their situation. However, this volume and noise can work to your advantage, as with Continuous Product Discovery you’re looking for the common problems. You can quickly find these common problems in feedback and also see how they’re manifested in different ways for different users and situations.

The more common problems you solve, the broader and more effective your product will be.

Showing up Those Subtle but Difficult Problems

Even more powerfully, this volume of feedback can surface those subtle but difficult problems which aren’t caught with initial Product Discovery because you don’t have the time or people to collect data.

The nature of initial Product Discovery means your time and access to people are often limited. The problems you’re testing or discovering are the ones that people are currently aware of. All of which is good, but you need to weed out those that are transient problems (like when your dog dribbles water on the kitchen floor but you don’t bother cleaning it up because it’ll dry in five minutes). More importantly, you will struggle to discover the subtle problems that people aren’t aware of and those problems that slowly surface over time.

The volume of information that is captured with Continuous Product Discovery allows both the problems that users aren’t aware of to be discovered and for slow problems to surface. But only if you actively look for them. As the volume of feedback grows, you can spot patterns that point to these subtle problems so you can then delve into them to validate their existence and characterise them.

While customer feedback is often the most significant part of Continuous Product Discovery, the knowledge garnered from metrics and product usage tracking should not be forgotten. Combined, they give you a potent weapon for problem discovery.

Careful Validation Required

The next step is, of course, validation. There are many ways of validating a problem, user testing, surveys, asking questions in a user community, to name a few. Be careful that you don’t keep returning to the same people during validation. It may be easier to go back to the same helpful people, but it’s extremely important to get a diversity of users in your validation of a problem.

What about outside your current user base? With Continuous Product Discovery you aren’t trying both validate the product and the market, and as you’ve already identified your market you can look for similar people who currently aren’t customers. Previous trial users and cancelled accounts can be a great source of external validation. Your outreach to these people shouldn’t be a random crap shoot though. Focus on those who liked or were engaged with the product, but didn’t continue with it. For example, their situation changed and the product failed to fit, or the product didn’t quite meet their needs, or they weren’t ready for the product at the time of trial. They can be a great source for problem validation as will be they more interested in the product’s success than randomly selected people.

How to Prioritise Those Problems

Continuous Product Discovery is likely to surface lots of problems so you will need to prioritise them for validation and eventually for delivery.

Firstly, ask whether the problems fit with your product vision and strategy. If they don’t then you can park them until they do.

Next, look at the impact that solving the problem will have for your users and your company. Will it widen the market? Will it increase the value of the product to users? Will it make the product more important to users? Is the problem broad and far-reaching? Is the problem one faced by your high-value users?

It would be great if there was a magical scoring system that produced a single number and was right all the time, but this sort of prioritisation is always a judgement call.

Once you’ve established your priorities you can roadmap the problems and start to work on breaking them down into sensible parts. This results in something to be passed on to developers (or manufacturers) to be implemented, built, or otherwise delivered.

Done well, Continuous Product Discovery is an incredibly effective and powerful way of keeping your product relevant and valued by your customers.

How can ProdPad Help with Continuous Product Discovery?

ProdPad can help you to create an effective Continuous Product Discovery process by:

• Helping to capture the volume of feedback you receive
• Sifting through that feedback to find the gems
• Prioritising by looking at who gives you feedback and the value they bring to your company
• Roadmapping, ideation and then onto delivery

Start a trial today!

The post What is Continuous Product Discovery and are you Doing it right? appeared first on ProdPad.

Because if you do find that your CPO describes your product differently from your customer support reps, there’s been a communication breakdown that isn’t going to fix itself. That right there is the next six months of your work cut out for you.

It doesn’t matter what you thought your job would look like – now you drop your other plans, your assumptions around what you thought your role would look like, and work on addressing a company that’s pulling your product in different directions.

What you’re looking out for during this initial orientation period are flaws, discrepancies and even the language they use to describe your product.

And be glad you’re doing this now – because these are symptoms of deeper problems within your organization that you either fix now or suffer from down the road.

First, try the product as a new user

Right before you do start having those 1-to-1 chats with your colleagues, I always recommend opening up an account as a new user and and taking notes as you go. You only have one shot at a first impression, so take note of subtle points of confusion or frustration as you navigate through your product. If you’re experiencing problems, chances are your customers are too. As you make your way through, focus on the following:

• What are user expectations?
• Do those expectations match up to the customer experience?

You’re paying attention to two things here: the way the product itself works and whether it matches up to the way the product has been communicated. As product manager, get used to having both hats on. You’ll always be working towards syncing your product with the marketing and customer service that supports it.

For example, if your marketing automation company has put in a lot of effort to market an A/B testing section but hasn’t pushed out any resources or customer education around using it, this is something you would need to work out a plan for. After all, your success as a PM depends on metrics like feature adoption rates and usage intensity.

Anyway, don’t worry about what changes you’re going to apply just yet. Just figure out what the current issues are so you can bring them up during discussions with your team members. Decisions come later.

What you’re looking for during your 1-on-1s

Now that you’ve dug around on your own, you have an angle for approaching 1-on-1 chats with your teammates. When you do go in, start broadly:

1. What do they think the product vision is?
2. What are their frustrations?
3. What would they like to see improved?

Look for the way they describe or pitch the product to you – and how they feel the product actually stacks up against it. Repeat the same sort of exercise with a handful of customers and end users.

Keep track of the differences you observe from team to team, from your CEO to your sales and support teams. Your first actions as PM will revolve around finding out why these discrepancies are taking place and setting out to fix them so they don’t happen on your watch.

Starting a product manager role is definitely overwhelming, but at least for now, all you have to do is listen.

The post What’s The First Thing A New Product Manager Should Do? appeared first on ProdPad.

Here’s where you start:

Regardless of your motivation, there are succinct and effective strategies developed by practitioners and authors in our field, to guide you in this task.

Practitioners such as Jock Busuttil, an experienced product management consultant, author and startup mentor, contend that in order to evaluate your success as a product manager, you need to consider your effectiveness in the following areas:

• Communication
• Idea development
• Roadmapping and planning
• Launch
• End-of-life

These areas form the basis of many product management Key Performance Indicators (KPIs).

Busuttil, along with others including Marty Cagan of the Silicon Valley Product Group, states that it is essential for product managers to recognize the fluidity of their work, and the ways in which product managers work as a sort of ‘oil in the gears’ of an organization, without which the business would ostensibly fail to reach its full potential.

So how much is a product manager worth to a company?

Nils Davis, a field professional with over 20 years of experience, contends that, “a good product manager is worth between $5 and $10 million in annual product revenue.”

He reached this conclusion by using a formula to determine that the normal ratio of development resources to revenue is approximately one developer per $1 in revenue. The normal ratio of product management to development resources is one product manager per 5-10 developers, Davis said. He posits this as a challenge to product developers, asking, “are you worth $5-$10 million a year?”

If you’re not sure how to evaluate your worth in these high terms, Marty Cagan offers an easy to use tool to help determine the answer to Davis’ question, and to help you to improve where necessary. He calls this tool a “product scorecard,” not to be confused with the “Balanced Scorecard” which Cagan argues is somewhat unnecessarily complex for a majority of teams. He suggests that the scorecard can be used to establish the KPIs that product managers, and the organization as a whole, use in decision-making throughout various aspects of production.

Cagan uses an example of a product manager in charge of high-volume seller solutions for an e-commerce company. Though the company strategy may differ, he states for the sake of example that these high-volume sellers bring the majority of the company’s revenue. This company’s scorecard might look something like this, according to Cagan:

• Average revenue/seller – because we want to encourage sellers to sell more goods
• Average promotional revenue/listing – because we want to encourage sellers to promote their listings as aggressively as possible
• Absolute number of high-volume sellers – because we want to grow the number of high-volume sellers
• NPS of high-volume sellers – because we want the sellers to consider ours their preferred marketplace

So, as Cagan and Busuttil state, though product managers are not in control of certain aspects of the business, it is still the product manager’s responsibility to be invested in every aspect. This means if you’re not satisfied with the customer acquisition strategy, you should work with the marketing department to create a more effective campaign.

Concentrate on the essentials

Cagan’s scorecard can help you to ensure your work is in line with the company’s goals and that you are effectively managing your time on the essentials. If an idea doesn’t align with a KPI, Cagan suggests taking it off of the list. The KPIs should be adjusted to reflect the natural and necessary changes in the business strategy over time.

The best product managers work collaboratively to tackle problems others may not foresee. They’re problem-solvers, and often they work behind the scenes, offering dynamic support to various departments and elements of the business. So whether your role is hidden away or more visible, you are an invaluable asset to your company and you have the power to get paid what you’re worth.

How do you evaluate your own success, and your worth as a product manager? What sorts of KPIs do you consider? Let us know in the comments or you can Tweet us!

The post How Much is a Product Manager Worth? appeared first on ProdPad.

Superhuman curiosity

A product manager should have the sort of personality that means they never stop looking for answers. Rather than a simple question of creativity or ingenuity (all great qualities too, but you have a team at your disposal for that), the PM should be constantly asking ‘why’ and ‘how’. He thinks about whether a problem is really being solved in the best possible way. She’s genuinely intrigued by the needs of her users. A superhuman drive to explore the unknown equips a product manager to sniff out hidden solutions.

X-ray product vision

At the intersection of technology, business and customer and the reserve of countless sources of information, product management has to be a heavily organized game. It’s your job to take insight from anything from a sales conversation to a customer support request and translate all of that into workable product specs without missing a bit. But perhaps the biggest challenge in juggling each of these snippets of information is to maintain razor sharp focus. The product management superhero sees through all extraneous data to how to best achieve the product vision.

Charming communication

Product Managers need to be great communicators. And that means great communication of many different forms. You should be an active listener when discussing problems with your customers, but you should be assertive when explaining to your sales manager why a particular feature can’t be promised for Q4. Thoroughly understanding your countless audiences is a great basis for having real conversations with them. But combined with a strong sense of confidence, a noble product manager will go far in getting things done.

Earthly humility

Reading this post is a good sign that you’re a good product manager (as long as you’re looking to become a superhero, not just check off the list). A product management god can’t have a God complex. Always trying to learn and improve and never assuming your opinions are more valuable than others’ is hugely important to a grounded product process. A good product manager should assume that the answers lie outside of their own brains and be open to criticism of their ideas. Much like Superman and Batman keep their true identities in the shadows, a product manager hero doesn’t need the glory of being an idea’s brainchild.

Brewed in a science lab?

A product manager doesn’t have to be an engineer. In companies across many different industries product managers are coming forward from many different backgrounds, from customer support to coding. But for anyone managing even mildly technical products a strong understanding of those technologies is a must. And for anyone managing any kind of product at all, a sensibility for a scientific approach to experimentation is equally important. From A/B tests, to impact and effort measures, to simply a record of how many times a feature has been requested, product managers should be sufficiently equipped to make informed decisions. 

We already revealed our alter-egos – Prod Man and Epic Girl – for the product management superheros we try to be every day, at last year’s WebSummit. Tell us yours in the comments below!

[bctt tweet= “What makes a product management superhero?”]

If you’d like to read more best practice, read our 7 pillars of good product management

And if you’d like to see how ProdPad might help you to bring out your inner superstar, sign up for a 14 day free trial here

The post What Makes A Product Management Superhero? appeared first on ProdPad.

You’re struggling to manage expectations with your roadmap

Perhaps our number one challenge (at least according to this survey way back in 2009) is roadmapping. In my chats with product managers, what is specifically challenging about a roadmap is not simply deciding what to build when, but how to communicate this out to your team and customers. If you often find yourself backtracking when artificial deadlines come around, you likely need to reconsider many preconceived ideas about roadmaps to better manage expectations.

What can you do?

• Banish dates from your roadmap, and instead be firm on your commitment to current, near-term or long-term developments.
• If you can find a proxy that everyone is comfortable with, you can set vague time brackets for these allocations to help with communications.
• Make your roadmaps as open and visible as possible so that your colleagues and customers feel that they are integrated in the product loop
• Treat your roadmap as a fluid, changeable document. Use a format that is appropriate for demonstrating changes and making updates in light of new decisions. Share these processes visually with your team.

It’s hard to focus on your strategic product direction amidst day-to-day demands

Many product managers see their most important objectives slipping further and further away as the day is taken over by urgent, but less important tasks. Perhaps roadmap features are getting pushed back in favour of quick fixes, or the distraction of endless emails and meetings means you can’t find the time to concentrate on strategy.

What can you do?

• Break down big strategic goals into manageable tasks – whether this be to interview a customer or source intelligence from a colleague – and integrate these into your daily routine.
• Keep your product vision at the fore of your mind by making it physically visible. Print it out and stick it around the office.
• Consider the business case for every decision, no matter how small. Develop a system whereby if you commit resources to a product change, you’ve measured whether the impact will outweigh the effort.

Aligning your company on product direction is threatened by different teams’ biases

A product manager should be 100% focused on the needs of their target customer. But there are many different people in your organisation who are key in how to get there. Sales, Marketing, Customer Support and every other customer-facing role has invaluable insight into what customers want and what is key to success in gaining new ones. Trouble is, every team is biased towards their own objectives and world-view, making it difficult to align each one on product direction.

What can you do?

• Be the link that brings different teams together to collaborate on product discussions. When everyone is able to see the big picture – and the different viewpoints that come with it – part of your mediation work is done for you.
• Make sure that all employee input is securely captured and traced. This way if a particular departmental concern can’t be satisfied by one project or development, you can point to how it is being actioned elsewhere.

Your executive level doesn’t always agree with your product decisions

The role of your executive team in the minutiae of product decisions depends heavily on your business, its size, and the individuals involved. But regardless of how interested your executives are in day-to-day product management, these are the people you ultimately have to convince of your vision and decisions to get there. So when they aren’t behind you, this is a product manager’s most crippling challenge.

What can you do?

• Follow a rigorous and repeatable process to qualify new ideas, whether they come from a customer support rep or the CEO. You must be equipped with reasoned arguments for or against any product decision, and train your executive team to expect the same for their brainwaves too.
• Make sure your product decisions are grounded in business value. If you’re finding yourself battling your senior team to push back on or push through a suggestion, are you sure you’re taking the right approach? Every product change should reflect a real value to the business – be it customer retention or competitive survival – and you should be collecting the evidence to prove it.
• Again, be open and transparent on roadmapping. Once aligned with your executive team at the highest level of product strategy, the smaller decisions should be easier to support against this framework.

[bctt tweet= “Overcoming a Product Manager’s Biggest Challenges:”]

If you’d like more best practice, read our 7 pillars of good product management

And if you’d like to see how ProdPad can help to make your life easier, sign up for a 14 day free trial today

The post Overcoming Product Managers’ Biggest Challenges appeared first on ProdPad.

Organize your product landscape into portfolios

How product management is structured differs from business to business. But even those without diverse product offerings are likely to break product management into a series of different areas. If you have more than one product manager, organizing this effectively becomes even more important. Define distinct products and – if necessary – portfolios for groups of those products. This gives different product managers a key area of focus where they can update existing product materials, and review all potential and upcoming developments for the products they own. Uniting these in a consistent format in ProdPad keeps everyone working to the same processes, and moving in the same direction.

Coordinate product streams under a master roadmap 

If you have different products, and even different product management teams, that doesn’t mean that you’re running separate businesses. All of product management should be pulling together to achieve a single product vision, and be agreed generally on how they’re going to get there. On top of separate products and portfolios, creating a master roadmap that sets the direction of each product stream is key to turning your product vision into viable, meaningful products that work together. 

Give structure to the backlog with tags and filters 

A product backlog can easily become a huge mess when not managed efficiently, particularly when you have more than one product manager capturing and pruning potential ideas. ProdPad enables Product Managers to retain order over a backlog of any size with advanced tags and filters. Ideas can be categorized based on anything from product, to user persona, to an idea’s specific author. Product Managers can drill down to the ideas that are relevant to their own products, without losing visibility of what’s happening across different product portfolios and ultimately the big picture.

Allow every Product Manager to follow relevant ideas

Although different product managers might be responsible for specific products, it is inevitable that other new developments or ideas will be of interest to them too. In-built collaboration and granular notifications allow every Product Manager to stay in the loop. In ProdPad, an idea author can be set for any idea to ensure that product managers receive updates on any changes to their own canvases. However they can also opt in to follow any additional ideas, regardless of which products these are related to. ProdPad allows different team members to discuss the viability and progress of product ideas via comments and mentions, in an organized system where everything is logged and searchable.

If you’d like to find out more about how ProdPad can be used across a large or complex product management team, sign up for a free 14 day trial here.

Next week, discover how ProdPad can help you to open up product management to your executive team.

The post Opening Up Product Management: Involving Different Product Teams appeared first on ProdPad.