Product Manager Onboarding Done Right, and How to Work with Subject-Matter experts
I was recently asked to provide a few words on Product Management to the folks over at Producter, and you don’t need to ask me twice. Check out the questions, and my answers, over here.
There are many ways that product development can go off the rails, but if you wait until the train is at the bottom of the canyon you’ve missed so many chances to fix the situation. Keeping close to developers and treating them as true and equal partners to the product management function can help minimise the chance of disconnects. Fast feedback loops and constant communication enables you to anticipate and fix problems when they’re small.
A word from the sponsor - Product People
If you’re a company founder or product leader who needs to get a product management team up and running quickly or cover parental leave check out Product People. They’ve got a thriving community and 40 in-house product managers, product ops pros, and product leaders. They onboard fast, align teams and deliver outcomes. Check out Product People to book a free intro chat and quote code OKIP to get a 5% discount.
New podcast episode: The Trouble with Product Management Onboarding and How to Get it Right
Speaking of Product People, I recently spoke to their founder & CPO Mirela Mus to talk about the problems with product management onboarding, why it’s so bad, and what people can do to land in a new role effectively. It was an interesting chat and you can listen to it on your favourite podcast app or on this link here.
Onboarding for product managers is harder than for most roles
Product managers are at the centre of everything and the requirements of the role can be really ambiguous depending on the company. The product culture is often underdeveloped which can drag product managers down.
Product Managers & Subject-Matter Experts
A little while ago, I Tweeted about subject-matter expertise and how it can impact your product decision-making in a B2B startup. I broadly bucketed people into 4 categories on a quadrant.
Let’s recap what these buckets mean before discussing some more general ways to approach dealing with subject-matter experts, who have strong opinions and long experience in your industry (and expect to have that experience weighted highly when planning out the roadmap).
The Potential Disruptor
They have product chops and maybe built a product in this industry before, so they know where the pitfalls are, broadly what can & can't be done, and are the most likely to help the product team build something disruptive and new.
The Essential Informer
They know the industry inside and out, but they've never built a product to speak of. They are the closest equivalent of your customers, but they aren't your customers. They can be super-insightful partners but beware of status quo bias.
The Customer Enquirer
The good old-fashioned generalist PM, who believes that good (hopefully continuous) discovery and a solid vision & strategy will see them through. Likely to have little status quo bias, but limited industry credibility & need help with the acronyms.
The Helpful Observer
Ones to watch - maybe they'll develop industry or product expertise. Meanwhile, they can help sense-check you & make sure you're not doing anything quite obviously stupid. It's also true that good insight can come from anywhere. Don't ignore them.
So, let’s assume you’re dealing with a subject-matter expert. Again, they have long-standing, legitimate expertise in your industry. They probably worked in it for a while. They have a clear idea about what is obvious, what are table stakes, what the market is doing and who your competitors are. But, on the other hand, you don’t just want to work in an SME Feature Factory. How might we approach this?
Acknowledge their expertise
The worst thing to do is to dismiss these people out of hand. As I said, they have legitimate expertise. These people aren’t making it up. They probably do know more than you about banking, healthcare, supply chain management, payments, or whatever your company does.
It’s very easy for PMs to get defensive, and start talking about product discovery and how the user has the final say. And, obviously, we want to be talking to users (and, very importantly, buyers). However, it’s a mistake to dismiss people’s legitimate expertise. We need to develop empathy for, and connections with, our valued subject-matter expert colleagues. Acknowledge their experience and their history. Don’t diminish it otherwise you’re starting off on the wrong foot.
Listen openly to their opinions
Subject-matter experts will have lots of opinions. Some of these opinions will be actual, indisputable facts. Some will be more tenuous, or very context-specific (the company they used to work at, for example). It is a mistake to discount these opinions out of hand. It’s doubly a mistake to do this with no better idea, or opposing evidence. But, even if you do think you have competing evidence you should still listen to people openly and take notes. Find out what they want and why they want it.
Give them fair consideration
Your job as a product manager is not to just listen to people and do exactly what they say in the order that they say it. Obviously, your mileage may vary here depending on the culture within the company, but your job is to sort through the million and one requests to work out what the really important stuff is.
Ultimately, the feedback (or direct requests) from subject-matter experts is a fantastic jumping-off point for product discovery. This will be tricky in some situations. You may be told something is “obvious”, that “everyone wants this”, or words to that effect. But, you know, the beautiful thing about obvious things that everyone wants is that it’s really easy to check whether that’s true.
As with any customer or user discovery, subject-matter-expert discovery needs to have some proper Jobs to be Done thinking applied to it. What are they asking for, why are they asking for it and what is the end goal of users getting this functionality? It’s quite possible that they have actually asked for the right solution, but don’t take it at face value, and do try to abstract it out to the original problem.
Let them know what you’re doing & not (and why)
Especially opinionated subject-matter experts in very top-down companies with a limited product mindset may well expect you to just jump at every request. We all know this can happen. But, assuming that you’re in any kind of position to prioritise the roadmap then communication is key. Look at the problems you’re being asked to solve and filter them through your product vision and product strategy (you do have a product vision and product strategy right?). Talk to your stakeholders, explain the rationale, what they’re getting instead and the evidence that you have that it’s a better idea.
It’s important to never, ever demean the idea or especially the person. Remember, these are valuable professionals with strong expertise. Just because their idea isn’t on the roadmap right now doesn’t mean that it wasn’t a good idea. As David Bland once advised on my podcast, don’t attack ideas, attack assumptions. People get attached to, and defensive about, their ideas. Assumptions are much easier to talk about without letting emotion get in the way.
Subject-matter experts tend to be rated incredibly highly by leadership, especially if the leadership team happens to be comprised of many subject-matter experts. If you can’t build a constructive working relationship with these people, you are setting yourself up to fail (and, even worse, the inevitable escalation and pain of being overruled).
Thanks for reading!
Hopefully, some of this will be helpful for any of you out there who are having some thoughts about your own subject-matter experts.
Thanks for reading, do please send feedback and let me know if there are any topics you’d like me to cover. And remember to share the newsletter with your friends!
If you want to buy me a coffee, you can buy me a coffee.
Thanks for reading One Knight in Product newsletter! Subscribe for free to receive new posts and support my work.