Let’s first clarify what I mean by Product Discovery. It is an iterative process that consists of research, experimentation, and conceptualization activities. This allows you to reduce uncertainty around an opportunity or idea to make sure that the right feature/product gets built for the right audience. This is how I visualize the process:

If you zoom out, discovery and delivery should both be continuous and run in parallel cycles:

You can learn more about discovery by digging into the reading material in the appendix.

1. Understand and evangelize why discovery matters

The core problem with discovery: Important but not urgent.
Discovery is like eating healthy or exercising regularly. If you don’t do it for a while, you don’t immediately notice a problem, but once you eventually notice it, it can be hard to reverse your habits. For example, you can ignore customer needs for some time and pretend that your marketing doesn’t work, your solution is buggy, or some features are missing until you run out of money or learn that you actually haven’t solved a real problem. Delivery, on the other hand, is urgent and important. When your engineers don’t have work to do, management gets nervous about the most expensive employees not being productive.

The key mindset change to make Product Discovery work: Outcome over Output.
Most CEOs ask me “How can we ship features faster?” However, this is the wrong question. Every feature you build makes your organization slower because you’re adding complexity (legacy) to the system which you have to maintain and incorporate for new things you build. Thus, the key question is actually, how to ship fewer features (e.g. 7 instead of 10), but ensure that a higher number of features delivers on the expected outcome (e.g 5 instead of 3). Product discovery techniques let you test more ideas and help you increase the success rate of the few that make it into delivery.

Other essential mindset principles are:

1. Understanding the underlying problem(s) deeply over falling in love with the first solution
2. Identifying and de-risking critical assumptions over building right away
3. Continuous discovery over irregular, long lasting research efforts
4. Openness to failure over fear of being wrong
5. Collaborative, cross-functional discovery over silos and HIPPOS

It is very hard to make time for product discovery if your executive team and product leader(s) don’t understand what product discovery is, why it matters, and ultimately have a fundamentally different mindset towards it. So, it is worth digging deep into why discovery matters and into the necessary discovery mindset. Then start to educate other people in your company and experiment with discovery methodologies. This will slowly increase the awareness and the willingness to invest time and money into discovery.

2. Include the discovery in your roadmap discussion

You cannot run a discovery for every single idea and problem (opportunities) the company has. Thus, you need to do an early prioritization to align which opportunities have the best chance to deliver impact on your objectives with reasonable effort. Make the discovery step explicit in your roadmap and limit the number of opportunities that one team can discover at the same time. This will help you to make discovery efforts more visible and manage resources around it. I published a detailed article on my approach on roadmapping which can help you to implement all of this.

3. Empower engineers to take ownership of the delivery

Make it clear to your engineering team that they own the delivery and that you are open to support. This point has probably the single biggest impact on freeing up discovery time. In many companies, PMs act as project micromanagers who take care of every delivery detail and handhold engineers along the process. You should focus on understanding the business and user problems, which you should present to the team in the form of powerful epics and user stories, alongside additional context (“the why”). Leverage the team to conceptualize and test solutions, and ensure that everyone understands the functional requirements to deliver the solution. You should not own the technical details and decisions, as long as they are not a key functional requirement. For example, if your new feature is a public API, you might be involved in the API design. In most other cases, you should stay out of this discussion.

Occasionally, you need to let your engineering team run into making a mistake and allow them to learn from it, even if you could have prevented the mistake. If you proactively take care of all problems, it makes them feel that it is not their responsibility. If you see them struggle or run into issues, help them figure it out by themselves by asking good questions: “How could we simplify this part?” “What is the biggest unknown?” “What would happen if [fact] is not true?”.

The following 3 tips closely connect to this topic, but go one level deeper.

4. Delegate operational release management

Overseeing all details of a release is very time-consuming. While you should certainly be involved in release communication, especially when it comes to rolling out larger initiatives that require close alignment with stakeholders, it’s not the PM’s job to ensure engineers are aligned or integration/regression testing is completed prior to release. Make your engineers (or engineering lead) own these things.

A simple Slack channel with all release updates is very helpful. I like to distinguish between three types of releases:

1. Hotfix: Small fixes release as a follow-up on a minor or major release. Entirely coordinated by engineering.
2. Minor: Small improvements, bug fixes and changes. Entirely coordinated by engineering.
3. Major: Big new features or products. One PM takes the communication lead and one engineer the technical lead.

5. Delegate quality assurance

Quality assurance is essential, but also very time-consuming and complex. You have probably learned it the hard way when your stakeholders started pressuring you after a release with some major bugs. Many PMs then take over the role of a QA analyst. Some companies have dedicated QA people, while other companies embed the responsibility into the engineering team. Whatever approach you choose, the technical lead (CTO) needs to make sure that processes, tools, headcount, and mindset for high-quality delivery are in place. Involving QA early on (e.g. later stage discovery and/or certainly latest when kicking off a new initiative) will increase quality while freeing up valuable time for you downstream. It’s worthwhile to check in with QA regularly and/or get involved in testing major acceptance criteria of strategic features, but you cannot take over the role of QA.

6. Focus your delivery time on grooming and planning

If you don’t take time for proper planning, you will pay the price by having questions pop all the time, requiring your attention to unblock the engineering team and drop everything else. The better your grooming and planning process works, the more you can focus the remaining sprint on discovery. No matter which exact methodology you are following (Scrum, Kanban …), I suggest you do grooming and planning. The grooming helps you to prepare the next planning session, identify open questions, avoid oversized stories and bring the acceptance criteria of your stories to 80%. I recommend splitting the planning into a product and a technical planning. During the product planning, you align on the scope for the next cycle, go through the final acceptance criteria and align on the complexity of your stories. In the technical planning, the engineers take the lead to break down the stories in technical tasks and align on the execution plan for the coming cycle. For larger initiatives, I found it necessary for engineering to have separate follow-up sessions to complete the technical planning. Exchange with peers, read about best practices and experiment with your process to improve your planning work.

7. Delegate product design

I have consulted countless leaders who expect their product manager to take over the product designer role (PD). You should not hesitate to create wireframes to communicate your ideas. You may certainly act as a coach and leader to junior designers. However, doing good product design is a full-time role. Great PDs take over a lot of responsibility around research and user testing. If you have no designer or an unqualified PD, it is your responsibility to highlight this gap to your manager, as you won’t be able to live up to the expectations of your product role. You should be open to support on the design front, but this means you will make compromises on other parts of your PM role.

8. Ensure regular retrospectives to foster engineering ownership

Running retros regularly helps to improve accountability and empowerment of your engineering team cycle by cycle. The retrospective allows the team to take a step back from their process and discuss impactful improvements. This will enable them to carry more and more delivery responsibility, while you will free up time for discovery topics. Unfortunately, many teams are not making retros a regular routine. Work with your engineering lead to help create these routines (I suggest having them every 2–3 weeks). Moreover, many teams fail to define clear action points and don’t follow up on these actions at the beginning of the next retro. Having a facilitator in the retro session will help to address this problem.

9. Get an agile coach to support the delivery team

If you feel overwhelmed in acting on the recommendations explained in the above paragraphs, get an agile coach to support you. The first agile coach we hired at N26 was a game changer for the product team. Not only did our delivery work improve, but we were finally able to free up more time for concept and research work. We waited for our product organization to grow to 4 teams until hiring our first agile coach. This was too late. Depending on the seniority of your PM team and engineering leaders, you may consider hiring a freelance agile coach as soon as you have more than one product team. Having an agile coach who can temporarily act as a scrum master to help the team help itself, is invaluable. However, I don’t believe that you need a permanent scrum master for every team.

10. Don’t be the only one responsible for discovery

Taking on all discovery responsibilities on yourself as PM does not scale and will lead to suboptimal results. Instead, you should have a complementary trio of product, design, and engineering skills. If your product designer and engineering lead also understand the importance of product discovery and their role in the process, you can hold each other accountable and support each other to free up time. In some cases, you may even have someone from the data or marketing team join the regular discovery work.

11. Introduce discovery planning to create focus and alignment

Taking time to frame and plan a discovery means some time investment upfront, but comes with a number of benefits. The quality and efficiency of your discovery will increase. Moreover, it will help you to manage expectations and create alignment and buy-in. Discovery planning is a broader topic that deserves a full article. In short, get all the people who might be valuable contributors in a room (or call) and align on the following points around the opportunity you seek to discover:

12. Optimize recurring activities to prevent last-minute distraction

Product management teams have to regularly review their planning and delivery process, to standardize and automate recurring PM activities. These activities can easily become very time-consuming and distracting, if handled “last minute”. Two such examples are tracking and managing translations. Have a clear process on how to define, document, review, and test your tracking efficiently. And start thinking about tracking when you specify the requirements. Otherwise, you either forget about it and cannot track the success of your delivery, or squeeze it in at the last minute.

Managing the copy and translations can be very time-consuming when you don’t use a tool that allows you to make changes with a few clicks, on the live system, without an engineer involved. It takes 5x more time to make a wording change if you need to create and process a ticket, or need to upload and download some files. Just implement a tool like phrase or smartling and this problem won’t consume your time.

13. Be okay with engineers “not being busy”

Instead of going into planning with something that is not thought through and properly de-risked, you should rather be open with your team and tell them that you will need a few more days. Starting to develop new features prematurely will only lead to downstream fire-fighting, or worse, have the team work on something that ends up being irrelevant. Agile means being flexible, so you don’t need to wait for the next sprint to start. Push the planning back by two days if necessary. Don’t become a slave to your process. Your engineers can use the time to work on meaningful improvements. They should create a separate backlog for tech improvements that help the team to be faster and more robust in the future.Your TechLead should manage it and coordinate with you.

Making time for product discovery is a result of many small steps.

If you are new to discovery, it will feel a lot more time-consuming at first. This is true for all complex things we do for the first time. Thus, you need to build a toolbox for product discovery and routines that allow you to run it more efficiently. However, the most important thing is to make a little change and reflect upon it. Then make the next adjustment. This reflection template can help you do that.

