Photo by Chris Yang on Unsplash

Product Managers — Don’t Fake It ’Til You Make it.

How to minimize imposter syndrome and quickly build a solid foundation to be effective when starting a new Product Managment role.

TL;DR — Onboarding Product Managers and getting them up to speed needs to be a deliberate act that is planned and executed by the Product Manager and their manager.

Given the amount of knowledge and context needed for Product Managers to do their jobs well, it’s important to take an intentional and systematic approach to this.

The actual needs will vary from Product Manager to Product Manager and company to company, but three key areas need to be addressed: relationship building, knowledge acquisition, skills development.

Table of Contents

• Background
• Three Key Areas of Focus
• Relationships
  — Identify key internal and external contacts
  — Prioritize and hold meetings
  — Debriefs and follow-up activities
• Knowledge
  — Market Knowledge
  — Competitive Knowledge
  — Customer Knowledge
  — User Knowledge
  — Product Knowledge
  — Business Knowledge
  — Organization Knowledge
  — Ecosystem Knowledge
• Skills Development
  — Focus on larger Product skills
• Conclusion

NOTE: This post is a means to address Dysfunction #2 — Under-skilled Product Managers — in my post The 5 Dysfunctions of Product Management Teams.

Background

Whether you’re new to product management or starting a new product management role, there’s an enormous amount to learn before you can get up to speed, become productive and have real impact on your organization and product.

“Fake it ’til you make it” is a line you’ve probably heard before.

I’ve heard it in Product Management contexts, often tied into discussions about imposter syndrome. Yes, we all face it in our careers.

Here’s a great talk by Mike Cannon-Brookes (co-founder of Atlassian — yes the makers of Jira/Confluence etc.) on Imposter Syndrome. It’s well worth watching.

Given a lot of people become Product Managers with little to no formal training or education, and with high expectations placed on them, it seems like “fake it til you make it” is the only option.

But it’s a really bad strategy. REALLY BAD.

Product Management is a difficult and complex job, even when you are experienced and up to speed.

Product Managers are in highly visible, highly influential, and highly impactful roles. A lot of eyes are on you as a Product Manager, and if you don’t know what you’re doing and are faking it, people will know, and things will not end well. You may not get fired, but you’re digging a credibility, trust and execution hole that will be difficult to get out of.

This can also lead to burnout for Product Managers and expensive lessons learned for businesses, including turn over, lack of team alignment and lost business opportunity.

Often, companies hire or transfer in someone who they believe is a capable person with some seemingly relevant background — they have technical or domain knowledge — and make them product managers and expect them to learn on the job. How hard could it be? They’re smart and really eager to do the job, right?

As a new or incoming Product Manager, you face a lot of questions and decisions:

• What’s the current state of the product and the business?
• What issues, problems and gaps need to be understood and addressed?
• How should you focus your efforts?
• What really are the most important priorities?
• How do you work cross-functionally in this new role?
• Are there any goals and strategies that need to be understood?
• Who are the key people that really have influence?
• Who will be your allies? Who will be the opposite?
• How do you keep “stakeholders” happy? Who are the “stakeholders”?
• What partners should you get to know”
• What impacts can you make?
• What’s on the current roadmap?
• Is there even a roadmap or roadmapping process?
• Why did the previous Product Manager decide we needed to build what we’re currently building?
• What decision criteria were used?
• Do they still apply for upcoming decisions?
• Why is Sales blocking access to customers?
• How will I build customer relationships?
• Why does Sales need so much help from me?
• Why doesn’t Marketing have better messaging?
• Why do all these fires keep popping up?
• Is all of this really MY job?
• etc.

The reality is that even for an experienced Product Manager, there is a lot to learn in a new role BEFORE they will be really productive.

Three Key Focus Areas

There are three things that will help you make it (and not have to fake it).

• Relationships (who you know and who knows you)
• Knowledge (what you know)
• Skills (what you can do well)

