Product Management Tasks – A Guide through Responsibilities of your Job

Not every company provides enough clarity about the product management tasks which are expected from their employees. That’s why this extensive guide will walk you through the general expectations on that role and which specific domains you need to master to become a successful Product Manager.

The Death of the Product Manager (as we know it)

Product Management Tasks - Modern Role Definition

When it comes down to responsibilities in a company or a team, the world of product development as we know it always provided a pretty clear structure: CEOs have to lead, designers have to design, developers have to code, and product managers have to…well, actually manage everybody. They are doing that by writing tickets, preparing presentations or thinking about new features and the future product roadmap.

But it was sometime around 2013 when the web suddenly started to discuss whether designers should know/learn how to code or not.
The reasons for this question were obvious. Designers and developers work closely together but often really never understand each other which leads to pretty much waste in communication, mostly caused by missing knowledge about the work from the other.
Advantages would be that designers could, on the one hand, make an early reality check on their drafts and impress developers a little bit more on the other one while the developers would start to value design work more.
Though there were a lot of opinions for and against that statement and it sometimes also depends on what kind of designer you are and what you’re working on, I felt like the essence was: »Yes, designers definitely should know how to code.«

So, if designers learn how to code so they maybe don’t even need a developer to launch a product and developers would vice versa learn more about photoshop, who would need someone else to make excellent digital products? Depending on the size of your company or team you probably still need a project manager to structure the work with scheduled meetings and caring about some organizational stuff like reports or having an eye on the budget.
But do you then still need a guy who can’t design or code pushing wireframes around, writing tickets and testing the latest version all the day also?

But let’s take a closer look at this. Can’t we just put up the same question that rose last year on designers who code? Isn’t it time to ask: »Should Product Managers know how to design and to code?« – I think it is.

If product managers gained a deeper understanding of what’s happening inside “their” teams by having practical skills in both disciplines, it would be a massive win for the product itself. So, in my opinion, we should rethink the role of the product manager. He or she should become someone who’s involved in the actual process of building things.

As a consequence, skills in teams could become more concentrated on fewer people, and team size could be reduced to iterate even faster.

Seeing how small teams gain so much traction with their products without including a personal “overhead” like a product manager made me think about this role (which is what I do for money, too).
One of the key learnings I took away from a journey to the US in 2013  was that I just had to learn how to design and how to code (of course I know that just don’t »learn« design). It would be a requirement if I wanted to stay relevant for the process of digital product development in the upcoming years.

The most important Product Management Tasks & Disciplines

Product Management is so much more than just writing tickets and sitting in meetings.
This guide wants to prepare you for the challenges in the daily business of a Product Manager to help your product management career to get going.

Product Vision

Product Vision Board by Roman Pichler

Your product vision should not be a specific plan that shows how to reach a goal. Instead, you should keep the product vision and the product strategy – the exact tactics to achieve the goal – separate. This enables to change your strategy while staying grounded in your vision.

A handy tool for describing both the product vision and the product strategy is the Product Vision Board by Roman Pichler. Its top section captures the vision, and the ones below state the strategy to realise the vision.

Product Management vs. Project Management

Disciplines in Product Management - Project vs. Product Management

No other terms get more mixed-up in the daily job life but should always be separated from each other to keep things clear. It’s a confusion which maybe occurs to you during the early days of your product management career. Don’t get confused by it.

The best way to explain both jobs is probably the agile methodology (more on that later). If you apply their principles, a Project Manager is similar to a Scrum Master, and the Product Manager is considered as the Product Owner.
Applying the definition from any agile playbook, a Product Owner is responsible for the meaning of the product, and the Scrum Master has to ensure that the team can work towards the defined goal and for reporting on the progress and potential impediments.

These responsibilities can easily be extended to non-agile environments as well, as they’re not bound to specific job terms. Some companies though try to combine both roles in one position and then ask for primarily best of both worlds:
Someone with full product and developer responsibility who removes all impediments for a team and has a fully fleshed out project plan for the next months always ready to present – Something that’s hard to deliver in reality and mostly one area suffers regarding quality.

An Agile Mindset

Disciplines in Product Management - Agile

The most common understanding of Agile is probably the agile manifesto which was developed back in 2001 by 17 men who were back at the time unsatisfied how software projects were approaches. It states the following principles:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

But these values are giving you guidance for developing products in an agile way and leave a lot up to you and your team. Scrum or Kanban, on the other hand, are frameworks that are built upon these guidelines and are for precise in describing the way (software) development should happen.

But only applying agile values to your team or even using Scrum or Extreme Programming from a manual does not automatically solve all your problems. This acknowledgment is best summed up by the following quote from Bill Scot, Senior Director of UI at PayPal:

“Agile doesn’t have a brain.”

The Unofficial Scrum Checklist by Henrik Kniberg

Even though Agile is way more than specific processes and guidelines, this handy checklist from one of the most well-known Agile coaches is a great way to kickstart your team collaboration using Scrum.

Unofficial Scrum Checklist by Henrik Kniberg

Alignment

Disciplines in Product Management - Alignment

As a product manager, you’re working at the intersection of multiple disciplines of your product. You always have to deal with people who own a particular aspect of your product without actually creating issues in your backlog or talking to the designers who are part of your team. This situation is part of almost every product environment, independent of their size.

One of the most critical factors for remaining actionable and accountable even in complex stakeholder environments is the degree of alignment you can create your product vision and your stakeholders. Depending on the variety of your stakeholders, multiple formats can do the job at this point.