Additional Reading Material

• If you are curious what role product discovery plays in a product mangers’ skill set, take a look at the article I recently published. You will see that discovery is one of four essential process skills/techniques. Decoding Product Management — A skill matrix to grow, coach, assess and hire world-class PMs
• Finding a meaningful balance on how much time you spend doing discovery on a specific opportunity is very difficult. This is an interesting take on this question: How much Product Discovery is Necessary? | Roman Pichler
• Empowering your team to own the delivery is very difficult. Radical candor is the best leadership book I have read, and “Empowered” also offers a few good ideas on how to deal with the challenge.
• This article provides a great introduction around the “mindset” required for discovery
• Understand problem first vs. solution first
• Go deeper to Outcome vs. Output
• Test before building, this is the must have book on experimentation for every PM
• If you want to go deep on openness to failure, I recommend blackbox thinking
• Teresa published one of the first book entirely focused on product discovery. Definitely worth reading: Continuous Discovery Habits
• Tim Herbigs article on Product Discovery is a great summary to get a full overview of what product discovery actually means. He also briefly introduces some important frameworks. Product Discovery: A Practical Guide for Agile Teams (2021)
• Get some inspiration on how to do the discovery planning / framing:
• Planning Product Discovery — Silicon Valley Product Group
• How to kick-off Discovery Sprints, reframe a problem and align your team
• 25 Questions To Cover In Your Discovery Kickoff
• Balancing Discovery and Delivery is very hard, here are a few tips to consider it you struggle with this problem: The Product Leader’s Guide to Balancing Product Discovery and Product Delivery — Petra Wille
• Brandon published a number of great articles and is really worth following. To make time for discovery and strategy, you need to free yourself from micromanaging deliver and handholding engineers: Applying Leverage as a Product Manager
• Good user stories can be essential to empower your team. Here is some inspiration for how you might want to improve your user stories.
• To continuously grow your skills, you should also reflect by reading (articles, books), listening (podcast) and/or watching (video) content on discovery. Here are 15 great discovery related videos that can help you reflect on your discovery experience The 15 best product discovery talks to help you build better products

Roadmaps can exist on various levels. However, we will focus on the roadmap that you spend the most time with and which connects your operational doing with your strategic objectives. I call it the roadmap pipeline. This pipeline reflects the opportunities you bet on to deliver on your objectives and strategy.

Good roadmapping requires a clear strategy and clear objectives. If you don’t have objectives, you can’t do a good job in prioritization. More on this in section 3 and 4.

The structure of this article:

1. Section: Explanation of the Roadmap Pipeline approach
2. Section: Outline of 3 routines to make this approach work
3. Section: How to use a prioritization framework like ICE within the roadmap pipeline
4. Section: Recommendations and pitfalls if you plan to implement this approach and how to scale it across lager teams
5. Section: A short take on other forms of roadmaps I regularly use

1. A roadmap pipeline to triage opportunities

The roadmap pipeline helps to evaluate your roadmap on a continuous basis. I don’t believe in defining a roadmap only once per quarter. The roadmap pipeline helps me to keep an overview on all major things within my area of responsibility. It is a tool to create focus, alignment, and peace of mind as it is my cockpit to facilitate my product efforts.

The roadmap pipeline is a simple Kanban board with a few important tweaks. Here is an overview on the board. I will guide you step by step how I use it:

New topics can come from anyone.
Collect new topics in the first column. I like to call these topics opportunities. However, I name the column differently, so everyone understands what an opportunity actually can be. I suggest allowing almost anyone to drop new opportunities in. At the scooter sharing startup Circ, we have introduced limitations for operational employees (blue-collar workers) as their team grew too fast, leading to a high number of duplicates. Thus, new opportunities were submitted to the local head of operations, who filtered duplicates out right away. When someone submits a new opportunity, I expect them to answer the following questions:

1. Description of the opportunity
2. Expected outcome if we tackle the opportunity
3. Existing proof why the outcome is expected

Keep it as simple as that because for most people even these three questions are hard to answer.

This is how an example request might look like at this stage:

Triaging opportunities to do a first prioritization.
Only PMs should make changes on the board, except for creating new requests and commenting. I expect PMs to block time every week to go through the first column and do an initial assessment on all requests within their area of responsibility. In case a request cannot be clearly assigned to a PM based on their area of responsibility, we quickly align via Slack to decide who takes ownership for the given request. This initial assessment follows these four steps:

1. Step: The PM tries to understand the opportunity, the expected outcome, and the relevant proof points.

• If information is missing, the PM may either continue if the request still seems clear enough or park the request in the column “initial assessment”. In this case, the PM reaches out to the requester to understand the opportunity in more detail. This might mean reaching out to a customer who has requested something via customer service, or simply reaching out to a colleague.
• The PM should rephrase the original version to make it more clear and add context if required. More specifically, I recommend rephrasing titles in the form of a problem statement, as stakeholders often like to propose solutions.

2. Step: The PM does the priority scoring (explained in section 3 “Prioritization”)

3. Step: The PM takes a decision to put the opportunity into one of the following columns:

• [Later]
• [Next]
• [Discovery Now]
• [Not in the next X months]

The priority score can be a guideline for this decision. The final call should be made by the PM, though. It has to be based on what they think has the strongest contribution to the company objectives.

4. Step: The PM leaves a short comment why they have decided to put it in the given column.

The [New] and [Initial Assessment] columns should be empty by the end of each week. This is how the board might look like:

This is how the board might look like:

Here is how an example opportunity ticket might look like after being triaged. (I recreated it, as we were not using this system at N26 back then, but the content is very similar):

Sort opportunities in [Later] by priority and limit the number of opportunities for [Next].
The [Later] column is usually quite busy. Hence, it can help to sort items by priority. On the [Next] column, make sure to limit the number to a few impactful opportunities (about 3–5). This will help to focus the discussion on what the most critical opportunities for upcoming discoveries are, and help everyone to keep an overview.

Split [Now] into [Now Discovery] and [Now Delivery].
In most roadmaps you see a single column [Now] mixing topics that are in discovery (research, validation, and concept work) and delivery (agile implementation of user stories). Both discovery and delivery should be continuous processes, and most PMs are working on topics in both areas at the same time. However, there is a major difference between the opportunities in discovery and delivery. Opportunities in discovery come with much more uncertainty than opportunities in delivery. Your main focus in discovery is to learn, understand, ideate, experiment, and validate. Oftentimes something rather unexpected comes out of the discovery. These are three common cases:

1. Dropping: You learn that the opportunity you expected to deliver a lot of impact with little effort is precisely the opposite and not worth pursuing. Thus, it is important to stay open to the idea of entirely dropping opportunities during, or as a result of a discovery process.
2. Splitting: You figure out that it is best to split an opportunity into different sub opportunities or versions. For example, at Circ we investigated the topic of offering a public API. The discovery resulted in splitting the topic in three opportunities (versions). Version one progressed into [Now Delivery], while we put version two into [Next] and version three into [Later].
3. New Opportunities: Product discoveries often result in identifying opportunities very different from what we were initially looking at. For instance, one discovery may bring up several new opportunities that need an initial assessment and might be more promising than the opportunity you were looking at.

A great side effect of splitting the [Now] column into ‘discovery’ and ‘delivery’ results in increased awareness around the importance of discovery and the staffing bottlenecks related to it. I recommend limiting the number of opportunities in [Now Discovery] too. It will help you to focus and deal with the reality that no team can run several discoveries on different topics at the same time effectively.

[Not in the next X month] is an effective way to decline.
Many product managers find it hard to say NO without harming the stakeholder relationship. Consider a colleague from marketing who approaches you with the idea to build a referral system. For most companies, this tends to be a good idea. However, whether it is a good idea right now depends on the current situation of the company. If growth, in particular organic growth, is not a company objective right now, you better put the referral system into [Not in the next 6 months]. So, you are not saying that it is a bad idea. You are just saying that it is not the right topic regarding the current objectives.

Let people challenge you and be open to change your opinion.
The roadmap pipeline should create transparency and invite others into the strategic discussion of which opportunity is most likely to succeed. So, if you put something in [Later] or [Not…], and stakeholders complain, invite them to deliver more data on the expected impact on the current objectives. You may even team up with them to help them test their assumptions. Tell them to pull the opportunity from [Not…] into [New…] when they have new data or whenever the company objectives change.

The roadmap pipeline cannot cover 100%, but 80/20 is enough.
It doesn’t make sense to have every little improvement included in the roadmap pipeline. At Circ we defined the limit of at least 2 days of expected engineering work in order for an opportunity to be reflected on the board. For dealing with small requests consider one of the three options below and leave this decision entirely to the PM:

1. Grouping: If you receive a lot of small improvement requests around one feature, for example, your dashboard, you can collect them under one opportunity “Dashboard version 2” or “Dashboard improvements” and put it into [Later] or [Not]. Whenever you see that improving a metric around the dashboard becomes a priority, you pull the topic to [Next]. You define a clear outcome, such as “increase user satisfaction (or adoption, retention…) with our dashboard by 10%” and start a discovery. The small improvement ideas collected on the “Dashboard version 2” can serve as valuable inspiration for that.
2. Build right away: Take the topic into one of the soon upcoming sprints (into the development backlog). You can agree to spend a maximum 10–20% of the team’s time on such small topics that take the fast lane.
3. Ignore: Remove the request from all boards. If it comes up again and again, with good reason, consider option 1) or 2) from above or put it into [Not in the next X month].

Engineering projects should be reflected on the roadmap as well.
Major refactorings or infrastructure efforts of teams should also be reflected on the roadmap pipeline. Management should be aware of these projects, and they should also undergo structured discovery thinking. Small refactors and technical improvements can be treated as described in the previous paragraph.