And while people want to “hit the ground running”, “get some quick wins”, focus on “outcomes over outputs” and “make an impact”, you can’t do any of that effectively unless you build the key relationships and hone the needed knowledge and skills first.

But it’s not just any relationships, knowledge, or skills you need, but the ones most relevant to your job and your objectives.

You must identify the gaps and develop a plan to address them.

This must be an intentional and analytic step, and you perform with the support and participation of your manager. And it will take time and effort. Don’t rush it, but don’t delay in starting it.

Far too many Product Managers are brought onboard, and for all intents and purposes, left to “figure it out” with minimal assistance unless they ask.

“Let me know what help I can provide.” or something similar is what I’ve heard a lot of managers say.

Or slightly better, but equally ineffective, is a “plan” that is put into place to get “up to speed”, but then falls to the bottom of the priority list once “real work” starts filling the daily schedule.

Product leaders MUST take an active and explicit role in ensuring Product Manager onboarding is successful

And remember this must be done with the active support and participation of your manager, with a clear understanding that this is important, it provides significant benefit in the short AND long term, and it CANNOT fall by the wayside when “the job” gets busy.

This is critical to doing your job well, and moving forward and delivering outcomes and impacts.

So, here’s a process to use to get “up to speed”, and fill in those gaps so that you can quit faking it and work confidently and effectively in your role.

NOTE: The following sections lay out a comprehensive path to enable Product Managers to gain the knowledge to perform efficiently and effectively. While I don’t lay out any specific time frames for these activities, this process takes time. 30–60–90 day milestones are a starting point. After 90 days, a Product Manager should have enough knowledge to function well, but the learning should continue beyond that first 90 days.

In most of my own jobs, often the total time it took me to feel like I wasn’t “faking it” was about 6 months, maybe up to 9 at the most. Six months to build and grow working relationships, gain the context and knowledge I needed, understand internal processes and power structures and start having real impact within the company.

This doesn’t mean nothing else is happening for six months, but the growth in knowledge, confidence etc. is a curve, not a step function.

If you’re a Product Leader, and you’re hiring and developing future Product Leaders, then a 6 month time frame should NOT be a surprise to you.

Relationships

Product Management is a cross-functional job. It is about working with others, enabling them, aligning them and driving results. It’s an impossible job to do alone, and can only be accomplished by first building strong working relationships with others within and outside your company.

Here’s a suggested process to follow with your manager. But feel free to adjust as needed.

1. Identify key internal and external contacts

Product leaders must identify a list of key internal AND external people the Product Manager should get to know. This list includes internal counterparts, influencers, executives and others who the Product Manager should start building relationships with. These are people who can help the Product Manager, but also, and equally importantly, need the help and support of the PM.

It’s important to include external contacts as well, including key customers, partners, influencers, analysts etc. Being a new PM is a good reason to meet with these people and for them to meet with the PM.

The external contact meetings should be held AFTER the internal ones are complete, AND the PM has gathered some other context in terms of product and market knowledge.

But don’t put this off too long. Perhaps a few weeks to a month at most before starting external meetings. At that point, other priorities may come up that push the external meetings down on the priority list.

Needless to say, starting a new role by building strong relationships is a great foundation for future success.

Photo by Christina @ wocintechchat.com on Unsplash

2. Prioritize and hold meetings

Prioritize the list and set up meetings with each individual.

For a reasonable sized list — say 10–15 internal individuals — the goal should to hold those meetings over a few weeks maximum, depending on availability of the people. Internal should be easier than external for obvious reasons.

For each internal person, the Product Manager should:

• understand who they are
• what they are responsible for
• their objectives that relate to Product Management
• where they see Product Management helping them and hindering them
• The Product Manager should also share some information about themselves and their goals, focus, direction etc. back with these people. i.e. they are mutual learning sessions.

For each external individual, the Product Manager should:

• understand who they are (look them up in your CRM)
• learn the history of their relationship with the company (when they bought, what they bought etc)
• how they are using your product(s) — (how many users, where, for what projects/purposes)
• what successes they’ve had and what challenges they’re facing
• anything else that may be of interest