The most critical aspects when communicating alignment are (as always) the why, what, how, who and when of your products roadmap. While there are multiple formats to create alignment, you should ever approach this matter before actual implementation starts.

One of the recent trends regarding this subject is based on applying military strategies from the Prussian army to modern product environments by Stephen Bungay. Based on those theories the product community at e.g. XING has started to use a format called Auftragsklärung to align stakeholders before a project begins. It’s a result of some iteration and should be seen as starting point for alignment among larger organizations.

Smaller products and less complex environments can quickly get along a simple kick-off meeting, a lean slide deck and a publicly available product vision and out-of-scope objects.

AB & Multivariate Testing

Disciplines in Product Management - AB & Multivariate Testing

Testing is something every product person is looking forward to. It gives you the flexibility to try out new crazy ideas without the risk of breaking every key KPI of your product at once.

While it’s rather easy to come up with new ideas for an individual feature or product, you should take a look at these rule of thumbs before building your first test:

Define explicit hypotheses and KPIs before running a test
Instead, go for an AB test instead of a multivariate one (especially in the beginning)
Always test bold! 40 shades of blue are something for Google
Even if you think a test ran long enough, extend it for a few more days
Monitor your KPIs again 3-4 weeks after the full roll out of a winning version

Companies like Optimizely, Optimizer or Mixpanel are an excellent choice for the web if you or your company haven’t developed an own testing framework yet.mv

Besides picking the right tool and defining precise hypotheses up front, it’s important to pay attention to the significance of your test results. This metric states if the difference between your tested variants just happened by accident or was caused by the changes you made. Visual Website Optimizer provides two convenient tools that can help you to plan and analyze your tests. While their Test Duration Calculator gives a rough estimation of the minimum time a test should run, the Split Test Significance Calculator tells you if your results are already significant.

Of course, you’re free to build such tools on your own using Excel or Google Spreadsheets if you’re firm with the concerning formulas. Besides that, it’s useful to have a personal or shared test calendar, so it’s easier for you to keep track of the tests you ran as time goes by.

5 Product Management A/B Split Testing Mistakes

A/B Split Testing is the most powerful tool of a product manager for getting from gut feeling and HiPPO driven product decisions to actual progress based on measurable outcomes.
But while it’s comparably easy to asses a tool and implements your first testing setup, there are a couple of meta mistakes I see being made from time to time among product managers (and which I’ve made myself).

Here’s my personal selection and how to avoid them:

Sharing Results too early with Stakeholders

While ‘too soon’ is measured in two dimensions (more on that below), let’s just says there’s a certain point in time during which you just should not talk about the preliminary results of a running A/B test. Especially when you’re testing around a critical business KPI there are just too many dreams and visions emerging from (mostly non-technical) stakeholders – even though the test result doesn’t stand on solid ground.

In the past, I shared ongoing progress of a test we’ve implemented with my engineering team, in order to make their efforts implementing it transparent as possible. But when it came to upper management and marketing, I learned to wait a lot longer before I communicated a result. Best case is, you get approvals from two expert perspectives: A mathematical one (e.g. Digital Analyst/BI Manager) and a practical one (e.g. Director of Product or Product Management buddy).

A/B Testing for the Sake of it

While A/B testing is something to aim for because of the above-mentioned reasons, you shouldn’t run any testing idea which is floating through your regular stakeholder alignment meeting. While the costs of implementing and cleaning an A/B test up are important, it’s more about the environment you want to test in.

Do you actually have enough traffic flowing through your area of product in order to generate significant results within 4 weeks? Do you have the freedom to test variants which are differentiated enough from each other? Do you have the commitment from upper management to also implement the ‘unpopular’ version and they just let you A/B test in the first place because it’s a ‘modern approach’?

Solely relying on Significance Calculators

As I wrote earlier, the mathematical expert view on your test setup and results is a crucial one. But don’t let numbers alone influence your decision when a test is finished. You’ll run into scenarios in which a significance calculator will spit out a significant result after two days or so. But seriously, two days? Common sense should tell you to at least run a test through every day of the week twice in order to balance-out ‘seasonal’ impacts.
Also, significance calculators don’t know every twist and angle of your product and its dependencies like you do. So only you will be able to spot outliers and potential bugs influencing your testing setup.

Confusing A/B Test Results with User Feedback

‘Version A won, so our users like this one more!’ While this assumption doesn’t seem far-fetched, it’s quite misleading. It’s the perfect example why quantitative and qualitative testing (and research) need to go hand in hand for a complete picture.
Even though A/B testing tells you what users are doing (like clicking 5 times more likely on the yellow button instead of the red one), it doesn’t tell you why people are doing it. It’s the unfortunate discrepancy between what people say they do and what they actually do.

So, be happy about the measurable uplift your latest winning version has caused, but make sure to check back it’s mid- to long-term impact on your product by conducting some 1:1 user interviews digging into what users actually made them click more. E.g. in the worst case you just locked the users tighter into a checkout process and they had no other choice then to proceed. Again: Correct action to impact your target KPI, but it’s helpful to know the context around it.

Focussing on the wrong KPI to change

Speaking of KPIs: When setting up your test, it’s important to only work towards an increase or decrease (e.g. when working on a churn topic) of the very metric you can directly influence with a test. Especially when implementing a test within a multi step funnel, you can never be sure to impact the very last checkout metric when only testing improvements within the address data step.
It’s intriguing to assume that all conditions before or after your area of testing stay the same, but then again you perform an A/B test to stop assuming, right?