The roadmap pipeline should help you find a balance between intuition and data-driven decision-making. It is impossible to research and validate every single input and idea that people have. And it is not smart to rely solely on some manager’s gut feeling and build right away, as building is the most expensive way to test. Thus, I recommend using your intuition and available data to pre-prioritize topics. Then run a proper product discovery on a number of selected opportunities. This generates additional insight and data, and will help to make a more informed decision, which opportunities are most likely to enable you to achieve your objectives.

2. Introduce these 3 routines to stay aligned

1. Weekly triage: If you don’t do this, the whole roadmap approach will fail.

Set up a weekly triage meeting or block time for yourself to do the initial opportunity assessment of the new request and update other tickets if necessary. If you don’t do this, the roadmap pipeline will be outdated and everyone will stop working with it. Start by building a habit for yourself and add people over time. These can be parts of the scrum team, the whole scrum team, or a key stakeholder (e.g. Marketing Manager for Growth teams). Find out what works best for your organization.

2. Roadmap alignment: To leverage collective intelligence and maintain a focus on outcomes

I recommend meeting every two to three weeks. Invite key people of the team(s) (PMs, Design Lead, Tech Lead), your department lead (VP Product, CTO or their like) and maybe some key stakeholders. At Circ, we had three product groups (tribes) and three roadmap pipelines. We had one roadmap alignment per roadmap pipeline. More on that later.

Product managers have to lead and prepare the meeting (not the VP Product or CPO, but PMs who run tribes and/or squads). This is the most important product meeting to connect operational doing with strategy. It is also the hardest meeting to run for PMs. You want to avoid being overconfident and defensive, but you also don’t want to be full of uncertainty and not have an opinion. PMs should act as facilitators of the roadmap discussion. This is how I suggest structuring it.

1. Start with a short update on the current status of the OKRs of the team(s). My favorite question at this point is, “From 0–100%, how likely do you see your team achieving OKR X by the end of the quarter?”
2. Do a short update on what has changed around opportunities that are in [Discovery] and [Delivery]. If you are well-prepared, you will be able to share a short statement about each of the items to have everyone on one page. This is what you might say:
   ** Opportunity A has been successfully delivered, and I will share with you the initial results of the release via Slack later today.
   ** Opportunity B is blocked for a few days by a technical issue. Max is confident to resolve it soon, in the event we need further help we will let you know.
   ** Opportunity C got kicked off. I have shared a short summary on the scope for version 1 over Slack early this week. We will focus on it in the next 2 sprints.
   ** Opportunity D, the discovery is completed, and we decided to build an MVP to validate this solution on a next level. I will attach a summary of the findings in the follow-up of this meeting.
   ** Opportunity E, the discovery came with many unexpected learnings, and we concluded that we should not spend more time on this topic in the next 6 months. I will also share the summary with you.
   ** Opportunity F, we’ll kick off a discovery on this later this week. Let me know if any of you want to be involved in the planning session.
3. Share an update on the most important new requests and how you have assigned them on the board.
4. Mention other essential changes, such as, we prioritized Opportunity G from [Later] on top of [Next].
5. Let everyone know what questions you would like to get their input on.
6. Let everyone ask questions and challenge you.

Focus on prioritization discussions and avoid going into details.
The focus of this meeting should always be around the question “What opportunities/bets should we prioritize next, to have the best chance to achieve our OKRs”. Focus the discussion around this question. Push all other, more detailed discussions into smaller follow-up meetings and asynchronous communication. You can let people ask questions and have short discussions while you do your update (step 1. to 4.), but always ask them “Is this question/discussion helpful to make a better decision on our priorities or can we have it later?”.

If some stakeholders seem to have problems listening and always drift off in detailed discussions (particularly CEOs), then only allow clarification questions on the things you say during step 1.-4. Tell them to write down all other questions and address them in step 6. I usually guide them directly through the Kanban board. If you feel that it is too much information to process for them, you can screenshot each column of the Kanban board and put each on a single slide of a presentation.

Plan for 45 to 90 minutes
In a smaller group (4–6 people) who have done this meeting several times, you should be able to go through it in 45 minutes or even less. For larger groups and in particular groups who only recently started the practice, I would rather plan for 60 to 90 minutes. However, the quality and time depends on the preparation of the PM and the way the PM runs this meeting.

3. Synchronize your roadmap with the latest Objectives

After you have kicked off a new quarter and defined OKRs for the new quarter, you need to reflect the updated OKRs in your pipeline. This might mean changing some priority scores or reviewing the [Later] and [Not…] column for opportunities that might be worth considering, given the changes. I recommend blocking 1–3 hours at the beginning of the quarter for this routine, depending on the size of the group and how much your objectives changed compared to the previous quarter.

3. The ICE score applied to the roadmap pipeline

There are countless product prioritization frameworks out there, and I encourage you to try many of them and find out what works best for you. My favorite framework to help me prioritize is my iteration of ICE. I prefer it because it is simple and covers the 3 key questions you need to think about when deciding about priorities: Impact, Confidence and Effort. I went back to using ICE from using RICE because too many people struggled with handling Reach and Impact. This took too much focus away from the actual discussion. Most companies start far too complex and end up not using anything consistently over a longer period of time across the whole organization. Start simple and once a framework (and the surrounding process) is established, evolve it and possibly increase the complexity.

Use it to make your prioritization transparent and increase the discussion quality.
Even a simple framework like ICE will 10x the discussion around priorities. It makes it so much easier for everyone to challenge a decision taken by the PM or team. Instead of asking “Why did you prioritize this opportunity so high?” they can ask “why do you think this is so complex”, “why are you so confident on the impact of that opportunity” and so on.

Using ICE is simple. You choose a factor/multiplier for each of the 3 parameters. I recommend a simple scale of 4 to 6 difference levels or using Fibonacci numbers. A scale of 10 is so hard to use. What is the actual difference between 6, 7, 8? It is much harder to synchronize people on such a scale.

This is how a scale of 4 can look like. Adjust the terminology to your company, but keep it simple to start with.

Impact on objectives, not user or business.
When talking about impact, people have different opinions about what impact you are referring to. Rating the impact on your current objectives is most powerful. Your objective might be to increase the NPS, in which case it is very user-centric. Your objective might also be to improve the payment conversion rate, in which case it is more of a business metric with user impact. Approaching it this way will make sure your roadmap is in sync with your objectives, strategy, and vision. This only works if you have clear and meaningful objectives. I recommend looking at team level objectives first. They should be in sync with higher level objectives. If there is a conflict or uncertainty on a few opportunities, we move a level up and challenge them against the department or company objectives to widen the perspective. The value of scoring impact comes from relative comparison. So, if we take 3 opportunities, do we believe they have equal impact, or does one of them have slightly or clearly more or less impact?

We are often overconfident when judging opportunities.
Your focus should therefore be placed on finding and generating evidence (data) that will increase the confidence score. This habit will encourage your team to have data-first discussions and run experiments or discovery processes to generate confidence on larger opportunities.

Complexity estimates over time estimates.
When we name it ease instead of effort, we tend to think in complexity rather than in effort measured in time. In my experience, the discussion about complexity leads to better insights than the discussion about time. While I would never use a time equivalent when estimating user stories, I am open to using a rough time estimate when we try to understand the costs of a given impact to be delivered. This can be helpful to manage stakeholder expectations. I usually limit it on the complexity/time of the delivery of the opportunity.

The priority score is a guideline.
You should not blindly decide upon the score. It helps you to highlight important topics, create transparency on your prioritization decision and is a great conversation starter. At the end of the day, the final decision should be taken either as a team or by a responsible product leader or executive.

Update the priority score as you learn more.
Through the process, but particularly during a discovery process, you generate new insights and learning which will lead you to update your priority score. You will gain more or less confidence about its impact and certainly a better understanding of the complexity. Hence, keep reevaluating your priority decisions as you go.

4. This is how to get started and scale

You can follow these steps to get started:

1. Set up the Kanban board.
2. Fill the board with topics that are currently in Discovery and Delivery.
3. Fill the [New] column with topics from “idea lists”, with “feature tickets” from your development backlog, input form customer feedback forms etc. You can add further research and stakeholder input on an ongoing basis.
4. Do an initial assessment and clear the first two columns. This may be hard at first, but is the key to make this entire approach work.
5. Introduce your team and key stakeholders to the roadmapping approach. Call it“an experiment” if they are skeptical. Invite them to add opportunities right away to get their buy-in.
6. Arrange a first alignment session. It’s OK if this takes a couple of hours for the first run.
7. Schedule the recurring routines.
8. Share the approach with all relevant stakeholders. Consider using a video format (e.g. Loom) where you explain the concept and let everyone know how to participate. From my experience, this format is well accepted and can further serve as reference/documentation for future hires.
9. Schedule a short retrospective 4–6 weeks after the first alignment meeting and introduce changes to the approach to adjust it to your needs.

Here are a few more things to consider when you plan to introduce the approach:

Use a simple Kanban tool that your company uses for other purposes too.
I have tried all the fancy product roadmapping tools. Most of them are great products, but I have not been successful in establishing them across the whole company in a practical way. To create maximum transparency, and collaborative interaction around the roadmap, use whatever Kanban tool you use for project and/or to-do management. I have seen companies successfully establishing such roadmap pipelines in Trello, Asana, Jira, Notion, and other similar tools. At Circ we used Asana for general project management and Jira to manage the detailed development workflow. We created the roadmap pipeline in Asana because it was the most accessible solution for the majority of people in the company. One of my clients established it in Jira, as +70% of their employees were tech people. You can use tools like Unito.io or Zapier to connect different tools. But remember, the number one goal is adoption. It is better for you to establish a continuous roadmapping approach in a basic tool, than having a fancy product tool that no one looks at.

