PM Interview Series: Product Management in a Nutshell with Clement Kao
My encounter with Mr. Clement Kao from Blend started from his LinkedIn connection invitation. I gladly accepted his invitation and we chat a bit about his career at the moment. I was quite delighted to know that Mr. Clement Kao is an avid writer and co-founder of Product Manager HQ (PMHQ). Mr. Clement published 70+ product management best practice articles on the PMHQ website.
I would not want to miss the chance of getting product knowledge from an avid writer like him. As a professional contributor to PMHQ, I will embed links of his thoughtful articles throughout the interview transcript so you can also have some context!
For a better reading experience, I will list the topics discussed in this interview:
- Product Manager
- People
- Ideation Until Launch (Product Roadmap, Priotization, User Research, Project Management)
- Competitors
- Performance (Product Life Cycle, Metrics, Apps Interface, A/B Testing)
- What distinguishes Great PMs from Good PMs
Product Manager
Q: Product Managers are often being confused with Project Managers. In your opinion, what is/are the stark difference(s) between the two?
At a high level: product managers maximise upside (and therefore expose themselves to risk) whereas project managers minimise risk (and therefore cannot kick off exploratory experiments). I have a PMP (project manager professional) certificate, so I speak from experience.
To elaborate more on this topic for the curious souls, Mr. Clement also shared one of his insightful articles on Product Manager vs. Project Manager on PMHQ. Do give it a full read if you can! :)
Q: “To be a great PM, one must be from a tech background.” Do you find this statement to be true as per your personal experience?
No.
Q: What do you think is the most crucial criteria, in terms of hard skills (aside from leadership, management, etc), a great PM must possess?
The most crucial thing is to have empathy for stakeholders, and that includes empathy for engineers.
You can see his article here on empathising with engineering (and why you don’t need a technical background).
People
Leadership & Attitude
Q: What does it take to be a convincing, persuasive Product Manager?
Stakeholder empathy is the one thing that we need the most. Until we understand what makes our stakeholders tick, there’s no way to persuade them. This includes executives, managers, cross-functional partners (e.g. sales / marketing / legal), and podmates (e.g. engineering, design, QA).
Q: What do we need to do to earn the respect of our team?
Demonstrate that you care about them — set up 1:1’s and gain stakeholder empathy. Then, keep your commitments. I like to use a running 1:1 doc so they can see everything that I’ve tasked myself with on their behalf, and provide status updates on whether I knocked those out or not. That creates a historical record of my accountability.
Team & Stakeholders
Q: What is the typical size of a team managed by a PM?
Depends on the company and the product maturity. Sweet spot is 5 engineers, but I’ve worked with only 1 engineer before, and I’ve worked with 24 engineers before.
Q: For the success of your product, who do you usually collaborate with? (Finance, Legal, Sales, Designer, Testing, etc)
This will sound trite, but it’s “everyone”. Finance, legal, infosec, sales, account management, deployment leads, customer support, marketing, design, QA, engineering, management, etc.
Q: What do you usually share in a PM meeting?
Depends. You can either meet to share context, or you can meet to drive to a decision and next steps.
Read more on Effective Meetings for Product Managers by Mr. Clement for a better review regarding PM meeting.
Q: How often do you need to collaborate with other PMs from other teams?
Depends on the product. Sometimes every single feature requires collaboration, other times none of the features ever need input from other PMs.
Ideation until Launch
Product Roadmap
Q: Where do backlog ideas usually come from?
Customers and internal stakeholders.
Q: How do you differentiate pain points from raw insights?
“I wish you build this solution.”, customer said. We should not really go into this feedback without understanding the actual pain points.
How do we attempt to understand the actual pain points?
1. Ask why. be better listeners to your customer.
2. What problem does it solve for you?
3. Try to better understand why they ask for such a request, because a feature request means there is a hidden pain behind it. And it is our job to identity this hidden pain.
But there comes a problem, pain is too abstract. but in an umbrella term of pain, it is usually referring to “more money to have or less money to spend.”
Weave in the discovery process into the sales process.
Q: What do you usually do to validate your ideas?
We do user research.
Q: What decides which product/initiative should be put in the product roadmap? What does a typical idea usually go through in order to be on the product roadmap?
The PM is the ultimate decision maker, but they take input from customers, cross-functional stakeholders, and leadership.
Q: How flexible is your product roadmap? How often do you go back to your product roadmap to revise your roadmap?
Very flexible. I edit every week.
Q: What are the protocols in finalising or revising a product roadmap?
I write the roadmap, I share with stakeholders asynchronous, if someone has objections then I talk through them what their concerns are and continuously edit the roadmap. Roadmaps are organic, living documents; they are not meant to stay in stone.
Q: If a company decides to change their business growth vision, how is the adjustment going to be?
We perform quarterly planning (rolling 12 months) from both a top-down perspective and a bottoms-up perspective, and then we realign all roadmaps and all metrics to the new quarterly plan.
Q: Do you use decision making framework/tools?
Yes.
Q: What decision making framework/tools do you usually use?
Three questions to ask:
Is this a reversible decision?
What is the ROI? Is this the highest ROI thing we could do?
Is there a window of opportunity, or is this opportunity evergreen?
Q: With the three questions asked before, what is the next best thing to do then?
The challenges with any kind of prioritisation, or any decision making framework, is that decision making is an art, it is not a science. and so, there is some amount of cost that you are spending in trying to understand whether this decision is good enough. So, if you spend 6 weeks trying to understand whether a decision is correct or not, that is much worse than if you spend two days to make a decision, spend two weeks building this, and come to a conclusion that this is not a good decision.
There is a part one: if it is a reversible decision and it doesn’t cost you a lot, it doesn’t commit you to anything, you might as well just go into it, because then, there is no long lasting pain.
but, part two, if it is an irreversible decision, it costs you a lot of time that you can’t get back, then you would have to ask, is this the best way to use our time? One way to ask: what is the ROI (return on investment) that you are going to get? This applies in a case where there are two initiatives: the first initiative costs us 100 dollars and ROI of 1,000 dollars meanwhile the second initiative costs us 100 dollar and ROI of 5,000 dollars. We should go with the second initiative instead. So that helps you to identify the sequence.
But then, there comes another problem of: a lot of opportunities just don’t last forever. Product is always in an evolving landscape with competitors (shifting market demands, and etc.). So, there are many times that you just need to go with the smaller ROI project first, because there won’t come an opportunity like that later on. There are going to be times when you are forced to do the projects with smaller ROI, but it is urgent. There won’t come any other time where you can do it, which this will hinder you in the long run.
So, the reason there is no one right answer is the answers to the 3 questions above fundamentally changes the landscape of how you are making a decision. It depends on what your executive thinks is important, and what you think is important.
Q: Cost of delay. Do you use this as a method to identify which feature/product to prioritise?
not always, because cost of delay is ultimately, a cost in the cost-benefit analysis. There are two component of a product:
benefit component (to your customer and to you) and cost component (which is not just the cost of delay, but the cost of building it).
If you optimise simply on the cost of delay, then you will be building a lot of short-sighted features that are not going to ladder up to a broader product roadmap, and you are going to build a lot of features that are urgent, but not important (projects that might not have ROI to begin with). Just because it costs you a lot to get your foot in the door of some tiny market, doesn’t mean that you are going to want to go to that tiny market in the long run. But if you are trying to keep your door open to everyone, that is something that a product team might do. If you are trying to get into all 50 markets by building tiny projects, then there is the broader question to ask: should you actually be in those 50 markets?
If you are only use the cost of delay, you are not going to build a good product. but if you don’t use the cost of delay, you are also not going to build a good product. So it is an art of balancing.
So if there is a huge cost of delay but no ROI to begin with, then you should not be doing that feature.
Q: How to manage product discovery and delivery?
For discovery: meet with customers regularly, demo / ship on a relentless cadence, get feedback and talk through tradeoffs.
For delivery: this is project management, stay on top of Jira and standups.
Prioritisation
Q: How do you prioritise features / projects and cut out the noise?
I work in B2B. The factors are:
how large is the aggregated customer demand? How deep is the impact? This gives me a benefit number.
Then, what is the engineering cost?
Divide benefit by cost to get ROI. Evaluate ROI vs. all other initiatives, and sequence based on highest ROI.
Q: Which one will you prioritise first: developing new products / features to attract bigger markets which require high-level cost of resources, or developing a feature that tackles risk assessment of our application first?
Depends on the lifecycle of the product. If there’s fundamental missing capabilities that would unlock significant new markets, then we tackle those. Otherwise, we try to avoid refactoring just for refactoring’s sake.
Q: Does every prioritisation need to be calculated objectively?
No, not all of them need to be objective. If it’s a low cost (less than 1 dev-week), and is clearly a better UX for the majority of users (e.g. cannot just be an edge case), we’ll invest there even if we can’t measure it.
User Research
Q: Which process do you usually act on first: idea or surveys?
Surveys are not generally valuable in B2B. I’ve never used a survey in my time as a product manager. I always jump straight to conducting user interviews, and presenting multiple alternative ideas in a neutral way. That way I can get their reactions to various perspectives and understand how they’re thinking about the problem.
Q: How frequent do you conduct user research?
Every day. Every sales conversation and feedback report is user research.
Q: What method(s) do you find is/are the most effective in identifying customer’s pain points & feedback?
He suggested me to read on his article for user interview, which you can also read here: conducting effective user interviews. But for the purpose of the wholesome learning points for myself, I will write a short summary (which will contain mostly quotation from the real article for better interpretation) on his article:
This guide is structured the following way:
Before the Interview:
- Plan
Determine what your objective is for conducting the user interview. Are you trying to better understand a particular problem? Do you have a hypothesis in mind that you’re trying to prove or disprove? Is there a product decision that you’re trying to make?
Based on your objective, come up with questions that will help you achieve your objective.
Note that most user interviews shouldn’t go past 60 minutes, since interviewees tend to run out of energy and focus by then.
- Source
To conduct interviews, we need interviewees. I realise how dumb that sounds, but finding interviewees is honestly one of the hardest parts about user research.
We need to find willing participants. One great way to jumpstart your pool of interviewee candidates is to start with family, friends, and colleagues as initial interviewees, and to ask them to refer others to you.
As you look for participants, consider both unpaid (word-of-mouth and postings) & paid channels.
In cases where you’re finding lots of difficulty in recruiting, considering hiring a third-party professional sourcer.
- Screen
You need to ensure that the users you interview are not biased. Biases come in two broad categories: beliefs and demographics. To account for these biases, you need to ensure that the sample you take is representative of the market that you want to tackle.
But, it is also important to take note that similarly, we shouldn’t exclusively limit ourselves to a particular geography unless that’s the specific geography we want to tackle.
- Schedule
Be sure to leave time between interviews so that you’re not rushed from one to another. You want to ensure that you have some amount of buffer time in between interviews, especially where you find a thread of inquiry that’s particularly insightful but requires additional time from what you had originally scheduled.
During the Interview:
- Contextualize
Provide context to your interviewee. Who are you, and what are you generally looking to learn about?
Stay high level and keep your product out of the discussion for now. What is she trying to accomplish, and why is she trying to accomplish it? What’s blocking her from being more effective?
- Dive
Your most important objective is to learn how to think the way your interviewee thinks — try to understand what they are feeling, make them feel included and actively listened.
First, ask questions in an unbiased way. Instead of asking, “Why is it so painful for you to shop for groceries?”, ask “How do you feel about shopping for groceries?”
Second, don’t ask a ‘yes’ or ‘no’ question. Do not ask “are you the one who is buying the groceries for your household?” but ask “who are the one buying the groceries for your household?”
Third, ask “why” to any answer that you get back. You may feel embarrassed, or you may feel the answer is complete — but many times, you’ll find that going one level deeper will yield new insights or ways of thinking.
- Replicate
Close out the interview by running through hypothetical scenarios with your user, or by running through wireframes and prototypes. Now is the time to see whether their behavior is the same as their stated thought process!
After the Interview:
- Retrospect
Once you complete the user interview, reflect on the experience immediately. Use whatever downtime you have until the next interview to reflect on what you’ve learned. Are there other areas of inquiry that you should going after instead? Are particular questions not working the way you expected them to?
With these insights, continuously hone your user interview guide.
- Document
Gather all of your notes and recordings in one centralized location.
Create a spreadsheet or table, and enter in attributes about each of the interviews that you’ve conducted so far.
Then, provide a direct link to the raw interview itself. That will help you synthesise the data at a later point, and enable you to quickly navigate all of the interviews you’ve conducted thus far.
Q: What do you usually want to investigate during a user research?
You cannot get feature feedback without digging deeper into the pain that is kick starting the feedback. If you get feedback and you don’t ask why, why, why, then you won’t actually understand what the root problem is. Everyone will give you different and conflicting feedback, but the root cause pains generally converge into a single problem statement.
Project Management
Q: What project management framework do you use in your company?
None. We’re in charge of coming up with how we want to manage the work.
Q: If your team’s speed is low, what do you usually do to boost their speed up?
Identify the bottleneck. Is it lack of context, lack of skill set, or lack of people? Then, attack the bottleneck.
Q: Do you clash ideas with your engineers? Is it a common thing that a PM will be critically attacked in the technical realm by their engineers?
We collaboratively talk through tradeoffs. I expect my engineers to push back and tell me that there is a better technical solution available. And, my engineers expect me to push back and tell them that their idea cannot be implemented because our customer or our business has a real constraint.
Competitors
Q: Is it important to keep up with competition (since our competitors do it, then we should do it)?
We do not chase competitors. We identify what our customers truly need.
Read this article on value propositions by Mr. Clement, and why it’s dangerous to chase competitors.
Q: When do you know that it is time to find new verticals, not to expand the horizontals?
We ask our customers to make the tradeoff — what do they see as the highest priority? We aggregate the responses to identify how much to invest in new verticals vs. expanding existing capabilities.
Q: Do you ever get caught in tough competition? What do you do to attempt to stay ahead of the competition?
We purposefully find tough competitors and go tackle them. To beat them, we use pilots. Read my presentation on how to use pilots to create product/market fit and stay ahead of competitors.
Q: According to the book “Art of Opportunity”, it is said that today’s business model can no longer depend on being the cheapest offerings. What is your take on that? How do businesses/products stay relevant in today’s world?
Agreed. Cheap doesn’t matter. ROI matters the most. If you provide the most value for your customer (benefits divided by costs), you will always win.
Performance
Product Life Cycle
Q: When do you know that your product has reached the Decline Stage?
Based on user feedback and usage statistics.
Metrics
Q: Retention, Engagement & Conversion. Which metric do you emphasise on the most?
Depends on the product. For example, you can’t possibly retain a borrower when they’re applying for a mortgage, since they either apply or they don’t apply — they don’t come back after the mortgage is done.
Q: In relation to Product-Market Fit. How do you find your product’s North Star?
See this set of articles I wrote for Gainsight: part 1, part 2
Q: Do different sectors require different sets of metrics? If so, what did you use in the past?
Yes, they do. Each vertical has a different need. In real estate, I focused on funnel metrics such as “time to convert a lead into a sale”. In fintech, I focus on engagement metrics such as MAU.
Q: How would you analyse a change in a metric?
See my article here on analyzing metric changes.
Apps Interface
Q: How often do you change your interface? When do you know it is time to change?
I work in B2B, so I do not engage in UX changes unless the underlying functionality itself has changed. I’ve never done a redesign before.
Q: Do we, as PM, need to be adept in user experience?
Yes, you must understand what makes good UX, though you don’t need to design it yourself.
Q: What are the bullet-proof tips you can give in identifying the most pleasant user experience?
Things to do: conduct effective user interviews, shadow your sales team, shadow your customer support team. The general goal is “get the user’s voice into your head” so that you can talk design through “why XYZ decision is good” or “why XYZ decision is bad”. You own the customer’s voice in the room when you work with design and engineering.
A/B Testing
Q: What does an A/B testing mean to your product development? Does it possess a high importance even for small products?
No. I work on B2B products. You cannot A/B test those because businesses are running their processes on you, so you cannot introduce variants. See this presentation on Nuances of B2B Analytics.
What distinguishes great PMs from good PMs
Q: What is your key learning point of being a PM?
Identifying the correct problem to solve is 90% of the complexity. The rest is straightforward.
Q: What was your most difficult trial during your career as a PM (be it personal, professional, or relational)?
Relationships are hard. I’m an introvert and I’m not good at politics, so it’s always awkward for me to talk to someone about performing poorly.
Q: What do you think differentiate great PMs from the good PMs?
See this Quora post on 1% PMs from Ian McAllister. Basically: be T-shaped, be good at everything.
Q: What are some of your suggestions and pro tips on resources to watch/listen/read to be a great (not just a good) PM?
Focus on a specific PM and absorb their mindset through all of their blog posts. Good people to understand — Sachin Rekhi, Casey Winters, Adam Nash, Ken Norton, Andrew Chen, Marty Cagan. Once you absorb their blogs posts, you know how they think, and their voices will speak to you while you tackle product management.
The interview experience with Mr. Clement had definitely opened my eyes to how delicate of an art product management is. Though there are certain framework (in mathematical language — formulas) to certain cases, but it should be balanced with a certain amount of rationality and sensibility. With every other case varies ever so slightly, there is a sizeable amount of qualitative and quantitative consideration we need to take into account until we conclusively make a decision as a product manager.
With a very formulaic background of mine (maths..), there will be a gradual shift of way of thinking when I am carving my career into product management. The questions I have crafted were worded in a more formulaic stature. On the other side, the answers that I had gathered were mostly a balancing act between a “yes” or “no”. If this was illustrated as colours, it was initially black and white, and now it is all a definitive shades of grey.
I would like to thank Mr. Clement for setting aside time to discuss questions with me over on an online meeting. I was very pleased with the many insights I have gathered throughout our interview.
To read more on how I came up with this PM Series, check out my article here.
