Ask HN: I am interviewing product managers – questions to ask?
40 sharmi 2 days 33
Hi all! I’m connecting with product managers to understand more about the space. I make 30-60 minute interviews as part of some discovery research I am doing for a side project. I did an interview of a product manager in an enterprise and learnt quite a lot. Here are a few truths and titbits from it. * Product management is a high velocity communication game. You are constantly working with customers, customer success managers, sales engineers, CXOs, marketing team, sales people etc. * You can easily have a 1000 open tickets. You need to stay on top of which are in progress and what are the priorities. * The customer may communicate with multiple people in your organization but ultimately it is your responsibility to ensure that their priorities are taken into consideration and addressed. * Slack, Outlook in Office 365, Jira, and Zendesk are the goto tools
Here is the interview https://prodjeeves.com/transitioning-into-product-owner-role-interview/
I want to hear what the community says. What would you like to hear?
What would you like to ask other product managers? If you have some questions, let me know.
Otoh, I am also trying to understand the space. If you can spend sometime for an interview, please let me know. I would be glad to.
PragmaticPulp 28 mins It's important to understand their prior roles and responsibility in detail at the start of the interview. The Product Manager title can mean very different things depending on the company.
At some companies, Product Manager is a high responsibility, high accountability position that drives the roadmap. They are responsible for deciding what gets built and ensuring that it's both feasible and will generate the highest ROI. They are accountable for moving the product forward and coordinating across departments to make sure the right work is getting done.
On the other end of the spectrum, some companies treat the Product Manager like a communication switchboard or a Jira ticket manager. These positions don't have much power, don't make major decisions, and mostly follow orders from someone else. They spend their days sifting through Slack channels, Jira tickets, and nagging developers for updated estimates.
The trick is to get the person to elaborate on their experience before you tell them what type of Product Manager you're looking for. The challenge is that if you describe the position too much up front, most candidates will simply adjust or embellish their experience to match what they think you want to hear. If you instead ask them detailed questions about what they did at previous companies, you'll get a more unbiased view of their prior experience.
Here is the interview https://prodjeeves.com/transitioning-into-product-owner-role...
Be careful about using Product Manager and Product Owner interchangeably. They mean different things at different companies.
woeirua 1 hr How do you decide which features to prioritize and which to pass on? You'll probably get a wide range of responses to that question, but you'll also probably get a good feeling for who is a competent PM and who is probably not. Hint: good PMs won't just base it on gut feelings or anecdotal evidence.
How do you balance priorities that you're hearing from customers with priorities that you're hearing from sales? PMs often find themselves in between sales, customers and engineering, and balancing those conflicting priorities is tough.
How do you convince engineers to take on hard tasks? A lot of times PMs come up with great ideas but engineers will balk at actually implementing them because "it's too hard."
lemax 1 hr PM is all about impact and effort. Priority goes to the high impact low effort stuff first, and low impact high effort generally goes the way of the bin. Strategic alignment is also import whenever priority is evaluated.
Hint: good PMs won't just base it on gut feelings or anecdotal evidence.
Sure, good PMs tend to collect great evidence from customer interviews, usage data etc. However, getting too hung up on data is sometimes a trap. I've seen some great ideas from teams - some even fully implemented - shot down by other PMs because there was no research.
What if you don't have the data, but the idea is something you know will generate massive value? This is the exact issue startup ideas face... no one knows if an idea is valuable until it's tested and a product hits the market. But early stage founders and great product managers might just know something is the right idea yet have zero data to back it.
Any product a product manager has ever worked on was initially created from nothing. Data wasn't generated until people took a risk and delivered.
ntsplnkv2 48 mins Yep, the "it" factor matters. If data drove everything we wouldn't need people to make decisions.
necovek 1 hr Oh wow, that was sneaky.
In my experience, all sides do come up with "great ideas" all the time, but it is their job to estimate effort and ROI before starting on any one idea.
Sure, there are plenty of engineers who are unable to come up with an incremental approach for a "great idea", but there are as many PMs who are unable to understand the incremental approach and would rather have it all or nothing.
Every one of them needs to experience true incremental delivery of value to really buy into it.
foobaw 1 hr Sometimes, especially in B2B Saas, it's as simple as looking at potential short-term and long-term revenue (building something that is more sellable).
codingdave 3 hrs "Product Manager" is a title that means different things to different companies, ranging from mini-CEO to Jira-monkey, and everywhere in between. You are absolutely correct to be talking to many different people to understand this slice of the industry.
I'd ask them what PMs do in their organization, what POs do, and what the difference is in their mind. Ask what level of detail they operate at, what they delegate to others, and what types of things are expected to be passed up to their boss.
You also might get interesting perspectives if you explore outside the software industry. Product managers exist in all kinds of companies, with the same overall goal to understand the market and produce the correct product under the correct business model. But the day-to-day of a software PM is vastly different than the day-to-day of a PM that produces retail goods, for example.
swordsmith 1 hr
You also might get interesting perspectives if you explore outside the software industry.
Second this. I'd think PM at Google work differently than PM in Lockheed.
hollerith 2 hrs What does PO stand for?
xnyan 2 hrs To expand on the other answers, generally the project owner deals with “why” and the manager with “what.” In slightly more vulgar terms, it’s like the difference between an owner of a McDonald’s and a manager of a McDonald’s.
TuringNYC 1 hr Product Owner, which is a Scrum role but often a job title for an individual tasked with that Scrum role.
https://www.scrum.org/resources/what-is-a-product-owner
comradesmith 1 hr Product owner. Not that I could tell you what that means though
grapehut 2 hrs Petty Officer
airstrike 18 mins Purchase order
codeyperson 2 hrs Product owner
Lucasoato 2 hrs Project owner?
ambivalents 3 hrs As a PM I sometimes get asked a question, typically by Engineering, and I think the ability to answer this question well is an embodiment of the role. It can take different forms but it's basically: "Why?" Why build X over Y? Why this feature, this way, instead of another way? Why now, instead of later? Why should I build it, and not her?
Answering this well requires a) ability to communicate convincingly, b) evidence, typically through user data, research, competitor analysis, etc., c) authority in your space, d) ability to translate business requirements into technical speak, and vice versa, and e) respect from the team you're working with.
necovek 1 hr I am surprised it's your (PM's) job to decide who should be building something ("why should I build it, and not her").
nitrogen 9 mins As an engineer I find it very frustrating when the PM takes that role instead of the EM or the team via consensus.