Don’t mix the roadmap and development backlog.
Your engineering backlog should not be your roadmap and the place to prioritize ideas. I frequently see Jira backlogs full of empty tickets that are simple feature ideas PMs want to store somewhere. This makes your backlog messy and much harder to manage and understand. Your backlog should consist of user stories, bugs, and special tasks that don’t connect to a story. They are either ready for development or will soon be taken into a grooming discussion. Your roadmap pipeline, on the other hand, should give you a higher level overview and help you to decide which opportunities to prioritize to achieve your objectives.

Be aware of the mindset challenge: balancing predictability versus adaptability.
Everyone wants predictability: executives, investors, marketing teams, your squad. This is why you see so many huge Gantt charts full of features. They create a promise of predictability. However, you cannot expect predictability in an environment with high uncertainty and continuous, fast change. What is true today, might be outdated tomorrow. This leads to a lot of frustration, loss of trust and the perception of bad product management. The need for predictability comes from times when large and successful companies didn’t depend on creative output (such as factories). For companies with predominantly creative output, adaptability is more important than predictability, though. It is essential to understand the constant tension between the two needs, so you can actively manage expectations. The most essential change to manage this tension is to make your objectives outcome focused instead of output focused.

Outcome over output objectives
Let’s look into some examples to understand the difference:

It is much harder to predict which outputs (i.e.,features) to prioritize for next quarter than which outcomes (i.e. metrics) to focus on. For example, you define the objective to release a new tutorial for your product and start working on it two weeks later. One week in, you realize that a tutorial is actually not the best idea. You learned that you should rather improve the empty state of your dashboard, so new users can take their first action right away. Your initial objective (release a tutorial) is outdated. It would have been better to define an objective around the activation rate. For example, % of users who take the first core action within 3 days after sign-up. It is more likely this objective will remain important over the whole quarter, while the way how you achieve this objective (output) stays more flexible. With this change, a company can empower product managers to take more ownership over the roadmap and connect it directly with their objectives.

Less experienced PMs should team up with leaders.
I don’t expect early and mid-level PMs to set up and run a good continuous roadmapping process. However, if you want to get it implemented in your company, and you don’t have years of experience in product or as a manager, get started like this.

1. Introduce your leader (co-founder, CEO, product lead) to this concept of continuous roadmapping.
2. Do the initial assessment (triage) on a weekly basis together with them. You can take care of the operational work involved: keeping the roadmap pipeline clean, scheduling the sessions, replying to comments, preparing and summarizing the alignment meetings.
3. Challenge your leader, but let them make the final calls, and let them run the alignment meeting until you feel ready to take over.

When you scale the approach across many teams, decentralize it.
One central roadmap across a larger number of teams is complex to manage, makes it difficult for others to contribute, and it may make you slower. Consider having one roadmap pipeline per group (tribe) of teams. At Circ, we had 3 tribes. One focused on all consumer and external efforts. One focused on operations tools and one focused on the “platform”, enabling the work of the other two tribes. So, we had 3 roadmap pipelines and different stakeholder and customer groups interacting with it. Once a quarter we were reassessing how many resources a group needs to deliver on their objectives and how much risk we are willing to take.

5. Other forms of roadmaps

The roadmap pipeline is my day-to-day approach to handle roadmapping. Roadmaps are mostly alignment and communication tools. You will also need other representations of the roadmap. For example, when you introduce new members to the company strategy or when you talk to investors, presenting the roadmap pipeline is a level too deep.

Strategic roadmap: A summary slide to tell the overall story.
This is an example where I grouped the swimlanes based on our strategic segments and outlined key initiatives. Focus on the most important topics and don’t get lost in details. I update this slide once a month.

You can use the same approach to focus the strategic roadmap on telling the story which objectives are most important in a give quarter. In this case, the roadmap would be entirely outcome focused.

Gantt charts for planning very complex projects.
First, try to avoid very complex projects altogether. Break things down and deliver small increments. On some occasions, however, they can be unavoidable, especially to manage dependencies. For example, the migration of the banking system at N26 or the migration of the entire system at Circ. In such cases, I use simple Gantt charts to visualize high-level dependencies and communicate timeline expectations to stakeholders. One problem with such delivery dates is that people might interpret concrete dates as commitments. This can lead to a shift of the focus from satisfying customer needs to deliver outputs. Thus, I am extra careful with concrete time commitments.

Never forget a disclaimer.
To manage expectations and highlight the true challenge of a roadmap, add a short disclaimer. It can be something like “This is our best guess from [Date]. We prioritize flexibility over predictability, so don’t read it as a delivery commitment.”

To summarize, the key takeaways:

• Establish a triage process to do an initial opportunity assessment and prioritization on a weekly basis.
• Introduce a regular roadmap alignment session to leverage collective intelligence and have your key stakeholders on board.
• Use a simple prioritization framework to make your priority decision more transparent.
• Prioritize adaptability over predictability.
• Make roadmapping continuous, not quarterly.
• Connect every opportunity on the roadmap to the company / department / team objectives.
• Understand and implement outcome focused objectives.
• Keep the development backlog and roadmap separate.
• Leverage whatever Kanban tool is most accepted in your company.
• Split your roadmaps as you build out dedicated teams/tribes.
• Never forget to put a disclaimer on your roadmap.

It is better to get started than trying to be perfect. It will work, as long as you take a step back every few weeks, reflect on your approach and improve it over time. These are my learning based on 7+ years of mistakes on roadmapping. I hope this article is able to accelerate your roadmapping learning journey. Please share your questions and experiences in the comments below.

Additional Reading Material*

• If you want to better understand how Vision, Strategy, Objectives and Epics connect, check out this video by one of the product thought leaders
• Ruthless prioritization. This was one of the most influencing articles on my thinking around priorities
• This article gives an overview on 20 different prioritization techniques
• Another great approach how to use ICE and particularly how to think about confidence
• Dave’s article on strategy and roadmapping are also great approaches to think about the topic and widen your horizon.
• Great inspiration for defining or challenging your north star metric
• If you struggle with OKRs, this talk gets it to the point, very valuable advice.
• If you want to level up your Output vs. Outcome understanding, start with this video and read this short book
• One of the best talks on roadmaping
• This article shaped my opinion and thinking on how to deal with deadlines.
• If you don’t have a product strategy, the roadmap won’t be effective. Marty Cagan gets this to the point really well in this article.
• Marty Cagan on opportunity assessment
• If you want to learn more about the tension between predictability and adaptability check out this video

*Book recommendations contain Amazon affiliate links

In my last seven years in product management I have worked with over 100 product managers. Most of them didn’t have a clue what was expected of their role. And I’m not just talking about the interns.

When a product manager asked me why I was not a senior PM, but my colleague was, I wasn’t able to provide a clear answer. That interaction led me to create the first PM skill matrix. For the last five years I’ve used the matrix as a performance and development tool for PMs in my teams as well as a tool for coaching clients. Now I want to share the matrix with you to help you improve your PM recruiting, become a better leader and build a clear plan for your personal development.

The matrix is built upon the feedback of countless PMs and is constantly evolving. Your feedback is welcome and will help refine and evolve the matrix further.

The matrix consists of 26 relevant product manager skills and four levels of product management experience. In parts one and two of this article, I share some background on the skills and four levels. In part three, I elaborate on how you can use the matrix to be a better product leader. In part four, we look at how to use it for your personal development.

Here you can find the PM Skill Matrix in the form of a presentation and here in the form of a sheet.

1) 26 Skills to be mastered

The skills are organized into three groups:

1. Product knowledge: Understanding the product, industry, business and customer base you are dealing with.
2. People skills: Successfully working with stakeholders and teams, and being a strong leader.
3. Process skills: Covering all techniques required to build successful products.

Some skills are broken down into sub-skills to provide a more comprehensive base to assess these skills. I don’t explain each individual skill in this article as you can find the explanations in the matrix itself.

Most of the skills apply to all PMs
Some skills might not be applicable for highly specialized PMs. For example, if you are managing an internal product or technology platform, creating and working with personas might not be as important for you. However, you can apply all skills even as a technical platform PM or as a PM enabling internal customer care or operations team.

You won’t ever master all the skills
The product manager job is very challenging and broad in the skills required. Thus, I expect every PM to have a solid foundation in most product skills and a specialization in one or two fields. I have worked with PMs that are exceptional in UX and research. PMs that have an incredible understanding of the technology platform and the dependencies of all services. PMs that understand the business model down into the last detail. A strong PM team has diverse specializations. For a company’s first three PM hires, I most often recommend to focus on strong generalists with a business background. PMs with specialist skills are more appropriate as a fourth or fifth hire in a team. For you, as a product manager, this means you want to build a T shaped profile. You should aim to meet the general expectations for all skills listed on the matrix, and outperform at some of them.

You can apply the same framework for both B2B and B2C
There are obvious differences in the experimentation and research methods, the KPIs you track, and distribution channels you will deal with. Nonetheless, the core product mindset and principles, as well as the skills required, stay the same.

PMs have to build a toolbox of problem-solving methods
Some PMs ask me why A/B testing is not part of the matrix. However, A/B testing is only one of many experimentation methods. I wouldn’t want to highlight a single technique as they evolve and are specific to the industry, product and user. See the book recommendations in the appendix if you want to learn more about experimentation methods.

2) Four Levels of Experience

In addition to the 26 skills, the matrix is split into four levels. Each of these builds on the level before it. For example, under “Communication Skills” on level two you will find a subpoint which is also true for level three and four. The four levels are:

• Associate PM
• PM
• PM Leader
• PM Executive

Associate PMs (APM) are new to the role of PM
APMs have either previously done some internships in product management or bring relevant experience in a related field. Someone might be an APM for six to 24 months before making the step to become a product manager. However, in most companies this title doesn’t (yet) exist, and most people are given the title “product manager” right away. You might want to consider yourself an APM depending on your experience.

