Hacker News Reader

"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.

What does PO stand for?

Product owner

Project owner?

Petty Officer

Purchase order

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.

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

Product owner. Not that I could tell you what that means though

> 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.

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."

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.

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.

Yep, the "it" factor matters. If data drove everything we wouldn't need people to make decisions.

"It" factor? What does "it" mean here (silly question i guess)

Edit: the “it factor” is that feeling in your heart that you get when you know you are with the right person ... No, with the right software feature.

One method I can think of off hand is to de-risk new ideas by triangulating from success already in the market. Use the data that other's have collected to launch their successful thing and show how your feature or product is a combination of things already working. I think PMs who can do that have the "it" factor. It's walking the line between going with gut and not having time/resources/energy to get actual data.

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).

> Hint: good PMs won't just base it on gut feelings or anecdotal evidence.

Sure you want some structure, but people often get this wrong.

Intuition is surprisingly important and it's easy to get into some pseudo-scientific approach and call it data-driven (eg. biased questions/scales in surveys are very common).

Ultimately to be approximately right is still better than to be precisely wrong.

The problem with intuition is that it’s often misleading or outright wrong. The only time I’ll trust a PMs intuition is when their background closely matches the target audience.

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.

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.

Yes, very much so. I need a PO who can answer that question, and I judge the competence of a PO based on their ability to do so. I don't care about the requirements or feature list you drew up until you can explain to me what problem you're trying to solve. It's vital both from a product polish standpoint and a personal satisfaction standpoint, to be able to visualize a real person using this thing to solve real-life problems at the end of the process.

I am surprised it's your (PM's) job to decide who should be building something ("why should I build it, and not her").

It depends on the org. Depending on company size, the Product Manger and the Project Manager can be the same person.

"the Product Manger and the Project Manager can be the same person"

Depending on how many typos you have there, definitely! What did you mean?

Sure, but then it's still not the Product Manager doing it.

This is a discussion of what a particular role is in charge of, the fact that a single person might do multiple roles does not define the role under discussion imo.

As an engineer I find it very frustrating when the PM takes that role instead of the EM or the team via consensus.

I read this as: why should it be in product A (which we are working on) and not in product B (which someone else is building)?

On re-reading, you are likely right. Thanks for pointing it out, though it could have been worded slightly better.

>Slack, Outlook in Office 365, Jira, and Zendesk are the goto tools

Add long-form writing in there. One of the most important things is alignment so everyone knows what they're doing and why they're doing it. This helps people become independent, make their own decisions, and take actions.

Upstream emails that align everyone across several functions, skillsets, and abstraction levels prevent many small interactions and ambiguities downstream, effectively leveraging your time.

Explaining the objectives at a high level in terms everyone understands, then going incrementally deeper to tie these objectives to specific actions of the relevant people.

Tying revenue to scalability to spinning up Kubernetes nodes to an open issue to a line in a particular file that should be changed is a journey across abstraction levels.

This is our current state, this is our desired state, this is the gap between the two, and we haven't crossed that gap because X, Y, and Z. This is what we'll do to solve that, cross that gap, and go from our current state to our desired state.

Writing down these things exposes thought processes and rationale. It allows people to chime in at the abstraction level they prefer to augment, correct, poke holes, shed light on blind spots, and question assumptions in these thought processes. It also enables everyone to be on the same wavelength.

The above "tying" thread allows an advisor to comment, a CEO to comment, a designer to comment, a developer to comment, and a domain expert to comment. Each one of them has a place they can "hook" into.

How many conversations/requests/Slack direct messages/phone calls does this prevent?

I replied yesterday to someone asking about what they can do to understand and monitor product usage and drive development[0]. I wrote a bit about this in an "index" reply[1], and wrote about dealing with clients to develop custom machine learning products (mid six-figure projects) in a twitter thread[2].

- [0]: https://news.ycombinator.com/item?id=25270028

- [1]: https://news.ycombinator.com/item?id=25244246

- [2]: https://twitter.com/jugurthahadjar/status/131066829330549965...

>Add long-form writing in there.

This, so much this. I want to scream to the rooftops: I don't care about your slides, invest in good writing.

Ask them the same question: "What whould you ask a product manager in a job interview?"

Andvanced version: "Create and describe some case, puzzle, exam that you whould give your future product manager on the interview"

This will give you a good perspective of how he sees himself as a product and rich soil for open discussions.

OP is not interviewing PMs to hire. He is interviewing them to understand what PMs do.

Your product team can take up to 5 weeks to deliver a simple change like adding a field, the most sr engineers are pushing for a ground up application/architecture rewrite. What would you do?