Actionable advice for A/B testing as a Product Manager

  1. Define explicit hypotheses and KPIs before running a test
  2. Instead, go for an AB test instead of a multivariate one (especially in the beginning)
  3.  Always test bold! 40 shades of blue are something for Google
  4. Even if you think a test ran long enough, extend it for a few more days
  5. Monitor your KPIs again 3-4 weeks after the full roll out of a winning version

Why Retesting your Experiments is crucial for real Optimization Impact

Did you run AB tests before during your career as a product person?
Good.

Did you manage to achieve significant results with at least one of those tests?
Great.

Did you reject the same idea when a colleague suggests it as an experiment 6+ months after you ran it?
Not good. Wait, what?

What might seem counterintuitive at first, is one of the most common mistakes conversion optimizers make throughout their careers.
The primary motivation for testing hypotheses using AB tests is to gather data to avoid decisions which are solely based on gut feeling.
You also want to reduce waste by preventing colleagues in your company from putting effort into a testing idea you already invalidated.

But what if you’re causing more harm than good with this behavior? I recently had the chance to attend a talk from Willem Isbrucker, Senior Product Owner at Booking.com during our Product Tank Hamburg event and got a valuable lesson taught.

When he presented the audience with an AB test setup he ran and asked the audience for the winner, 80% in the room predicted the right version (variant). But then he revealed that the 20% who considered the control version to win was also right in a certain way. The experiment also ran a year ago with the opposite result.
While you could assume a mistake in the analytics, the real reason behind it was that the environment around the testes element (a search box) evolved, and thereby the element itself performed better being visualized differently.

And while looking back at my own set of AB tests I ran throughout my career, I also rejected ideas of retesting because…well, we already proved the hypothesis to be wrong or right.

So, whenever you get presented with a testing idea which ran 6+ months in the past, look again at your product and check the situation:
Did you make changes to the main navigation in the meantime? Did you test within a particular segment or across the user base? Does it maybe make sense to target the change at a particular user group? What if the recently introduced new pricing tier would impact the test again?

Try to find a balance between reducing waste and embracing retesting of known hypotheses. You might be surprised regarding the impact you can generate.

Shipping it!

Product Management Tasks - Shipping it

While there’s almost no better feeling for you as a product manager to ship a thing you and your team have put a lot of effort in it, it’s mostly not worth a rush.

We unfortunately often tend to make too many compromises on our initial vision, to get something through the door and the term »MVP« becomes an excuse for bad quality.
And even though de-scoping what you wrote down several weeks or months before often is very reasonable due to a changed competitive landscape or different requirements from your stakeholders, you should be careful with stripping your product down to its bare skeleton.

There’s often quite a discussion going on within a team if a Minimum Viable Product or a Minimum Delightful Product should be built. But in the end, the most important thing for you to consider is, that even what you ship in the very first iteration should fulfill enough needs of your users to make it worth using it compared to the status quo.

Data-driven vs. data-informed decision making

Disciplines in Product Management - Analytics & Gut Feeling

Decisions on whether to roll out a new feature of cut-off/extend a test are often based on analytics numbers. But sometimes the right metric for a product is just not measurable (e.g., is customer delight) or you’re firmly convinced of the opposite from what the data tells you.
There are times when intuition makes sense, but caution and an awareness of the limitations and pitfalls of this process are suggested here.

It’s always important to double-check generated reports with your personal experience on the product and a sane human mindset. That’s the way how to avoid wrong decisions if, e.g., incorrect implementation of tracking is in place or the analytics tool of your choice is broken.

Don’t forget you are a human. Keep using your brain and don’t rely entirely on provided data. Your reputation as an expert should qualify you to overrule data-driven assumptions from colleagues from time to time.

How to nail it as a non-technical Product Manager

When I started my product management career in 2010, I sometimes felt just overwhelmed with technical discussions, challenges, and expectations of tech stakeholders. I considered myself a non-technical Product Manager back then and was a bit what this would mean for my career.
But after significantly leveling up my tech knowledge over the years, I think it’s worth to look at the general technical vs. non-technical PM topic of our industry.

First of all, it’s important not to get intimated by missing knowledge. While social skills and values are pretty much given, learning about pretty much any topic can be build up by putting in honest work. It’s totally fine to raise questions regarding outlined technical constructions, details and ideas. After all, that’s our job anyways: To ask questions. Even more often there’s an often undiscovered advantage of looking at the complex with a youthful naivety (something Erik Kessels tackles extensively in FAILED IT!).
So, instead of being ashamed of your missing knowledge, appreciate it as a strength to look at things. You’ll become professionally blinkered soon enough.

It’s also motivating to keep in mind that even some of today’s most recognized Product People in the world like Hunter Walk started as a non-technical Product Manager background and worked their way into this field.

A nice quote from Ken Norton sums this (often controversially discussed) topic up from my perspective:

Too often PMs try to impress their engineers with their technical acumen, but in my experience engineers are much more impressed with PMs who are willing to ask questions and say ‘I don’t understand that.’”

Embrace your current set of skills and use them in the best possible way. When you’re comfortable doing this, become uncomfortable again and level up your (technical) skills.

Do’s and Don’ts for a Technical Product Manager

Straight to the point Do’s and Don’t’s from MindTheProduct. You should take a look at it, while it doesn’t matter if you consider yourself a Technical Product Manager or not.

Do’s

  1. Do focus on the business side of the role.
  2. Do use your technical skills to improve prioritization and planning.
  3. Do leverage your technical skills to close the communication gap between engineering and the rest of the world.