“Product Manager” can mean different things to different companies
Most product readers will find themselves in the “product manager” level. When looking at the matrix, you need to look beyond your job title, though. Just as many APMs have the title “PM”, so too do many senior PMs. This is oftentimes due to the fact that they are in organizations with a low range of different titles. Google and Facebook are excellent examples for this. Comparing a “Senior PM” at Spotify with senior PMs in most early-stage startups is also a stretch, as startups tend to have different expectations and try to be attractive in a war of talent. Furthermore, you have executives who are inexperienced in managing “product managers”. This matrix should help to identify gaps between expectations and reality. It is based upon the expectation I had when leading product management teams between one and 15 PMs.

“PM Leaders” are skilled in leading less experienced PMs
They are not only excellent in building products and solving problems, but take official leadership responsibility to make other product managers grow and become successful. Your title might be Senior, Group or Lead PM, or even (early) Director.

With an increasing focus on creating attractive individual contributor career tracks, job titles such as “Principal PM” are becoming more popular and important. These PMs have invaluable product experience and an incredible passion for solving problems, but they might not want to manage people. Nonetheless, the vast majority of skills on level three and four do also match individual contributor career tracks.

Heads, VPs or CPOs might want to look at the “PM Executives” first
This matrix will not only help to understand your gaps, but also allow you to find opportunities within your team and support in recruitment, development and performance management.

I don’t believe in a product manager, product owner split
Product managers should own the product process end to end. They are responsible for a given domain or scope and need to be capable of empowering their team to deliver outcomes. Product owner and project manager are both roles that the product manager plays. With more senior product roles, your responsibilities become more managerial and you can become a leader of product managers or manage a portfolio of products rather than owning a part of a product. However, end to end ownership is key to create real accountability, ownership, attention to result and empowerment.

3) How to use the matrix as a leader

If you are the leader of one or more product managers or aim to become one, feel free to make this framework your own. Experiment with it and adapt it to your organization and experience. You can use it to increase the quality of building and leading product in your company. I suggest you actively involve your team when you want to introduce this framework. Start by studying it yourself, and reach out to me with any questions you may have. Once you’re comfortable with it, share it with your team and organize a workshop to cover the following:

1. Discuss each skill (not necessarily each level of each skill). Make sure you have a shared understanding of what each skill means.
2. Align on whether you want to make adjustments to the matrix according to your company and circumstances.
3. You may want to do an assessment of the product team as a whole before using it in 1o1s for individual gap analysis. You could do a dot voting on each skill to rate the overall product team performance and discuss what to improve and what to keep, when you grow the team further.

Use the matrix to professionalize your PM recruiting
There are multiple ways you can use the skill matrix for recruiting:

1. When deciding to hire additional product managers for your team, you can identify skills where your current team has substantial gaps. Additional hires can help you to close gaps and bring additional skill diversity.
2. Use the matrix when creating a job description to make sure that the most important skills are covered appropriately.
3. When you start hiring, you can align the hiring process with the skill matrix. Define which team member focuses on what area of skills and how these skills are being assessed and scored.

A framework for coaching, career development and performance management. To make the skill matrix work as a leadership tool, follow these steps:

1. Discuss the process with your trainee. Make sure they understand the matrix and the steps of this process. Agree on one of the four levels which should be the main focus in the assessment. Where someone is exceeding expectations of a particular level, you might want to look at the skills on the next level. Where someone is below expectations, you might want to check how they are doing on the skills of a level lower.
2. You (the leader) and your trainee should separately assess the trainer on each skill on the level you agreed to. I recommend to make two copies of the sheet and use the following color system:

• Not applicable / Not expected / Can’t be scored (grey)
• Expectations not met (red)
• Below expectations (yellow)
• At expectations (blue)
• Above expectations (green)

Your sheet might look like this when you have assessed a product manager:

Using expectations as a means of scoring makes clear that there won’t ever be an entirely objective opinion on the scoring. It should be according to the expectations of the company for the given role. This will be judged by the leader. Thus, it is the leaders’ responsibility to collect feedback on the skills from different people and perspectives. They can be peers, stakeholders, team members, customers or partners. It can also be connected to any exciting 360° feedback process. Additionally, I encourage the trainee to collect feedback from a few people before they do their self-assessment. This expands their ability to self-reflect whilst, making them more open to listen to feedback in general.

3. Schedule a one-hour session to talk about the results.

• I ask the trainee to start by guiding me through the self-assessment. Next, I show them my assessment and highlight points where I have a different opinion or emphasize some points they have made with additional examples.
• Align on the expectation gaps to create a better shared understanding of the skills and expectations.
• Define one to three key development areas (skills) together. Make sure to prioritize them and make them goals for the next few months. Explain to your trainee how a great outcome of these skills looks like. Only if someone understands what it means to meet or even exceed expectations in e.g. “Problem Research & Definition”, will they be able to get there.
• Talk about concrete ideas how the person can improve on the agreed priority skills and how you can help them to accelerate. Identify opportunities to practice the skills, identify helpful books, articles and courses. Consider external coaches, internal knowledge sharing or peer shadowing.
• To finish the session, I ask the trainee to summarize the key points and either send it to me via email or put it in a given tool. By this, you make sure that you are both on the same page.

4. Check-ins during your 1o1s are important to understand:

• What is holding your trainee back
• How you can help
• What they have already achieved

5. I recommend having a more formal check-in on the goals after three to six months. Determine which skills still need some work. Identify new areas of growth and talk about career development. You might want to do a full reassessment of the matrix once or twice a year.

4) How to use it for personal development

I had an enlightening experience when I joined a company as an interim lead a few years ago. I went through the process described in “How to use it as a leader” with all PMs. During the one-hour session one of the PMs said, “I actually think I’m not a PM, but rather an associate PM, and I’m probably even overpaid”. I was speechless for a moment. First, because that type of openness requires a strong personality. Second, because I realized how well-suited this framework is to self-diagnosis. And yes, the PM was right. They were in fact rather an associate PM at that point. However, this realization helped them to understand how to accelerate their growth trajectory and actually become a great PM, rather than struggling to understand why things were not working out.

In the best case, you have a great leader who coaches you through the process described in the previous chapter. However, if you don’t, and want to use the skill matrix on your own, I recommend the following steps:

1. Start by understanding the expectations of your role.
Find the appropriate level to start with and go through the matrix skill by skill.

2. Understand where you are.
Use the same coloring scheme as described in the chapter before to score yourself on each skill. I recommend you gather input from peers, customers, your team members and your leaders. This will help you calibrate and get a good understanding of your status quo. For some skills, it can be apparent where you under or over-perform. For other skills it can be harder to judge as your limitations of experience will probably define your horizon. For instance you may think you are excellent in “Writing, slicing & prioritizing stories”. However, as you have never worked with someone who is truly excellent at this, you don’t know what excellence looks like. Thus, collecting input from others is inevitable. In addition, you can get a copy of the book “FYI” (linked below). This book describes 167 skills on 450+ pages. For example, it describes to the point and with examples what skilled and unskilled“Priority Setting” looks like. I might extend the matrix further at some point to have an explanation for expectations of each skill on every level.

3. Identify your priorities.
After the self-assessment in step (2), define one to three skills you want to focus on in the coming weeks and months. Try to understand what skills would be most important to improve, so you can succeed and grow in your current role. However, don’t miss the long-term perspective. Depending on your longer-term goals, you might want to prioritize slightly differently. If you want to become an entrepreneur and start a business yourself, you might want to prioritize different skills than if you want to become a leader of a larger product organization or a master product builder within a company.

4. Create an action plan.
There are many ways to improve skills, and it is mostly a combination of different approaches that lead to true mastery. From my experience though, the most important principle is “What you have learned, but didn’t do, you haven’t learned”. Thus, only reading about things or attending a course won’t make you any better. The most important step in learning is practice. Finally, to truly master a skill, you need to teach it to others. When your students succeed at becoming great at the skill you are teaching, then you know that you have achieved mastery. In light of this, when you create your plan, try to follow these mental steps:

• Where can I start practicing this skill more?
• Who can help me reflect on my performance?
• What content can I consume to gain new insights?
• How can I teach others what I have learned?
• How can I understand whether others have been benefiting from what I taught them?

5. Reflect, reflect, reflect.
To accelerate learning, combine consistent practice with regular feedback and reflection (supported by reading and coaching). The more regularly you reflect on the steps you take, the faster you will grow. From time to time, come back to the matrix and reflect on the full picture of the PM role. Take a look at the description on certain skills on the next level and identify new growth areas and repeat step 4.

Contribute to better leadership

My product management skill matrix is a living organism and will continue to evolve. I’d love to hear your feedback on how the matrix could be developed further. Also, feel free to share it with your colleagues in design, engineering, research and beyond. I believe such a matrix is an invaluable tool for leadership and growth, and hope that the product management skill matrix can serve as an inspiration.

Reading recommendations and sources:

• An interesting article on different types of PMs including a pre-assessment.
• A must-have book for leaders. Hundreds of general skills described in a way that you can really judge whether someone is good or not at something like communication or prioritization.
• Great article on how PMs evolve from Junior to Executive.
• Product Manager vs. Product Owner. This article brings it to the point.

Articles that have been a strong inspiration for my skill matrix:

• https://medium.com/agileinsider/product-manager-skills-by-seniority-level-a-deep-breakdown-cd0690f76d10
• https://medium.com/forto-tech-blog/the-product-management-skill-book-fefdf118270
• https://svpg.com/coaching-tools-the-assessment/
• https://www.ravi-mehta.com/product-manager-roles/
• https://levelup.mindtheproduct.com/courses/assessing-product-skills

Markus PM Skill Matrix:

• Skill Matrix in the form of a presentation
• Skill Matrix in the form of a sheet

A turning point for me was my flight to Singapore in 2013. I left behind my 3 co-founders with our restaurant business, which was facing many challenges at the time, to enjoy a five-month exchange semester. During this flight, I read the book The Big Five for Life. One thought experiment in this book got me hooked. What if at the end of our life, a museum would be built, in which everyone could see pictures, notes, quotes, and video-clips of the things we did in life. Every visitor would see us the way we were. Not how we wanted to be, not our excuses why we couldn’t make something happen, but how we actually were. How would you feel going through it after you die? Ask yourself every day: “Was today a good museum day or a bad one?”