3. Debriefs and Follow-up Activities

The Product Manager should debrief with the Product Leader after the meetings to hear what transpired, fill in any gaps or answer any questions that came up, and where needed, help define some activities to work with or support some of these people.

This series of steps provides a structured way to introduce the new PM to key people and better integrate them into existing work-related contexts.

Knowledge

A lot of time when people talk about “getting up to speed” they create goals for the first 30–60–90 days etc. There’s nothing wrong with that, but it’s important to understand what is really involved in “getting up to speed”.

In the case of knowledge, there is external knowledge and internal knowledge. i.e. knowledge about things outside the company and things inside the company.

External/Domain knowledge

The external knowledge is often called “domain knowledge”. But what exactly is domain knowledge? It consists of the following four areas:

1. Market knowledge—the market & industry trends, direction, opportunities, and threats.
2. Competitive knowledge — established and emerging competitive products and how they impact company/product positioning and sales/marketing efforts
3. Customer knowledge — how key customers buy (evaluation and buying process) and use (product footprint, history, benefits, results etc.) the product, as well as a breakout of usage across the customer base and other customer dynamics
4. User knowledge — the needs, personas, and major use cases and scenarios of users.

I’ve listed these out explicitly though clearly some are related. e.g. Market and Competitive knowledge, Customer and User knowledge. But it’s important to drill down into them as each type of knowledge is nuanced and their characteristics will vary from company to company.

Internal Knowledge

Internal knowledge consists of specific information that is available inside the company and directly related to company operations or context.

1. Product knowledge — the details of the product capabilities, architecture, operations, key uses cases, benefits, messaging, strengths/limitations and current roadmap, strategies and plans.
2. Business knowledge — the business side of the product (and company if needed), in terms of revenue, growth, strategy and objectives, business challenges and threats etc.
3. Organizational Knowledge — how the company or organization works. What processes exist and which ones are important, where the power structures reside, individual or team/department dynamics etc.
4. Ecosystem knowledge — the breath of partners, resellers, OEMs etc. influencers, analysts and even investors, that form the supporting and supported ecosystem in which the product and company play a role.

Note that depending on the scale and maturity of the product and company, each of these will vary. e.g. for a small startup, the ecosystem may be tiny (or non-existent), and the business aspects may be very simple, and with only a few customers there may not be a lot to learn etc. But, for a more mature product in a larger company, each type of knowledge may require significant time and effort to understand in depth.

Acquiring the Knowledge

Here are the steps for a PM to gain the needed “domain knowledge” for a new Product Manager. Note that gaining sufficient domain knowledge to work effectively is the goal here. Maintaining and enhancing that knowledge to become a “domain expert” (or equivalent) is a process that takes time (many quarters or years) and should be a long term goal for Product Managers.

1. Market Knowledge

A product leader and other PMs should be able to provide a LOT of the market knowledge for a new PM, but additional information should be gained from conversations with staff in Marketing and/or Product Marketing, as well as reading existing internal documents and external analyst reports or other related content.

Understanding key markets and market segments, trends in the markets, whether the markets are growing or declining etc. are all important to understand.

Photo by Quino Al on Unsplash

2. Competitive Knowledge

In a large company, perhaps there is a Competitive Analysis team that can educate the Product Manager, but if not, look for those who conduct sales enablement and learn about how they see the market and shape it for the sales people. Product Marketing Managers, Sales Engineers and Salespeople themselves are also great people to speak with to gather competitive information. They’ll each have their own perspectives, and the mix of their views will give some good insight to Product Managers.

It best to understand competitors strategically — i.e. how they are positioned in the market, their strengths and weakness and key messages etc. It’s almost never a good use of time, especially early on, to go deep on features/functionality of competitors. That knowledge will come over time if needed, but the most important and useful information is the strategic information.

3. Customer Knowledge

The best way to gain customer knowledge is through conversations with customers themselves. But first, it’s helpful to get an understanding of the customer landscape.