The role is to align those various parties in the direction of success. Imo, that success is a function of the respective stage of the company. The conversation that goes, why do you believe in this company, what product risks did you take that didn't pan out and why, what can you tell me about our customers, and what are the factors in the growth trajectory of our company, should be a fast filter.

Reality is by the 2-3rd interview, a PM candidate necessarily knows as much about your product or company as a prospective customer and the least technical sales person, and presumably they would buy what you are selling. Get them to sell your product back to you.If you are an enterprise interviewer, you're basically looking for polish and acumen, and if you are a startup I'd recommend looking for self awareness. A mismatch is basically a time bomb, so understand your own business.

The best PMs I have ever met were amazing because part of being that smart is they were strategic about the products they took on. This upstream eye for growth and the ability to be a part of it, which they had consciously developed with experience (and some, mainly elite, education), positioned them for success because growth beats literally everything. Ask what they think the factors in the growth trajectory of your product are.

"How far down the totem pole is the Ops team in the mind of the average product manager when it comes time to decide 'we need a new feature'? How soon are they brought to the table, generally speaking? Compared to other stakeholders, how much of a voice do they have in deciding if a feature is valuable or non-economic?"

Ask them to respond to this comment

> Product Manager is a bullshit job that is wildly overpaid due to managerialism and the tech bubble excess.

[From one Product Manager to another]

Some have called Product Management the “Visionary’s Whipping Post” as role sits internally between the company’s development, accounting, production, and accounting teams who all need someone to blame for their woes. Others have describes the role in terms of shuttle diplomacy between external customer needs and internal corporate objectives. How would you describe or frame the role of Product Manager?

For your own organization, where do you strike the balance between Microsoft's "Promise everything even if you don't have it" and Apple's "Say Nothing until it's available in the store," promotional strategies and how does your position relate to your unique line of products, industry and customers?

Are you currently in a product expansion phase or option/feature expansion phase?

Are you positioning yourself for a new market segment or extending your reach into the existing customer base?

What products or industries do you admire or see as well managed?

How do would you tackle two conflicting views from two different internal customers.

How would you tackle a situation where a customer wants something completely diffrrent, which you are made aware of during UAT.

What is a customer journey?

What do yoh thing of working agile?

Hiw do you start off after being hired onto a project and broader system ecosystem you have never been part of before.

I would want to treat it as a customer interview, asking them about specific situations where they had to negotiate customer needs, how they decide what features are proper and what are extraneous, and how they get buy-in from the team to implement [desired, necessary, relevant] stuff.

Have they ever worked on a product before it had achieved a sense of product-market-fit, and if so, how did they help it get there?

When they did not feel content in their role, what was lacking? And when they did feel content in their role, what were the great elements that set it a cut above the rest?

Dependant partly on stage of company and stage of product, however... Consider asking how many products they have successfully canned. Not launched. Killed. When you’re a PM launching products everyone from the investors and CEO down is your friend. When the time comes to kill a product, nobody want to know. Product Management is the job of managing the product through the product lifecycle. Concept, development, launch, iterations and enhancement, maturity, and yes... eventual migration, retirement, and burial. If you are at a large and mature company a PM may be required to retire more products than he launches. Both ends of the product lifecycle are important.

How will you establish product quality baselines? Are you willing to repeatedly reject contributions from developers who violate those quality definitions?

If a product manager has any muscle they not only have to project product goals but they must also defend the product from internal incompetence, which is far more challenging than it should be.

Ask them to walk you through a successful and a failed initiative/project they were leading.

This sounds like a senior level Business Systems Analyst role.

A former employer of mine employed people with that title. However they were far, far removed from product. They were essentially HR or bookkeepers. I never really figured out what they did but it had nothing to do with our products.

PM is one of those titles (analyst too, now that I think about it) is one of those titles that means vaguely the same thing at a plurality of orgs, but wildly different at the edges.

Traditionally Business Analysts (BAs) had the same role as Product Managers, but were also tasked with testing the product to ensure the product met specifications. This was common in the Systems Integration type consulting firms (Accenture, IBMGS,...) and also in Financial Services.

With Product Managers, I have noted they do not typically have the testing role.

What did you build? How fast? Then dive deep on the technical and user stuff to test if HE(!) was really the one who drove and understood it.

"What do product managers actually do?"

Don't hire a project manager.

you only need to ask one question. tell me about the conjoined triangles of success.

how do you prioritize epics?

Ask HN: I am interviewing product managers – questions to ask?