During this exchange semester, I started my journey of continuous self-reflection. And ever since, I have been experimenting with frameworks and iterating on reflection cycles. I wrote this article to share what I learned. I started reading about self-growth, psychology, the purpose of life, and the like. You can find a list of some of my favorite books at the end of this article.

Begin with the end in mind

“If one does not know to which port one is sailing, no wind is favorable.” Lucius Annaeus Seneca

In life, we often get bogged down by small things or other people and, as a consequence, struggle to feel a sense of fulfillment. Or we might be on autopilot, unquestioningly following preset paths and not even realize that life is passing us by. Until, maybe, one day we wake up realizing that we are not living the life we actually wanted.

There are different philosophies of what one needs to be fulfilled in life. I believe it is essential to have (1) a target personal identity as well as (2) a purpose in life. To make my purpose more tangible, I break it down into (3) 5 life-goals. These three elements guide me whenever I have to make a difficult decision. They help me to prioritize my day and limit feelings of envy, and rather let me experience satisfaction, thankfulness, and fulfillment.

The focus of this article should be self-reflection loops rather than going deep into the topics of identity and purpose. Hence, the following few paragraphs are only a short introduction to the topic.

Start by defining your target identity and a clear purpose.

1. Take a moment and try to imagine your funeral. What would you want your family and partner to say about you? What would you want your best friends to say about you? What would you want your colleagues and communities say about you? This should be the core of your target identity.
2. Next, think about “What can I offer to the world?” What are rare and valuable skills you have or want to build? When we master a skill, it will become our passion. Finding one’s passion without investing time to become good at it is a myth. So think about “What process of learning a skill would I enjoy?” These thoughts will be the foundation for your purpose, the purpose that you are on planet Earth for.
3. Now you can derive 3–5 concrete goals related to your purpose and identity. Think about different areas in life such as your relationships, profession, hobbies, and places you would like to spend time at, the impact you want to create, and most important, your health.

Taking the first steps is hard and talking about it can seem abstract and hard to follow. So I will provide my examples to help you get started.

This is my purpose, my big 5 goals and my target identity as of the beginning of January 2020:

Continuous course corrections to stay on track

Your purpose and target identity are neither ever done nor ever fully accomplished.

Their job is to provide you with guidance to stay connected with the things that motivate you. The 5 concrete goals are linked to both your purpose and target identity and should give you clarity and motivation to get going. Without defining your goals, you might not know where to get started and how to bring your purpose into action. Pay attention that your goals are connected to your purpose and underlying identity, since fulfillment comes from becoming that person capable of achieving those goals not necessarily from achieving the goal.

As we progress through life and deal with our day-to-day challenges, we easily get off-track from our long-term ambition. This is normal and okay. And this is the reason why you need to continuously reflect and take a moment to check:

1. Where am I right now?
2. What happened in the previous period?
3. What was good/bad?
4. What did I learn?
5. What do I want to change to get back on track?

Just like there is no right zoom level to look at the map of the world, there is not a single routine that helps you to reflect on everything. Sometimes you want to zoom out to see the bigger picture and reflect about it. Sometimes you want to go into the details of a conflict you have and understand why it is happening.

This is why I built the following routines over the last few years. I started by only doing an annual reflection. At some point, I introduced the quarterly session. I struggled for a long time to find habits for a weekly and daily rhythm that would persist. You need to find the right setup for yourself. I will guide you through my setup to give you some inspiration. Don’t over-engineer it. It is better to get started and improve as you go, rather than never getting started because you are aiming for perfection from the start. I follow my routines 95% of the time. I never skip on the annual or quarterly loop. However, on some days, I just miss doing my daily reflection in the morning or evening. And during vacation, I sometimes leave my self-reflection book at home intentionally.

To help me to reflect on the progress toward my goals, I follow four loops of reflection:

1st Loop: The Annual Cycle

Refine your bigger picture

I block a few hours at the beginning of a new year. First, I review my target identity, my life purpose, and the big 5 goals. Do they still feel right? Do I use them to make key decisions and to prioritize the way I spend my time?

Be open-minded to challenge and adjust your goals when your priorities or circumstances change.

I make a few changes to my goals almost every year. For example, for three years, one of my five goals was to travel to 100 countries and make one friend in each country. After having had this goal for three years, I noticed that I wasn’t working toward reaching this goal and started questioning it. I realized that it actually doesn’t matter to me to how many countries I travel and whether I make a friend there or not. I enjoyed traveling, but rather to regenerate, spend a good time with family or friends, or gain inspiration. Thus, I dropped the goal entirely and replaced it with a different one.

Create a list of annual objectives

As a second step, I define 2–5 concrete objectives for each of the following areas in my life: (1) Relationships, (2) Energy, (3) Passion, (4) Profession, and (5) Personal Growth. Using such categories will help you to come up with objectives more easily. Creating a list of objectives matters more than what categorization system you use. The objectives can be: “One-time” activities like organizing a trip with my family; Recurring activities such as doing an improvisation theater course; Continuous tracking of a metric, for example setting a sleep score goal by tracking my sleep with the Oura ring. And most importantly, I try to build or change one to two new habits every year, for example exercising regularly, drinking less alcohol, eating less meat, or meditating daily. To build lasting habits, I define rules and systems for each of them. I will elaborate later how I track the progress of my habits. Understanding the impact of habits and how to deal with them is a key skill. You can find a recommendation for my favorite habit-building-books at the end of this article.

Once you have a list of annual objectives, double check them against your target identity, purpose, and life goals. Sleep over it for a few nights and review them. Talk to your partner, family, or a few close friends and let them challenge you on why you have chosen these objectives. These objectives should be inspired from your inner desires, from your purpose and identity, not from the expectations of your parents or the public image you want to create, but actually don’t care about. Other people can help you challenge that. Make your adjustments based on these inputs and your thoughts.

For example, these were my 18 annual objectives for 2019. I accomplished 10 of them, 2 not at all, and all others to an okay or good extent but not entirely

2nd Loop: The Quarterly Cycle

Check the status of your annual objectives

At the end of each quarter, I block two hours to reflect on the past three months. These should be two hours of full focus. If you are too busy, postpone the session by a few days rather than rushing through not being fully focused. I have a recurring blocker in my calendar for the first weekend of a new quarter. First, I go through the list of my annual objectives and mark them accordingly:

• “Done”
• “On track”
• “I need to keep an eye on”
• “Not started”
• “Changed” / “New”

This is an example of my Q3/2019 review of my annual objectives.

Adaptability over being dogmatic on initial commitments

If something significantly changes that makes an objective unrealistic or deserves a specific objective, then I adapt. In 2019, I didn’t have a lot of such changes. While in the first quarter of 2020, we learned that we are becoming parents, which was not reflected in my yearly objectives. So I added a new objective around making support for my wife the top priority. COVID-19 also affected some objectives, such as travel plans and my plan to join an improvisation theater course. This is why these quarterly reviews are so valuable. They help you to course-correct during the year.

Review the previous quarter

Besides the check-in on the annual objectives, I answer the following 7 questions to do a proper review of this quarter. This is the most exciting exercise every quarter. There is no dedicated order for checking in on the annual objectives and answering the 7 questions. I start with either of them and jump back and forth until I am done because the insights from both are somewhat dependent.

1. Things I did this quarter?
   You list everything worth mentioning in a short list of bullet points. Books you finished reading. “First-time experiences”. Special events at work. Trips you took… I do this by going through my calendar to gather input. Usually, I am surprised how much happened in only one quarter. Things move so fast, that we tend to forget.
2. Highlight of the quarter?
   To be precise, you list 3 highlights:
   (1) The “Me” highlight, which is about your personal growth, health, or about one of your passions.
   (2) The “Relationship” highlight, which is something that happened relating to your family, partner, or friend.
   (3) The “Work” highlight, which is about something related to success in your profession
3. Low Light of the quarter?
   You use the same three categories mentioned in question 2. The low light usually is something that didn’t go as expected or planned, something related to negative emotions and with potential for improvement.
4. New learning of the quarter?
   This can be a skill, an experience that taught you an important lesson or an insight derived from a book, conversation, or similar. Something you didn’t know before this quarter and you are glad you know now.
5. Most interesting new person of the quarter?
   We meet so many people these days and oftentimes struggle to stay in contact. Think for a moment who is someone you got to know, whom you want to stay in contact with and possibly deepen the relationship with.
6. What am I thankful for?
   I answer this question every day. However, once a quarter, we should reconsider and see the bigger picture to not forget all the great things we are thankful for.
7. What do I want to do better next quarter?
   First check the answer to this question from last quarter to see whether you actually improved on the things that you planned. Then you define a few things you want to improve on. In my case, they are oftentimes related to my annual objectives.

Here is an example of my quarterly review of Q2/2020.

Connect annual objectives with your private “To-Do” backlog

Oftentimes, we end up reacting to things that are urgent and tend to skip things that are important but not yet urgent, such as health, family, or reading. To connect my annual objectives with my daily doing, I create concrete actions for most of the objectives and put them in the backlog of my private Could-Do list. More on this later.

3rd Loop: The Weekly Cycle

A week is the perfect period for planning and reflection

When daily planning, it is often hard to balance all the things that are important to you in life. You will have days loaded with work and days focused on private matters. Yet, within a week, you can balance well between time for you, your relationships, and your professional ambitions. There are exceptions such as vacation, but for most of the year, you can build and stick to well-balanced weekly routines.

I struggled for years building a lasting weekly reflection routine

I blocked an hour every Friday for self-reflection. I tried a Monday morning routine and some other formats. At the end, I didn’t follow through on any of them more than a few times. One day, a friend recommended the 6-minutes-diary, which was a game changer for my daily and weekly reflection routine.

The 6-minutes-diary was my game changer