Dont’s

  1. Don’t design/solution the product yourself.
  2. Don’t take on non-Product Management deliverables.
  3. Don’t get caught up in Agile, or whatever methodology you’re using. (Annotation: I don’t share the opinion on splitting the Product Owner and Product Manager role)

Do Product Managers need a Portfolio?

It’s almost funny how much focus the specifics of individual projects get during the hiring process of a designer. A CV on the other side is not much more than a necessity to check for some known names.
And in the end, everything boils down to their portfolios. It’s, on the one hand, the perfect place for the designer to put some love into the representation of the work one has done. On the contrary, it’s ‘perfect’ for judging the capabilities of a person based on pixels.

The situation is then often, that most design portfolios look pretty, but lack context or outcome of a project entirely. And because everybody (involved in the hiring process) of course has a (healthy) opinion on design, the portfolio gets judged subjectively as shit.

That’s a real problem as at least I favor an approach to the application process which removes subjectivity and focuses on outcomes (read this book for more input on this topic). So, if portfolios, in general, are already an established part of the hiring process for designers, shouldn’t a more outcome-oriented version of the portfolio play a significant role in an application process of a product management career as well?

To me, the answer is yes. At least, if you’re beyond the junior job level and have a couple more projects to talk about under your belt.

Way more important than the actual medium you’ll use to showcase your work (since there’s no Behance for Product Managers yet) is the real content to put in.
As a Product Manager, your success is often measured by the numbers/impact your product has generated. It’s a bit unfair to say, but while designers can hide behind beautiful pixels and bouncy animations, you need to come up with the naked truth and objective facts.

That’s probably the primary differentiator when compared to the current state of design portfolios being part of the hiring process. As outcomes should be a part of a Product Manager portfolio, you won’t hear that many ‘opinions’ on that part. And it’s probably not a matter of taste on how to judge it.

While I currently don’t maintain a product portfolio myself, I made a weak attempt back in 2014 on my website. If you’re looking for a better example, I highly recommend the way my fellow product superwoman Petra Wille is presenting her work (German only).

So, when you’re assembling your product portfolio as a continuous representation of yourself or for a particular application process, I recommend something loosely following this structure:

  • What was the objective of the project/product?
  • Which stakeholder environment did you face?
  • How did you structure the discovery and delivery process?
  • Building upon that: Which frameworks & tools did you choose to apply and why? Would you pick those again (for the same context)?
  • What was the measurable outcome?
  • In hindsight, what was your most significant personal learning from the project?

Some additional thoughts on the criteria of a Product Manager’s portfolio are included in this neat article by Sachin Rekhi.

Product Management Consulting vs. In-house Product Management

For those of you who have been following my writing for quite some time now, this shouldn’t come as a surprise: I don’t believe much longer in the differentiation of domain product managers.
Instead, I believe in the power of deploying (product) skills in whichever domain is necessary and staying close to some core values (e.g., relentless customer focus).

But there is a particular distinction I want to point out to pay attention to when deciding whether you want to move in or out of working in an agency context: End-to-end responsibility for product outcome.

This all comes down to individual motivators you or team members of you are driven by, and it’s something I urge every people manager to pay close attention to when hiring.
A common motivator I heard about when talking to people which wanted to move into a consultancy/agency domain was the need for more variety of the product challenges they (which was also one of the motivators for me to give consulting a try).

While this is often the desired primary goal, a second one comes into play when it comes to shaping and shipping products for clients: You (can) give up end-to-end responsibility for your decisions.
As a product manager in a consultancy context, you may be responsible for the inner processes to build the product, but you’re not enabled to take full ownership for wrong decisions, mistakes, and potentially fame.

You might be able to push for decisions and initiatives but will always have to rely on the faith, trust, and patient of your client to see things through. While this may sometimes feel frustrating, it can be somewhat convenient for certain types of (product) people. It lets you focus on the upper part of the product funnel. Like the development and discovery of ideas instead of having to deal with hard facts down the road (e.g., ongoing backlog refinements, resolving delivery dependencies and organizing go to market).

When you work in a product company on a product you can (hopefully) entirely own, nobody and nothing will rescue you from dealing with those hard things. It’s part of the overall deal of working on your product with full responsibility.

So, when you’re currently working in an agency/consultancy context and are looking for the next step out of your comfort zone, I encourage you to join a product company and try owning the end-to-end responsibility of a product without the comfy possibility to put mistakes on irresponsible client decisions.
On the other side, when you’re currently part of a product company and consider switching into a consulting role, I’d like to challenge your critical drivers for this switch.

Which Schedule should a Product Manager be on?

You may have heard of Paul Graham’s Makers vs. Managers Schedule paradigm. And while most Product Managers would probably place themselves in the ‘Makers’ bucket (despite the contrary job title), I’d bet that most of you are actually on the Managers schedule.

Product Managers are typically the connection between multiple departments and even business units. This almost automatically implies that you’re discussing a bunch of different topics across the day – perfect for structuring your calendar the Manager way.
And here’s the conflict: While this is an often to observe status quo amongst PMs, the most critical challenges for Product Managers can most likely only be solved on a Makers schedule. Finding the jobs your customers want to hire your product for and drilling deep into customers needs and problems is not something you can quickly pack into a handy chopped calendar slot. Personally, I only manage to crank in foreseeable ticket work into slots like this.

So, here’s the deal: Don’t only try to be a maker during your next job interview or when you’re a guest on a podcast. Be a maker when it comes to planning your daily schedule and only occasionally switch back into the Managers schedule when it’s necessary. Not the other way around.