• How many customers are there?
• What is the customer distribution geographically?
• What industries are they in?
• What size of companies are customers?
• Where does your product have the biggest footprint?
• What is the most common footprint?
• What are the typical deal sizes?
• What is the customer acquisition rate?
• What kinds of customers have churned?
• etc.

Most of this information can be found in a CRM so the Product Leader should provide access to the Product Manager, but also help them navigate the data and also connect the Product Manager to key people in the company who can help provide context where needed. Perhaps the Product Leader can do this themselves (hopefully s/he has the needed customer landscape knowledge).

Once the customer landscape is understood, connecting with real customers is essential. A new Product Manager has an excuse to meet them and listen and learn from them. This also ties into the relationship building mentioned earlier.

Aside from direct customer conversations, internal teams such as Professional Services, Customer Success, Customer Support, and Training groups, who have direct customer contact and relationships themselves are great source of customer insights. They can also potentially connect a Product Manager directly to some of those customers for additional relationship building.

4. User Knowledge

User knowledge is tied to customer knowledge, but of course at a different level. When having conversations with customers, you can help but also engage with actual users of your product.

Understanding users, their backgrounds and skillsets, their objectives and challenges, their workflows and processes are all important.

I once managed a product and one of our target users was QA Engineers for BI and data applications. We had assumed that they all knew SQL. After a number of customer visits, never thinking about talking about specific skills, one customer told us that one of his challenges with our product — which required *some* SQL knowledge — was that his QA Engineers didn’t know SQL and that they’d constantly need to ask Developers for help.

This came as a shock to us. When we investigated this in other customers, we found out that there were many (perhaps 30%-40%) customers that had this issue. It really caused us to rethink how we could support these users in our product.

Photo by Susan Q Yin on Unsplash

5. Product Knowledge

There are many ways to gain product knowledge and Product Managers should take advantage of them where possible. These include:

• Formal product training
• Learning from Sales Engineers and Professional Services
• Learning from Customer Support and Success

Formal Product Training: If there is a formal product training course, given either by the company or partners, have the Product Manager attend that as first step. Not only will this be a structured approach to training, but it will give the PM great insight into how customers are training and what their experience is. The PM may also meet some new customers and start some relationship building in the class.

When I worked as a Product Manager, I would try to take the formal product training for my products at least once, and if possible every couple of years, to gain these benefits.

Professional Services and Sales Engineers: Aside from formal product training, Product Managers should spend time with Professional Services (PS) and Sales Engineers (SEs) if they exist and see how they present and use the product.

Both of these groups will be intimately knowledgeable with the product but view it from different perspectives. i.e. SEs will have a more sales-focussed approach, showing the best side of the product and hiding the warts etc., while PS will be very implementation focused, know the limitations, workarounds and ways to implement the product in the “real world”.

Insights from both of these groups will be very helpful to PMs and of course, there’s more relationship building going on during these sessions.

Customer Success and Support: These two groups are critical for a PM to gain product knowledge. Both of them are focused on customers using and succeeding with the product and they are solid conduits for the reality of what the product is achieving (or not) in practice.

When I worked as a PM, I found building relationship with these two teams to be invaluable because they provided the earliest signals of problems or progress with the product. In one company, I had weekly meetings with these teams, helped them if they needed to escalate issues, but also gain great insight into any product issues as well as customer usage scenarios.

Demoing the Product: A goal for a new PM should be the ability to demo the product with confidence. This shows understanding of the product as well as it’s strengths and benefits. There is a risk here though and it should be clear that this ability to demo the product is so the PM can be effective in her role and NOT, I repeat NOT, so that the PM can be an adhoc Sales Engineer or something similar when other teams are short staffed.

6. Business Knowledge

This will come over time, but PMs should learn the basics about company and product strategy, product revenue, growth, licensing, pricing, renewals etc. The amount of business knowledge needed really depends on what the Product Manager needs to do their job.

Many Product Managers are quite removed from the business side of their product, and that’s a shame. i.e. they are very focused on “feature delivery” and working with Engineering. That’s lost opportunity for the company and the Product Manager to contribute more to help drive product success.