For about one year, I have been using the book 9 out of 10 days. I have been successful most likely because it is a physical book always next to my bed that reminds me to act. The first version of the book comes with a weekly reflection based on five questions that go very deep and a section for some weekly notes. The second version has a much more structured section for a weekly reflection. On one page, you note down:

1. 1–3 successes in your week
2. on a scale of 1–10, how happy you have been this week and why
3. what you have learned this week
4. a few things you want to do in the coming week related to your private and work matters
5. 1–3 things you are looking forward to.

Here is an example page from the book with my answers for the weekly reflection from 3rd week of August 2020.

This takes me 10 to 15 minutes every Sunday evening or Monday morning. In addition, you have a section to track 3 habits every week. This helps me to better keep track of habits I want to change. Mobile apps didn’t work for me to track my habits.

Make time for important things — I know, it is so hard….

The second thing I do on a weekly basis is a short update of my private Could-Do list. I pull all items from my “Sometime” section — which is my private backlog — into the section “Next priorities.” Then I prioritize the items in “Next priorities” and block some time in my calendar for important items from this list that have a good chance of falling through. I consider the Could-Do list rather a “Want- or Can-Do List” that provides me peace of mind and helps me to keep an overview.

4th Loop: The Daily Cycle

As with the weekly routine, I struggled to establish a daily routine of reflection, planning, and thinking. The 6-minutes diary did help me to establish a 3 minutes morning and evening routine. I answer 3 questions every morning and 3 before going to bed.

Morning

1. What am I thankful for….
2. What would make today a great day?
3. Positive self-affirmation

Evening

1. What positive thing did I do to someone today?
2. What will I improve on tomorrow?
3. Great things I have experienced today…

Every day, I answer the same questions. They help me to appreciate the little things in life and keep my positive mindset. They support me in developing new habits and pay more attention doing good to others.

The following page, I fill out every day. This example is from 23rd of August 2020.

You don’t need to buy the book to build great feedback cycles. You need to find the approach that works for you on a continuous basis. For me, it was a breakthrough in my personal growth.

Career-based reflection

Two more things you should consider if you want to take personal growth and self-reflection seriously.

Do a structured reflection every time you switch your job (or role)

Over the course of more than 400 job interviews, I talked to many people who have been unhappy or “unlucky” with their jobs multiple times. There can be many reasons for this, but the core should be a solid reflection every time a major chapter in your life ends so you can avoid making the same mistakes again.

At the age of 18 when I finished one of my first major projects, I introduced this simple reflection framework. Ever since, I answer these 6 questions at the end of a major professional period. 1 to 1.5 pages are sufficient. I have always done it when I switched to another company, closed, or sold a company.

1. What was my initial objective with this project or company? Did I achieve it?
2. How did I develop my knowledge, social and financial capital?
3. How did I collaborate with others (my team, stakeholders, peers)?
4. What am I proud of?
5. What mistakes did I make?
6. What will I do differently going forward?

Every time I add such a reflection, it is great to scroll down and read these short reports about previous experiences and spend some time thinking about them.

You can also write down what you think will happen in 18 months’ time whenever you start something new. Comparing that with what then actually happens is a powerful tool to understand yourself better.

Use my template and get started today!

“I find it fascinating that most people plan their vacations with better care than they plan their lives. Perhaps that is because escape is easier than change.” Jim Rohn

Yes, it can be overwhelming and difficult at first. It is most important to get started somewhere. You can use my template and checklist to get started with defining your target identity, purpose, goals, and annual objectives. Schedule two hours every quarter for your review. Try out the 6-minutes diary or any similar books. Get an Audible, Blinkist or any similar subscriptions to start building a reading habit. Find a list of recommended books below. Follow these steps and observe your transformation. Not having time can’t be an excuse. Following the 4 reflection-loops takes 3 hours a year, 2 hours per quarter, 30 minutes a week, and 6 minutes a day. I am excited to hear about your experiences and stories.

Books & Links*

• A template and checklist to help you create your self-reflection loops
• My inspiration to get all this started — Big 5 for Life
• Best book about habit building — Atomic Habits
• Best book about core principles of life — must read for everyone — 7 Habits of Highly Effective People
• Inspiring book about living a more health life — Super Human
• Me learning about some basics on psychology Selbststeuerung
• Inspiring book to understand what makes people who live a “original” life Originals
• Challenged my perspective on “you have to find your passion” — So Good They Can’t Ignore You
• The title says everything: The Subtle Art of Not Giving a Fuck
• A book full of wisdom on how to live a more principle centered life Principles
• An amazing YouTube channel that helps me creating my book summaries

Some Articles:

• A challenge many of us struggle with in an overload of information we are facing — Stop Consuming. Start Creating.
• The reason I started having a 15–30 second cold shower every morning — Willpower
• The first time I started reading about Mental Models

Other:

• Awesome for sleep tracking Oura Ring
• I use Asana for my CouldDoList. There are many great / better to-do list tools out there; take whatever you are most familiar with. It is not about the tool, rather about the habits you establish.

*Book recommendations contain Amazon affiliate links

Digital product managers play a key role in any modern company. Despite their importance, there are hardly any straightforward ways to become one. During my career, I have supported dozens of product managers (PMs) in making their move to product management and progressing in their careers. In this process, I have done more than 300 job interviews with (future) PMs. Based on my six years as a digital product manager, I have identified three dominant paths to become a PM: joining as an associate PM, making an internal transition, and joining an early-stage startup.

Here is a short comparison of the three paths:

#1: Joining as an associate product manager

One common way to become a product manager is to join a company that has a dedicated associate product manager (APM) program or is open to hiring associates in a product role.

I have rarely seen early-stage companies hire APMs.
In the first three years at N26 we didn’t explicitly hire APMs but rather transitioned the strongest product management interns into a full-time role. At Circ, we hired one associate, but it was rather an opportunistic than a strategic choice because he had an exceptional profile. I advised one of our PM interns at N26, to whom we couldn’t make an offer to, to follow the APM track at a large, mature product organization, which he did. He became a great product leader in one of the cutting-edge product organizations in Europe.

I have mostly seen grown-up startups with 20+ product managers hire PM associates. Many traditional companies tend to lack the understanding for modern software product management. Small companies or tech organizations, however, tend to miss the structures or leadership capacity for more than a few, if any, APMs. Their product managers often lack the time, structures, or experience for mentoring and coaching. For smaller and medium companies, every project can feel like a make-or-break project. Thus, they often struggle to hand over ownership to new joiners.

Larger product organizations, however, are more likely to have advanced career tracks and established processes for performance management, and knowledge exchange. These companies have more projects that are important, but not necessarily critical for the survival of the company. Such lower risk projects provide the opportunity to allow less experienced PMs take end-to-end ownership of a product.

Applying to a regular PM job can work out as well.
Search for companies with an advanced product organization. If they don’t have a job posting for an associate PM role, apply to a regular PM position and clearly state in your CV and interview that you are open to join as an associate. Don’t expect that anyone will read your cover letter, focus on your CV. During the application process, make it obvious why and how your previous background relates to product management. Also highlight which gaps you will need to close during your time as an APM.

Become familiar with the terminology, best practices, frameworks, and the modern mindset of product management.
Start as soon as possible to grow your product knowledge and don’t wait until you are hired. See a list of reading recommendations to get started with below. You will also need to work on your performance in interviews. Apply also to companies that are not on your short list to practice. Run trial interviews with friends and use online interview preparation to think through tricky questions. You need to become comfortable with the stress during interviews. PMs have to deal with a lot of unfamiliar, stressful, and uncomfortable situations, and need to stay calm and focused. If you can’t do this during the interview, most likely you will also not be able to do it during the day-to-day job.

Be prepared for a salary cut and boring projects to start with.
Entering into product management may start with a cut in salary if you had a more senior position in a different role before. Don’t let this discourage you. Understand the salary ranges for more senior product roles and the requirements for a promotion. Make your future salary expectations for more senior roles clear to avoid any surprise.

After you join a company, be ready to work on less exciting projects and don’t be picky. Take what you’re given. Crush them and repeat. This is the way to build trust and respect. You may only get one opportunity before people pass on you. Watch the offers for more interesting projects come in. In the end, how you do anything is how you do everything. If you follow this advice, you will end up having more and more options within the company.

It isn’t easy to find a company, but once you are in, you are all set.
In particular in Europe there are not many grown-up startups with product focus and an advanced product organization. Once you join a company, the APM path can be less stressful and still offer a good growth curve. You will receive more guidance, structured learning, and support from your peers. You need to rely a little less on self-learning. On the flip side, it can come along with a salary cut and can provide a slower learning curve due to the maturity of the company and organization.

#2: Making an internal transition.

In my last six years, I have seen many people transition to product management within the company when internal needs met personal skill. These colleagues transitioned from business development, marketing, customer service, operations, design, or engineering.

Valuable knowledge, relationships, and an urgent need can form an opportunity.
This path became obvious to me when we had a reorganization at N26 and dissolved the business development team. Some former business developers joined our product management team. They had been familiar with the company, the product, and the people as well, and had convinced us with their soft skills and ability to learn. Over the course of 3–12 months of coaching and support, they became fully fledged product managers, owning major products end to end.

Internal transitions to the product team can be significant opportunities for companies. First, because someone who works in a department that has regular touchpoints with the product team can build valuable internal knowledge and trust within the organization. Second, closing a gap can be urgent and it can save the company recruiting cost as well as valuable hiring and on-boarding time.

Apply for a role of your expertise and transition 3–12 months later.
Join in a role where you have significant experience and competence and set transitioning to product management as your mid-term goal. Pay attention to determine if this role has regular touch points with the product and technology team. For example, you might be an important day-to-day stakeholder for the product team as a business developer, a partnership manager, or a finance manager. Or you might join as a project partner to enable cross-department initiatives, such as end-to-end CRM, tracking implementations, or operations process optimization. Or you might be close to customers and as such an important source of feedback for the product team, for example as a 2nd or 3rd level customer service agent, a sales manager, or a key account manager.