Product Managers need to be micro Pessimists but macro Optimists

I recently heard about this attitude in a podcast interview with Raylene Yung, reporting that it reflects overall company values at Stripe.
But instead of ‘only’ applying it on a business level, I think it’s also quite a suitable framework for the split of perspectives product managers face on a regular basis.

It’s kind of an analogy to the discovery and delivery separation every product manager needs to handle. While the one (delivery) focusses on execution in regards to ongoing sprint routines, details of backlog items and hitting milestones on time, the other one (discovery) focusses on customer problems worth solving and what to build next.

From my experience, optimism is essential for going into a product discovery. That doesn’t necessarily mean to be overly enthusiastic about a specific feature.
Furthermore, you should be looking forward to the digging into customer or business problems and the creative journey that you’ll identify something valuable you can build upon with your team.

On the execution side, I found the ‘right’ degree of pessimism helpful for staying on track. That doesn’t mean that you should doubt the success of your team on a regular basis, but challenging (your own) priorities and decisions at least during every sprint planning.
Don’t take yesterday’s decisions for granted – As long as corrections still fit into the overall product vision.
Remain, skeptic, that the path you chose for the next sprint will still be the right one when looking back at it into the retrospective. This way, you’ll stay hungry for ongoing improvement and avoid a ‘now we just need it build it’ attitude.

Your macro perspective should always be mostly positive. This will give you the confidence to question decisions on a micro level more regularly without becoming scared that you’re losing touch with the big picture.

Measuring success in a Product Management Career

When I started out in Product Management, the role, in general, was considered to be a bit more stakeholder-focussed project manager. It was all about facilitating requirements and keeping the (mostly outsourced) ‘IT department’ busy for a low daily rate.

The main success criteria to measure Product Managers again back then was basically to ship a particular feature (mostly determined by a HiPPO) in a given time and extremely budget. How essential or even reasonable a feature was, leave alone measuring the impact it may generate, were seen as unimportant factors.

Time Quality Budget Product Manager

Thanks to the influence and popularity of product-centric companies like Facebook, LinkedIn, Airbnb or XING, this perspective is now dismissed from modern product development.
Instead, Product Managers are empowered to truly take responsibility for that they were building in strong collaboration with design and development teams.

Comparing the guidance provided to Product Managers for moving forward with the “time-quality-budget“ approach, it’s now more something like:
Build the right feature for proven user needs with the leanest approach to generate a significant impact which is in line with pre-defined KPIs.

Product Management Tasks - Success Criteria

This lens of looking at the success of a product manager is not only important for individual people managers but also the product manager herself.
Don’t get caught up in “time-quality-budget” madness when it comes to reflecting your performance. Take a smarter approach looking at your work.

Product Management Career Paths – Building Products vs. Building People

At one point in time, every PM will arrive at the point at which she has finally gained enough professional experience at her current or past job to climb the corporate ladder. Promotions become a thing, and product management career paths need to be discussed.
And thereby it’s not about leveling from which level, but about the act of leveling itself.

While this may seem natural at first sight and was the de facto only way to gain recognition of a good performance, things have changed a bit in the past.
Growth trajectories of people are no longer only focussed on the vertical direction but the horizontal axis in a product management career.

In the context of product management, this means that you have to choose between continuing to build products yourself compared to instead focus on making people who then develop great products.

When you arrive at the point in time mentioned above in time, I strongly advise you to take a moment to check your real inner motivators instead of immediately jumping on having a new business card entitling you as Team Lead Product/VP Product, etc.

This also the very first thing I check with applicants. By focussing on motivators of someone in the first place you can avoid a couple of uncomfortable situations to find yourself in 6 months down the line:

A great product manager joins your small team with already clear leadership ambitions, which you didn’t check in the first place and only discover a couple of months in. One of 3 things will happen:

  1. You’ll have to put him off again and again when he’s asking for a leadership opportunity. His excellence in building products will decrease, and he’ll eventually leave.
  2. You give him the title he wants, without a team though. The title will delay the disappointment, but he’ll eventually leave.
  3. You give him the title and start unplanned hiring to create an artificial team for him. He may be happy, but you created weak growth (and thereby financial burden) for your company and put way too much on the line. Only to satisfy the needs of one employee. On whom you didn’t do your hr homework.

You promote a magnificent product manager for a leadership position who accepts out of politeness but has no leadership ambitions at all and is more than happy in an executive role. Here’s what’ll happen:

  • She’s leading people based on the corporate hr playbook but remains at the same time way too involved in operational details of daily product building because that’s way more interesting (and challenging) for her.
  • Her team grows frustrated and eventually starts to quit.
  • She discovers her right motivation based on building products instead of building people and quits as well.
  • You have to re-hire a product leadership position and the individual contributor roles of that team. Just because you didn’t check the real motivators of your initial hire.