Regardless, the Product Leader should define the initial business knowledge needed by the Product Manager and help them attain it. After that, the Product Leader and Manager should work so that the Product Manager stays abreast of business issues and context related to their product.

7. Organization Knowledge

In a small company, getting to know the people is almost the same as getting to know the organization. i.e. it’s easy to see who has power, authority, influence etc. and the processes and systems are relatively transparent. Any “insider information” can be learned over lunch or drinks with a few coworkers with longer tenure at the company.

But in a large company, things are more opaque. And while an org-chart will show how the company is structured, it won’t tell you how information, insight and influence flow. A Product Manager should learn about the following within the company

• the various software systems that hold key data (CRM, Issue Tracking, Wikis, marketing portals, product portals, customer portals, etc.
• key people/teams who hold power/influence in the company. e.g. in one company I worked at, the CTO had huge influence over many product decisions, including aspects such as product naming, licensing and packaging. This was definitely not the norm in most companies.
• Any specific processes, rituals or other cultural aspects that Product Managers should be aware off. e.g in one client I worked with, they had a very structured bi-annual (every 6 months) roadmap and release planning cycle. There was a formal process that a Project Manager led and it was something that had participation and visibility all the way up to the CEO. This was definitely something a new Product Manager would need to learn and participate in.

8. Ecosystem Knowledge

Last but not least, we come to ecosystem knowledge. The ecosystem consists of people and companies OUTSIDE of the organization that play a key role in the Product Manager’s domain or context. These could be companies with a:

• technology relationship (we license/OEM their technology)business
• relationship (they license/OEM our technology),
• key service partners (implementation or training partners)
• resellers/distributors (regional VARs or resellers) etc.

Or they could be individuals who are evangelists, influencers, customer advocates etc.

The ecosystem is a force multiplier for the product and it’s important to get an understanding of who the members of that ecosystem are from Day 1 (or thereabouts)

Skills Development

The third and final area of focus is skills development. There are a lot of skills Product Managers need to do their jobs including everything from Positioning, Messaging, User Journey Mapping, Writing Requirements, Presentation skills, Communication skills, Decision Making, Negotiation, User Reseaerch, Quantitative and Qualitative analysis, Experimentation etc.

But there are a smaller number of higher level Product skills (as I call them) that Product Managers need to have and apply very early in their tenure at a company. These include things like:

• Discovery
• Roadmapping
• Strategy Creation
• Product & Release Planning
• Prioritization etc.

When we interview and hire Product Managers, we normally vet for many of these skills, but no interview process is perfect and there is a big difference between interview performance and real-world performance after being hired.

Additionally, the actual processes of discovery, roadmapping, planning etc. vary from company to company and even across products within the same company. The Product Leader must work with the Product Manager on the first cycle through each discovery project, roadmapping cycle, planning cycle etc. to ensure they apply their raw skills correctly in the context of what the company needs.

For example, the word “roadmap” means VERY different things to different people. And the process for creating a roadmap, including external research, internal socialization and communication can be more important than the actual roadmap contents themselves.

Working through these Product Skills with the Product Manager to ensure they not only have the raw skills but also the process and company context will embed that knowledge in the Product Manager’s mind, and their initial success will not only benefit them directly, but it will help them build credibility within the larger organization with executives and team members.

Conclusion

This is a description of a comprehenive process to onboard new product managers. It may sound overwhelming and perhaps even overkill. Who is going to have time to learn all of that?

But the reality is that a well functioning product manager will need to develop those relations, gain that knowledge and skills at some point in their tenure at a company. The real question is, can that process be accelerated so that the Product Manager contributes at their full potential as early as possible, or should she work in a hobbled manner, suffering from imposter syndrome for far longer than needed, and faking it, without ever making it?

The choice is up to you.

A little feedback please

If you’ve read this far, thank you. I’d like some feedback on the article to make it better. It should take just 1 minute, but will really be valuable to me. Thanks in advance.

===> Click Here <===