Once you are in a role close to product, make sure you perform extremely well and build relationships across the company.
If you cannot perform or convince in your initial role, the company won’t be open for the transition. Thus, make performance a priority, and don’t see it only as something you have to do. Hence, do apply for a role in which you can actually deliver. Don’t shoot for more if you want to transition to product management.

Also, having strong internal relationships is key to become and succeed as a PM. Make building relationships with the product team a priority, especially if you end up not working as closely with the product team as you initially had hoped for. Meet product people over lunch and other events. Try to find ways to support the product organization and create value for them. This will require extra effort before and after working hours.

Keep your eyes open for upcoming opportunities.
There are two options here: Either a PM is leaving the company and creates a gap, or the company needs to hire more PMs. Approach your team lead and the product management lead with the desire to transition to a PM role. Explain to them how you can help to close the gap and how you will ensure that your current role won’t suffer. Be open to join as an associate PM or for a 3-month trial in this role. This reduces the leaders’ perception of risk by making it a softer commitment.

You should start to grow product management knowledge while you still work in your initial role. First by reading, but also by exchanging ideas with PMs of your company over lunch and by observing them in their job. For example, you can ask to join certain workshops, or scrum meetings as an observer. This will help you to build empathy and knowledge about product development.

If you make a transition, it will be a very intense time for you.
You will need to put extra effort into your job to ensure that you don’t leave a large gap in your previous role. Meanwhile, you need to get up to speed in the new role. Time-box some of your focus to build a continuous learning and reflection process. You can deliver additional value by creating empathy within your previous department towards product and vice-versa, for example, by explaining issues and improving communication between the two departments.

Don’t expect a salary cut, but a slower salary growth.
If you transition from a role you have been fully qualified for, companies aren’t likely to reduce your salary after this transition. However, your salary increase in the next 1–2 years might be slower than if you had stayed in your old role. This is because your PM experience matches the experience of an APM or a regular PM, while your current salary might be that of a senior PM. You first need to close the experience gap before you can expect your salary to grow again.

If the company does not grow the product department any time soon, no roles will be available.
Thus, make sure you join a company with clear growth ambitions and capabilities. If you make this path work, you will receive quite a lot of PM responsibility right away. Filling an important gap often means working on things that are essential for the company. Thus, this path to become a PM can be quite intense and stressful, in particular during the transition period.

#3: Joining early and taking the opportunity

In almost all early-stage companies, one of the co-founders takes the product management role, as the key challenge in that phase is to build a product that can reach product-market fit. However, founders will soon be immensely busy with many other things and need support around countless operational product topics. This can be your opportunity.

This is the path that worked for me.
During my early career, I designed and developed websites for several years, studied business, started my company (a restaurant with electronic menus) and built the operating software for it. Nonetheless, the path to becoming a product manager was not obvious to me. At that time, I was not even familiar with what it means to be a PM. It just sounded like the right job for me. Therefore, I decided to join N26 as an “entrepreneur in residence,” basically being an assistant to the founders. It was only a few weeks before the initial launch, when the CEO asked me to make sure we could launch the Android app in time. With this clear task, I was already heads-in into product management. I became connected to the product team and fell in love with the job. After an intensive two months, the head of product decided to leave and I got the chance to take over the lead in product management. With this internal transition, I ended up in a position with a steep learning curve. I needed to learn product management by heart, or drop out. Since then, I have worked for several companies, but I never have left product management again.

Find a promising early stage startup and build trust with the founders.
You have to approach it like an investor and figure out what chance this company has to become somewhat relevant. Look out for a startup with good funding, excellent founders, great product/market potential, a meaningful business model and strong investors. The main risk of this path is that the company might never grow out of the early stage of 5–20 employees. Then you will never end up doing a real product manager job. In fact, most companies get stuck in this stage and never find true product-market fit.

Convince the founders about yourself and join them as a founder assistant, entrepreneur in residence, project manager or anything similar. Build trust with the founders by executing in great quality whatever needs to be done. These can be boring tasks like finding a new phone provider, but remember - how you do anything, is how you do everything.

Offer your support to help with projects close to product and technology.
This will require significant extra effort, but early-stage startups are usually not a nine-to-five job anyway. You can support with setting customer feedback cycles before, around and after the launch of the product. Help the engineering team to solve upcoming problems such as: release management and coordination; quality assurance, in particular manual testing, bug reporting, and prioritization; support running scrum meetings as the team grows and needs more structure; document processes and product specifications; provide support in defining key business metrics and set up the data and tracking tools. You can also support the founders with gathering and writing specifications for upcoming features.

While you build trust with founders and work on different things to help the company grow, spend some time learning about product management, engineering, data, and design. Spend time reading, join meetups, and exchange ideas with the existing technology team to learn from them.

They will need a full-time PM to run the operational product management at some point.
The strategic aspects will stay with the founders for a while. You can use the opportunity to make the official transition and find an external mentor who can help you accelerate your growth. Further down the line, the company will need a product leader who will also take care of more strategic aspects, product team building and leadership. Depending on the company’s and your individual growth and previous experience, you can grow into this leadership role. It can also be meaningful to hire an experienced product leader from whom you can learn. In this case, it is most important to stay open-minded. It does not make sense to push yourself into the leader role when you are not ready for it. This will damage you and the company. Therefore, stay open to seek advice from experienced product leaders and founders at this point, and put your ego second.

Lower salary compensated with shares and learnings.
Depending on your previous experience, the position may come with a salary cut, as early-stage startups have lower base salaries. This can be compensated with share packages that can go beyond your imaginations. In addition, you will pick up valuable learning beyond product management, which will prepare you to become a successful founder one day. You will experience various challenges in all departments at the different growth stages of the company. Being a PM at this early stage means close interaction with the whole company. Hence, you will experience a steep learning curve.

Other Options: Relationships, Luck, and Internships.

Of course, there are more than three ways of becoming a PM and many combinations of them exist. Above, I described three options that can be used as a clear strategy and do not depend too much on luck or external factors. In real life, I have seen three other ways that worked for people. However, I would not bet on them, as they are less reliable.

Strong relationships with a product leader.
If you have been friends or colleagues with a product leader for many years, they might be a quick door opener into product management for you. Do not expect that a few meetings over lunch will do the job, though. In fact, I have done this a few times, but only with people who I already knew for several years. Thus, their soft skills, mindset, ability to learn, and relevant background knowledge were not in question for me. I decided to give it a try and opened the door into product management for them. In most cases, it worked out quite well. Yet, as a product leader, you can do this only for a small number of people. Otherwise, you will have a team of great people with little experience in product management.

Get hired as a regular PM right away.
There can be companies that offer you a PM position right away, even though you have no real product management experience. When this opportunity opens up, be cautious. The company might not understand what product management actually is and rather needs a project manager. In the worst case, you end up not doing product management at all. It can happen that you end up in a massive conflict with the company’s leaders. Or you adapt to a different role and don’t learn about real product management.

Internship in product management.
Product management internships are a promising path for people early in their career. This path is similar to path #3. I have seen many great PMs starting their career as a PM intern in a company, although mostly in early- to mid-stage startups. Companies can build product management talent and it involves little risk for them. They can get to know someone without having the obligation to offer them a full-time position in the end.

One path that definitely does not work is only to rely on certificates and formal education.
Of course, the more you know, the better, and these programs can help you to become familiar with the terminology, mindset, and some theory. You should not expect to be hired because a sheet of paper says you are a product manager. Good product managers are made and tested in everyday life. Education is a bonus, but education alone will not get you far.

Conclusion

When we look at the three options described above, we see that there is no “right” or “wrong.” Each way comes with its advantages and disadvantages. For example, starting as a PM associate is a slow but safe path. Internal transition is more challenging and requires some good opportunities. Joining an early-stage startup can quickly get you into product management, or out of it, as it is the most stressful and challenging path.

No matter which (if any) of the ways above you choose, first you need to understand whether product management is the job you want to go for. It is a great and satisfying job with many opportunities, but it is also very challenging and stressful. During the last few years, I have seen many people becoming PMs in all the three ways described above. Find the one that fits your personality and preferences the best. I hope this article is helpful on your journey. Feel free to share your experience and thoughts in the comments below.

Reading Recommendations

The requirements on product management are different in the various stages of a company. Understanding these different needs will help you to understand where to apply, how to plan your career, and where you fit best. Thus, I recommend you to read “How to Craft Your Product Team at Every Stage” in addition to this article.

No matter which path you choose, building a continuous learning and reflection habit will always help. Make regular time for reading and find a mentor if you can. I often see PMs not taking enough time for self-reflection and learning because they are too busy or stressed. This is a critical mistake. Remember “All leaders are readers, but not all readers are leaders.” The following books and articles have helped me on my journey:

Books*:

• The Lean Product Playbook
• Inspired
• Building Better Products and other books from Rosenfeld

Newsletter:

• https://www.mindtheproduct.com/product-management-newsletter/

Articles:

• Some basics about user research you need to know
• An intro about experimentation
• You need to understand “product discovery”
• Basic “problem first” mindset
• To foster your “problem first” mindset
• Some input on roadmapping
• One of my favorite frameworks
• Scrum vs. Kanban, what do you think?
• Defining goals and objectives is key. It starts with a clear north star.
• A practical flow charting technique I like
• Questions to exercise for you PM interview
• Running planning meetings sounds easy, but isn’t
• Understand what type of PM you want to become
• Important, basic mindset
• “Decision making” is a skill, often being forgotten
• Some basics about working with data
• Basic mindset about prioritization
• 20 prioritization methods you should have heard of
• Overview on the PM career track and skills
• About PM hiring, understand what they are looking for
• Great advice for stakeholder management
• A long, but true list about what a PM does

*Book recommendations contain Amazon affiliate links

3 proven paths to becoming a product manager was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.