So, whether you’re a product leader hiring for a team or a PM who is approaching a ‘critical’ level of experience: Check your true motivators and whether you’re more driven by building products (and want to continue to deepen your knowledge around that) or making people (with all the trade-offs of being involved continuously in the daily product details.

Product Management Alignment – How to create it

Generating and keeping product management alignment across all levels of an organization – from C-level until the single engineer – is one of the most important (and often most challenging) for a Product Manager.
And while often suggested a simple change of habits like ‘talk more to each other’ or ‘keep a confluence page about what has been agreed’ are right, they don’t necessarily provide the right level of confidence to a Product Manager to strive at his mission.

Why Stakeholders mostly talk about Feature Requests

Almost every product manager knows the situation (if you don’t, please let me understand how you avoid it right from the beginning): Some of your stakeholders just always come up with particular features (aka solutions and no problems) they want you to build into your product.
While some of them may have learned and agreed to the concept of building an MVP first and no stuffing the first product release with more functionality, they a least insist on storing them as they are in the product/feature/idea backlog (here’s why that’s not an approach to pursue).

That’s because they’re like users – They don’t know what they want. And talking about particular features is their way to remain involved in the product development process continuously.

The key for you as a Product Manager is to determine where the urge of some stakeholders to be a regular part of the day-to-day product development process originates. You have to reverse engineer your stakeholder’s feature requests back to ‘jobs‘ they want you to fulfill for them or your target user.
The most likely reason though is that they think that the product output becomes proportionally better with their involvement.

Unfortunately, this misconception is the result of a lack of trust these stakeholders have that the delivered output by you and your development team matches their expectations.
Why that may seem like a miserable situation, the best way to resolve this issue is to focus on alignment early on in the product discovery and the commitment to a particular outcome rather than feature idea.

A better way for stakeholders could be, e.g., to drop in inspiring snapshots they’ve seen in other products with the apparent accompaniment that the way this product approached an individual problem may be helpful for your work.

How Alignment supports you in Stakeholder Management

Why do Stakeholders always come up with Feature Requests? Because they’re like users – They don’t know what they want.
Influencing the roadmap solely with specific feature requests is their way to remain involved in product development continuously. An incredible challenge for product managers within the domain of stakeholder management.

Alignment in Stakeholder Management

Why do they want to stay involved? Because they’re not convinced that the results will match their expectations. You haven’t earned their trust (yet), and they may also have a hard time giving up micro-level control over ‘their’ product.

It’s your responsibility as a Product Manager to reverse engineer their feature requests using alignment tools to get to the bottom to what they want.
Only then you can come up with better solutions than they can imagine.

So, the next time you’re frustrated with the way stakeholders articulate their need, remind yourself to treat them like your users.
Develop empathy for them, get to the bottom of their actual problems and deploy ideation and creative techniques against those problems to come up with better products.

I know, in an ideal world, we’d all be on the same page already. But on the bright side, you can count on an educational effect on your stakeholder’s minds as a byproduct of problem-centered product development.

But be sure that this is your responsibility. The worst you could do would to just built those specific feature requests.

Product Management Alignment Tools

That’s why I picked four alignment tools for Product Managers for you to grab for your next product strategy session or product discovery kick-off. Going too much into detail about how they’re used would blow the frame of this format:

Auftragsklärung

Luckily, I have been around at XING when this framework was developed. It is a mix of the influence from Stephen Bungay and Christian Becker and has been evolving through internal forces since then. Check out the full guide right here (original link is currently broken), watch my fellow Product Tank Hamburg Co-Organizer Marc speak about it attend the upcoming workshop around Auftragsklärung facilitated by Christian Becker in April at MTP Engage in Hamburg.

Intermission by Intercom

A simple but effective one pager developed from the guys at Intercom. They managed to integrate all the stuff I like the most around product development (right now): problems first, defining specific measures of success, job stories, and clear product scope.
Would love to see some writing on the actual usage from the product teams (and stakeholders) at Intercom in the future.

Asana’s Spec Template

Asana’s proposed format is similar to the Auftragsklärung but goes into a bit more detail. For example, it already requires first mocks of the solution – which can be dangerous without giving the right context to your stakeholders. Also, it also provides the opportunity to ‘attach’ (user) research insights.
While this enables a very ‘complete’ picture of the project ahead, I think it’s on the edge of making starting a project or initiative similar to filing a request. It’s meant to be a pitch document to make C level prioritize.

The Product Tree

The best thing about this format is its strong visual aspect. It’s maybe not as sophisticated as the other frameworks above, but it focuses on feature prioritization is its most significant strength at the same time. It ruthlessly forces everybody at stake to develop a shared understanding of what to build next.
Besides, its format is perfect for keeping the aligned vision always visible in the team space.

‘Working Backwards’ by Amazon

While there’s no official material on this framework, it’s widely confirmed and well-known in the product manager community. It’s the result of Jeff Bezos’ approach to cut subjectivity and fluff of product development. The result is a document which shouldn’t exceed a page and a half in length which needs to be provided to meeting participants before, e.g., a kick-off meeting for tackling a new product.
Never used it in ‘production’ but will do shortly.

Alignment doesn’t need Agreement

When I talk about the importance of alignment and the several frameworks to create it, I often hear questions regarding what those are for and what the goal of the invitee/creator should be when walking critical stakeholders through an alignment process.

When I then explain that, at the very end, it’s all about getting commitment/buy-in, a typical response is something like that: “Ok, so, I need to convince everybody to agree with my point of view.” And this way of thinking often leads to the initial rejection of an alignment process, because people then don’t see any chance at all, to get individual stakeholders to agree with them on the process ahead.

That’s why I wanted to use underline the importance of not confusing alignment with an agreement. The way more critical part of alignment is commitment. And it’s way easier to get the commitment from your stakeholders, then making them agree.
I stole a beautiful phrase from the most recent shareholder letter Amazon CEO Jeff Bezos just recently published and which I’ll cite blow in a minute: disagree and commit.

Third, use the phrase “disagree and commit.” This phrase will save a lot of time. If you have conviction on a particular direction even though there’s no consensus, it’s helpful to say, “Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?” By the time you’re at this point, no one can know the answer for sure, and you’ll probably get a quick yes.
This isn’t one way.
If you’re the boss, you should do this too. I disagree and commit all the time. We recently greenlit a particular Amazon Studios original. I told the team my view: debatable whether it would be interesting enough, complicated to produce, the business terms aren’t that good, and we have lots of other opportunities. They had a completely different opinion and wanted to go ahead. I wrote back right away with “I disagree and commit and hope it becomes the most watched thing we’ve ever made.” Consider how much slower this decision cycle would have been if the team had actually had to convince me rather than simply get my commitment.

This example perfectly outlines a position a manager should take when working together with an empowered team: It’s fair to have a different opinion in your mind and articulate it.
But when your team of experts then chooses a different path to pursue anyway, you must have their back as if they’d follow your suggestion in the very same way.

So, coming back to the difference between aiming for agreement and commitment in an alignment process, a proper comparison is also to take bets, close the process and back them 100% compared to endless rounds of discussions to get harmonizing everybody’s opinions for the sake of it.
If you’re facing the latter one frequently during internal discussions, it’s also a very fundamental cultural issue within your company. Focus on consensus instead of embracing conflicting opinions.

Which format, framework or result of common sense are you using right now to create and follow-through on alignment within your organization?

Product Discovery – A Step-by-Step guide (incl. FREE Planning Template)

Nailing the Product Discovery is an ambitious task for every product manager. Here‘s a hands-on plan for approaching it.

When the roadmaps for the year ahead get crafted, you should place the topics you and your team want to tackle on a timeline.
Most often, the topics result from the epics you’ve worked on before, user feedback or top-down business goals for your department.

So it’s mostly pretty clear what to work on from a high-level perspective. But the remaining questions for you as a Product Manager are which problem exactly needs to be solved next and how can you generate the biggest impact?

This is the point at which a well-prepared and insightful product discovery enters the stage.

Product Discovery Definition

In a nutshell, a product discovery is about ensuring that the right product gets built for the right audience.
It’s the foundation for a successful implementation and launch phase later on and should give you as the owner of the product the confidence to represent your product vision towards your team, your stakeholders, and the upper management.

You’ll quickly notice that, as soon as you discuss your upcoming roadmap topic with anybody, a lot of people will have a strong opinion about the ‘right’ solution.
Particularly in the beginning of a product discovery, you need to stay focused on the problem and avoid falling in love with a solution. The opposite would be to eventually build someone else’s product with which you cannot identify over time and for which you don’t want to stand in for.

So, it’s pretty important to nail it down the right way. Most often, the problem to crack is not even the hardest part here, but orchestrating the available resources in a given period is.

Product Discovery Process

At XING, product management is part of the company’s DNA. This attitude and high ambition level resulted in several product-related initiatives to broaden a product manager’s toolbox for tackling the daily challenges we face.
After focussing on clarifying the intent of a project, we took a deep dive into the so important product discovery phase. The result was a sort of framework from my colleagues Cord, Marc and Sebastian.

Product Discovery Framework
Get the template as fully scalable .pdf right here

This template is a perfect starting point when planning your next product discovery. It divides the time ahead into 3 phases with different levels of granularity and ‘forces’ you to name the key stakeholders, make a commitment to timing and lets you focus on concrete outcomes already in the discovery phase.

Let’s go briefly through the single sections, discussing their context and giving you some examples regarding what to use at which point.

Phase 1 – Goal, Ideation & high-level concept

Phase 1 for you Product Discovery: Goal, Ideation & high-level concept

The first phase is easy to compare with an as large as possible bird’s-eye view on the topic. You should take one or multiple steps back, involve a lot of smart people who can bring an additional angle to the table and let yourself go through various approaches multiple teams.

By the end of it, you and the key stakeholders should have laser-sharp understanding about the goal you want to achieve (more about how to approach that in the Tools section below), gathered all the qualitative and quantitative indicators you may need and ideally have clarified as many impediments as possible, so there are no excuses left for getting shit done in the following phases.

Here are some key questions you should be able to answer after this phase:

  • What problem will your product solve?
  • How do you identify a good solution (e.g. metrics)?
  • How big is the opportunity?
  • What is the plan for the discovery?

Phase 2 – Hypothesis & Test

Phase 2 of your Product Discovery: Hypothesis & Test

After setting the stage, you should gather the most prominent experts for this project around you and approach the real concept together with them.

This phase is about focused and intense work in dedicated groups around the key user problems to crack. You’ll produce a ton of outcome in the form of prototypes just to throw 90% of them into the trash after talking to your users. And then do it all over again.
See the point? While the first phase focusses on solving a lot of meta topics, the hypothesis & test phase should give you the first solid confirmation that you’re on the right track.

You probably won’t involve many stakeholders besides the core team, but you’ll keep them informed and should at least once check-in with them in the process when you’re halfway and almost done.

Here are some key questions you should be able to answer after this phase:

  • What are the hypotheses you want to test?
  • What do you prioritize?
  • How to make tests usable?

Phase 3 – Requirements & Synthesis

Phase 3 of your Product Discovery: Requirements & Synthesis

Now it’s time to filter what you’ve produced in the second phase, crunch it together and make some decisions about what to pursue in your way of starting development.

It’s a good checkpoint to sync the produced output against your intent from the start and take may needed adjustments – on both ends.

While seeming seductively smooth, you shouldn’t underestimate this phase. It’s the time during which you have to stand-in for the taken decisions and defend your concept against may occurring concerns from all sides.
Those nitty-gritty discussions will especially appear while adding the final touches to the Visual Design and estimating first tickets with your whole engineering team. Those tasks usually require a lot of your intention, and you shouldn’t be occupied with zooming out too much of the topic just to counter someone’s arguments.

Here are some key questions you should be able to answer after this phase:

  • What does the solution look like for the customer?

Product Discovery Tools

An Example Impact Map for your Product Discovery
Image by impactmapping.org

As a Product Manager, you’re probably able to orchestrate a broad range of tools to get the right answers to the different questions you have to answer along the way.

The trick is, of course, to not just apply them randomly depending on your mood or the hipness of a particular tool. In fact, most tools only work best in a certain phase and are not universally applicable.

It’s, for example, a pretty good idea to get everybody on the same page by writing an ACE in the first phase of your product discovery, instead of trying to hectically achieve stakeholder alignment when you’re in the middle finalizing the Visual Design.

When formulating the goals of a project, you probably want to take a deep-dive into existing analytics as early as possible, so you not only get critical insights into the status quo while doing first user tests.
Other great tools for the ‘Goal, Ideation & high-level concept’ phase are e.g. the Jobs-to-be-done framework, a User Storyboard, a Marketing Position Paper or an Impact Map.

Hint: I also created a high-resolution impact mapping template to use right away for your own map.

During the second phase, it’s all about producing output and validating it as lightweight as possible.
You maybe want to consider a focussed Design Sprint with the relevant stakeholders for a bunch of rapid prototyping or co-creation sessions with your target group to build the product close to their needs.

The art of validation is executed best when you can avoid ‘wasting’ engineering resources before having more proof. So you should search as many contacts with users as possible with a click dummy/prototype. Good ways to reach your users during this phase are either guerilla sessions at your local coffee shop, putting together an e-mail presenting the core mechanic or just perform a specifically recruited user interview.

Another Impact Map or User Story Mapping are neat ways for bringing your discovery output together in a structured way when approaching the start of development.

Product Discovery Teams

While your development team is probably in a pretty solid state, the range of people which matter during the different phases of your discovery is not.

That’s why it’s wise to create an overview of the people you need to just keep in the loop along the way or which are critical gatekeepers you need to have aligned with your plans.

It depends on the size of your company, but a differentiation between the actual (value-producing) core team, key stakeholders (owning the budget) and certain individuals who own mission-critical assets has proven to be quite useful.
Examples of the core team are Product Owners, dedicated designers, and engineers. The primary stakeholders are mostly impersonated as Product Directors or even VPs. Besides that, you might want to watch out for horizontally located POs in associated domain topics or universally dedicated teams like customer care or Business Intelligence.

Obviously, you should always be clear about the prioritization of those group of colleagues. Nobody should expect equal involvement at every phase.

Product Discovery Planning

When you can take the time to split a discovery up into different phases, it’s important not to lose sight of the timeline you’re committed to.
Even when your project has more of an explorative character, you shouldn’t just go along without considering how much time is reasonably spent on each phase.

And you also shouldn’t feel bad to just set your best guess as a first estimate for timings. Don’t think of milestones as limitations, but rather use them as constraints which will give you as the Product Owner the best arguments for condensing the generated output into concrete deliverables.
It’s also a good mechanic to frame the scope of the project for the people you work with.

Don’t be scared of moving the milestones you’ve set if you have to and if you can provide convincing arguments. Your initial estimation could only have been based on the situation as you knew it ‘back then.’
If the situation has changed in the meantime, it’s more than fair to communicate the impact of this change to your key stakeholders – As long as you do it early on and are transparent about the impact.

Product Discovery Results

Deliverables of a Product Discovery

When defining the timeline, the needed days, weeks or months are determined by some given constraints like available resources or outside-driven events like press releases.
When it comes to measuring the success of a product discovery, and it’s initial phases, you can apply the same rules as for the overall project when you’ve shipped something: A product will only be as good as the outcome it generates.

While it’s difficult to put concrete measures on the results of a single phase, it’s rather easy to define specific deliverables for every stage you want to accomplish.
Having tangible objects to check off after each phase also prevents you from just moving along for the sake of the timeline.

For creating a convincing story within your discovery, the produced deliverables should always lay the foundation for the first step in the next phase.

Here are some examples you may re-use for your planning of the single discovery phases:

  • After phase 1: Agreed and committed ACE, Analytics deep-dive or user survey, concrete hypotheses for the final product
  • After phase 2: Agreed concept including release packages, Clickable prototypes, quantitative or qualitative validation of your hypotheses via user interviews or e-mail experiments, Planned AB-tests
  • After phase 3: A mapped user journey through your product, Final visual design for first stories, Groomed and estimated tickets in your backlog, Defined implementation of tracking

Summary

Planning your product discovery might seem like a bureaucratic overhead to you, especially in the beginning when you just want to get going and produce stuff.
But especially for products which either include a complex stakeholder environment or provide a hard problem to crack, this upfront invested time will help you along the way.

The main benefit of a neatly planned discovery is simply better output and a drastically increased chance of achieving your outcome goals.
Seemingly more like a side effect, but not less important: It’ll be so much easier for you to make progress visible to your stakeholders along the way so you can focus on the important things which matter to you.

If you’d like to discuss the provided framework or want to know more about how product discoveries are performed at XING, hit me up using the chat on the lower right or on Twitter – I always love to see my assumptions challenged and get new input from other people.

Additional Resources