[HN Gopher] More product, fewer product managers
___________________________________________________________________
More product, fewer product managers
Author : SigKill9
Score : 346 points
Date : 2023-12-15 09:53 UTC (2 days ago)
(HTM) web link (kitemaker.co)
(TXT) w3m dump (kitemaker.co)
| burlistic wrote:
| Some great advice. The best PM I have worked with are visionaries
| and catalysts. They are great at exploring opportunities areas
| and bringing the team along.
| wenc wrote:
| I've worked with some bad PMs and some great PMs.
|
| The great PMs generally follow the advice here:
|
| https://staysaasy.com/product/2023/03/12/pm-engineers-dont-h...
| freitzkriesler2 wrote:
| Ha, what's the difference between a project manager and a product
| manager?
|
| Two letters and about $50k-100k.
|
| I've done both and it ends up being project management with a few
| extra steps. The extra steps being, "focusing on the market,
| solving customer problems, and being strategic.
|
| You'll hear the classic adage of, " well project managers deal
| with the how to execute and product managers deal with the what
| to execute" but the reality is over most orgs Ive been in,
| they're really just project managers who also have (something) of
| strategic vision aligned with the marketplace.
|
| Don't tell product managers this because they'll get butt hurt
| and telling you how they aren't.
| rgrieselhuber wrote:
| As someone who has hired both, I really don't see it that way.
| As another commenter mentioned, the difference is the
| capability for understanding the problem, being able to
| envision the right solution, and then manage all the moving
| pieces to make it a reality. The best ones are similar to
| startup founders.
| freitzkriesler2 wrote:
| > see problem
|
| > envision right solution
|
| > Manage all of the moving parts
|
| Congrats you literally just described project management with
| extra steps.
| hnarayanan wrote:
| Thank you
| airocker wrote:
| Why not also be the developer if you can do that much already?
| Arcanum-XIII wrote:
| Because if you're working on a project big enough, you don't
| have the time to be a good dev or a good manager. As a
| developer I wanted time to think about how best to solve the
| problem I was facing, not writing documents, refining the big
| picture, get a buy in from the stakeholders, giving reports,
| making sure the other parts of the project kept getting along
| and so on. It was important for me to be kept in the loop,
| not doing it on top of my job. As a product manager, it's the
| other way: I have a product that need to be there and so I'm
| trying to find a good compromise between the stakeholders
| idea, what would really work and what can be done with the
| ressources I have. That means sometimes I recommend to not
| start anything, but to buy a solution (then I need to
| validate that it will work as intended, that the budget and
| contract are ok and so on)
|
| It's another job altogether. That doesn't mean I won't follow
| the technological trends, educate myself or refuse to program
| anything. I wrote some postman script to validate what's
| happening with our api, know the infra behind it, and can
| generally point people in the right direction. I have to know
| the product inside out to make educated answers when
| something goes wrong or if a decision is required.
|
| It's often a people job. And that's something I try to share
| with the teams I work for.
| airocker wrote:
| We are not talking about a good manager here. We are
| talking about the one who can program manage to the level
| of lowest jira issues.
| naijaboiler wrote:
| That's not product management. That's an under-qualified
| person misunderstanding their role. Product management is
| mostly a people job, understanding internal stakeholders,
| understanding customer, understanding the market,
| understanding the solution options, formulating and
| understanding strategy for the product, coordinating
| product marketing and documentation for the product.
|
| If someone can do all that well, there's simply no time
| to micro manage jira tickets
| airocker wrote:
| Even if they have the time, my rule is that nobody who
| does not understand the complexity of the solution (not
| the problem or the what) should be allowed anything more
| than watch rights in jira and standups. I would love to
| hear one non coding product manager who does not run jira
| in their org of more than 100 people.
|
| The problem is that it is hard to be a product manger and
| own those tough customer metrics. It is easy to do jira
| and get credited for engineering work.
| ghaff wrote:
| When I was a product manager for large computer systems
| back in the dark ages, I can pretty much guarantee you that
| none of the engineers wanted to spend probably the majority
| of their days on the phone with sales reps, in customer
| meetings, providing updates to management and other groups
| involved with product launches, writing technical sales
| docs, and reviewing marketing materials, etc. Many
| engineers liked sitting in on a customer meeting now and
| then as a change of pace but they (properly) wanted to
| spend the bulk of their time focused on actual engineering.
| Moto7451 wrote:
| This matches my experience over 15 years and four companies.
| This is not a scientific study but I can at least concur with
| your experience. There are clearly orgs that don't work this
| way, but I find that it's very common when chatting with my PM
| colleagues. The exceptional cases have been project managers
| for projects that involve wide scope, multiple products, or
| some other factor.
|
| I've also found that in addition to the Project Manager turned
| Product Manager, there are plenty of Product Managers forced to
| be Project Managers and it goes poorly unless a Development
| Manager is willing to carry that.
|
| The ultimate problem is that Project Management doesn't go away
| just because a company eliminates the role. The same is true
| for Product Management. If you're ok with your developers or
| someone else doing the work, and it is fruitful, great. For
| about a decade I tried as hard as I could to get one of the
| limited Product Managers for the products I worked on to very
| little avail. As a result I had to guess about price increases
| and other functions that I, someone with 70% of a CS degree and
| some extension courses in business topics, have to learn on the
| fly each time I face the challenge. I was successful but I am
| sure a real Product Manager would have done a better job.
|
| The companies I've worked for typically have a cynical view of
| dedicated Project Managers but I appreciate that this is a
| specific skill for similar reasons to my Development Manager
| forced to be a Product Manager experience.
| pnathan wrote:
| I have very rarely encountered a PM(any title) who lucidly
| communicated their value-add to the company. It is certain
| that, e.g., someone needs to assess the pricing of a product
| and how to position it in the market. But it's unclear that
| the vast majority of people I've worked with are performing
| that task - they are, to all appearances managing projects
| and doing secretarial coordination work (ticket munging),
| something experienced devs and managers can do
| straightforwardly up to a certain point.
|
| I think its one of those roles that you don't need until
| product (project) scope is a certain point, but it's been
| glommed onto smaller companies as they mimic the big-corp
| designs. So it never quite works for those small shops. They
| really just need a Product Person, singular, who drives the
| thing forward, IMO.
| anon23432343 wrote:
| I had project were we hade not difference between po, pm and
| scrum master. No difference at all on what they did.
| ath3nd wrote:
| All those jobs do look the same because they are all bullshit
| jobs which infantile developers assuming they can't do and
| decide anything for themselves but write code on command.
| aurareturn wrote:
| Project managers don't strategize or lead a vision of what the
| product should look like.
|
| It sounds like your strength is more in project management than
| product management so perhaps that's why the organizations tend
| to place you in that role?
| freitzkriesler2 wrote:
| If it wasn't clear, i'm a product manager that started in
| project management.
|
| The real problem is product management is hot, project
| management is old.
|
| I've been around the block enough times at different
| companies to form that opinion and thats OK. Product
| management is consistently project management with extra
| steps. Those steps being business and market analysis to
| solve customer problems.
|
| It seems businesses are starting to realize that.
| koliber wrote:
| You shared an interesting perspective, but ruined the delivery
| with the last line.
| Hippocrates wrote:
| I think the problem with these two roles is actually the
| confusion about what each is. Usually the issue is a "product"
| manager not doing the ideating, not doing research, not enough
| advocating about what user needs or what the product should be.
| Instead they do too much "project" management which amounts to
| gantt charts, check-ins, and nagging about status.
|
| I have seen that in all sizes and maturities of company that
| people view these roles as interchangeable and they are not.
| bbarn wrote:
| As a developer, and a development manager, the best product
| managers I've worked with rarely got involved in the "how". Sure,
| they may generate epic-level tickets in your back log, but lower
| than that, they trust you and the project people to get things
| done.
|
| Problem is, the org needs to support that, and in most companies,
| the work that gets the most attention isn't visionary or growth
| focused, it's whatever is making the loudest noise. Often that is
| in direct conflict with a product owner/manager's desires.
| antupis wrote:
| Or they are super into weeds polishing stuff in code level but
| it is never between those two approaches. Also very good pm can
| be kinda shackled if there is lots of mediocre pms running
| around.
| anon23432343 wrote:
| On the other side I have worked with PM/POs who have no clue
| and the developers are just telling them: "Oh this is super
| complicated you would not understand" or "This will take a long
| time to implement" and its a small feature.
|
| There must be a balance. There must be some basic understanding
| by the PM/POs. They cant be the person that barley can use a
| computer.
| Wurdan wrote:
| It also helps to be able to understand the tech enough to
| know if a certain approach is going to impact other
| initiatives which are further down the roadmap. One of my
| favourite questions I've been asked by a PM is "Will any of
| this work become easier to do if we change the order of these
| work items?"
| radiator wrote:
| I would have thought every manager asks such questions
| either to himself or to the team quite often.
| Wurdan wrote:
| Not in my experience - juggling priorities is usually
| difficult enough when you're just trying to manage the
| C-suite's favourite ideas, or feature requests from the
| highest revenue customer, etc. Factoring in synergistic
| engineering efforts is out of reach for a lot of PMs that
| I've worked with.
| gabrieledarrigo wrote:
| > As a developer, and a development manager, the best product
| managers I've worked with rarely got involved in the "how".
|
| My experience is completely the opposite. PMs that don't
| understand the how, that is, they don't know how their product
| works, are the worst.
|
| Best PMs that I worked with had a technical background.
| nip wrote:
| I believe OP meant << implementation >> with << how >>.
|
| You want a PM that knows the product (really) well and brings
| new work to the developers in the form of well documented
| problems, not solutions.
|
| You don't want your PM to get involved in the technical
| details.
| phillipcarter wrote:
| Careful here!
|
| > not solutions
|
| Often yes, solutions. When you're still in the "what are we
| building" phase you want a good PM deeply involved in the
| process. I think you may have implied that, but solution
| creation happens before code gets written.
|
| You also sometimes want a PM to get involved in technical
| tradeoffs when they impact the user experience. I've found
| that this happens more often with a technical product (API
| capability or SDK interface) than a UI screen, but it comes
| up. When your PM is the expert in your userbase and how
| they expect to use something, they need to be involved a
| lot.
| nip wrote:
| Agree on all counts!
| aurareturn wrote:
| >Best PMs that I worked with had a technical background.
|
| Best PMs I worked with just figured out what users wanted and
| organized the team to build it through good communication.
| That's it.
|
| Sometimes the technical PMs can be an issue because they care
| too much about the how and not enough of the why and what.
|
| If your product is selling devtools to developers, then yes,
| it helps to have a technical PM. Case by case.
| mewpmewp2 wrote:
| This would also depend really on how technical the product
| is, but if a product is technical and PMs don't have enough
| technical background they won't be able to understand
| nuance of what customers wanted and what is actually
| possible to do.
| havkom wrote:
| Best PMs know both the what, why and how and tries to bridge
| all that.
|
| It may include knowing technical weaknesses and strengths in
| the energineering teams abilities and their plattforms
| abilities and weighing that in for planning and priorities.
| In reality development in product that are over the teams
| abilities may lead to a real mess.
| PaulRobinson wrote:
| Product managers own the "Why?" and the "What?". Project
| managers own the "When?". Engineering managers own the "Who?".
| Engineers own the "How?".
|
| When people try treading on other patches, it always ends in
| disaster. That works both ways: engineers are lousy at the
| "Why?" and the "What?" because they think too much in terms of
| "How?"; and yes, product managers need to step away from the
| "How?" unless it's to clarify the "What?" or the "Why?".
| hehhehaha wrote:
| Hard disagree, cross role context is critical for intuition
| on getting stuff done. A designer with no insight on
| engineering will create shitty designs that take forever to
| build, create patterns that arent reusable, etc. Engineers
| with no insight on product will not be able to balance the
| debt/product ratio properly. You can say that all of this
| gets sorted out with proper communication, but knowledge and
| intuition will always beat leaky bucket cross role comms
| PaulRobinson wrote:
| "Having context" isn't the same as "having ownership or
| accountability".
|
| Of course there needs to be communication and context, but
| when engineers start to try and direct the "what" or the
| "why", it becomes as absurd as PMs trying to dictate the
| "how".
| mewpmewp2 wrote:
| If this is the ownership and Engineers ask "How?", there's no
| one overall to connect the dots. For instance with this
| ownership dynamic product managers will come up with what and
| why, and engineers will come up with "how", but no one
| validates whether the whole thing is worth it considering the
| technical complexities involved. So scenarios where PMs come
| up with this and Engineers just ask "How?" there will be
| initiatives that take a lot of resources, while not giving
| enough in return.
|
| There's no one to balance the complexity of building this vs
| the gains achieved.
|
| I think best engineers would be people who also use the
| product and can give their own insights on this, as well as
| best PMs are someone who have good knowledge of the technical
| background and context.
| PaulRobinson wrote:
| The customer voice - represented by product managers - help
| join the dots.
|
| It's a team sport, there needs to be communication, but
| there also needs to be clear areas of ownership.
| andromeduck wrote:
| That only works when the people under them are competent and
| business interests are reasonably aligned with reward
| structure.
| ChilledTonic wrote:
| Barely relevant to the article, but this new trend of AI art as
| the main image of blog articles drives me absolutely crazy - if
| you don't have a clear main image in mind when you wrote the
| article, don't waste my bandwidth downloading a computers pipe
| dream.
|
| I'm all for AI art, it's an incredibly valuable tool - but if
| your using an AI piece as the only image on the page, it should
| be for a damn good reason, not just space filler. Especially when
| you can't even curate the image generated well enough to have
| every person in the image have the correct number of fingers.
| mr90210 wrote:
| That's a fair take.
| jackblemming wrote:
| Agreed, the issue isn't AI, it's poor taste. Nobody wants to
| see what looks like an uncanny valley picture of all large
| ethnic groups smiling weirdly in a circle at each other. This
| bizarre soulless corpo art trend started well before AI
| generation rocketed in popularity.
| signaru wrote:
| It's not just AI art. Memes and unrelated stock image have also
| been used. It might be due to some SEO belief.
| 0x1ceb00da wrote:
| God I hate memes on medium pages.
| davidthewatson wrote:
| Me too, especially when the underlying root cause is siloed
| communication arising from founder burnout or sheer
| disinterest not the supply of product management thinking.
| It's as if you needed the subtractive design thinking of
| the two Bobs in office space and what you got instead was
| aimless growth of product like cancer.
| Nextgrid wrote:
| "Medium" itself is generally a good heuristic for trash
| that isn't worth the time reading.
| suslik wrote:
| Truly. I have it blocked in my kagi search together with
| pinterest, w3schools and other similar things like that.
| Can't say I miss it.
| politelemon wrote:
| Even before this, the trend of hero image which takes up most
| of the space above the fold, has been insufferable. This is
| just a continuation of that, which hasn't gone away either.
|
| Here's an article on selinux, bit first an image of a leaf.
| _giorgio_ wrote:
| The most sad part is imagining the prompt that he used, and how
| hard he tried to add black, whites, women... respecting the
| politically correct numbers.
| SigKill9 wrote:
| I spent less than 5 seconds in the prompt. Dall-e is quite
| politically correct, I guess :)
| bakugo wrote:
| There's no need to do this, because DALL-E already
| automatically injects those things into your prompts behind
| the scenes.
| rpastuszak wrote:
| What would be so sad about it?
| SushiHippie wrote:
| https://www.reddit.com/r/ChatGPT/comments/1717jqk/chatgpt_da.
| ..
|
| Yeah DALLE-3 has this in the system prompt.
|
| > Diversify depictions of ALL images with people to include
| DESCENT and GENDER for EACH person using direct terms. Adjust
| only human descriptions.
|
| > EXPLICITLY specify these attributes, not abstractly
| reference them. The attributes should be specified in a
| minimal way and should directly describe their physical form.
|
| > Your choices should be grounded in reality. For example,
| all of a given OCCUPATION should not be the same gender or
| race. Additionally, focus on creating diverse, inclusive, and
| exploratory scenes via the properties you choose during
| rewrites. Make choices that may be insightful or unique
| sometimes.
|
| > Use "various" or "diverse" ONLY IF the description refers
| to groups of more than 3 people. Do not change the number of
| people requested in the original description.
|
| > Don't alter memes, fictional character origins, or unseen
| people. Maintain the original prompt's intent and prioritize
| quality.
|
| > Do not create any imagery that would be offensive.
|
| > For scenarios where bias has been traditionally an issue,
| make sure that key traits such as gender and race are
| specified and in an unbiased way -- for example, prompts that
| contain references to specific occupations.
| thfuran wrote:
| >Don't alter memes, fictional character origins, or unseen
| people.
|
| I wonder what not telling it to avoid altering unseen
| people does.
| daemonologist wrote:
| That is quite interesting. Maybe they're trying to keep
| it from manifesting additional people - if the user
| requests a scene where logically more people are present
| than visible (maybe it's first-person, or the view from
| the front row of a theater) and ChatGPT crafts a prompt
| which describes the physical characteristics of the
| unseen people, Dall-e will probably include them in the
| image it generates.
| koliber wrote:
| I often do have a clear image in my mind for an article. I can
| not draw it and I don't have the budget to hire someone to do
| it.
|
| The image is meant to convey a feeling. It is meant to make an
| abstract concept from the article a little more tangible.
|
| In the past, I'd search for images on the net that I could use
| to accomplish that. Now I can craft them with DALL-E, and they
| are usually much better.
|
| This image should complement the article. Just like the text of
| the article is meant to convey some information, feeling, or
| concept, the image should do a bit of that as well.
| madeofpalk wrote:
| I don't know the exact word for the style, but this article
| is pretty egregious for the overly stylised "AI art". This
| just looks cheap, obviously "AI", and is pretty distracting
| for me. I don't know if that was the intention or not, but
| it's a detractor for me.
| itronitron wrote:
| It looks like an ad for a shitty mobile game.
| koliber wrote:
| Quality of writing and quality of imagery varies a lot.
| It's hard to do.
| wruza wrote:
| Is it any worse than a photo model's pipe dream about what they
| are shooting? People on stock photos rarely know anything about
| the profession or the situation they represent besides basic
| ideas like looking smart, busy or chatty. They just have to
| look good at the same time.
| layer8 wrote:
| Blog articles you could take seriously didn't use to have
| stock photos. It may not be worse, but that doesn't mean it's
| not bad.
| layer8 wrote:
| I don't mind AI art except that it's so often cringe. Half of
| the time I wonder if it's meant tongue-in-cheek, or if the
| author really feels it's an authentic fit to the article.
| layer8 wrote:
| > the correct number of fingers
|
| I like how one of the tablets seems to devolve into a paper
| notepad at the bottom, and how the notebook display on the
| right seems to be transparent and twisted.
| wimp wrote:
| I think my brain automatically blocks out stock photos, because
| I didn't even notice this post had an image.
|
| But there's something funny about this. The blog template
| requires an image bucket, so mindlessly fill it with something,
| right? Too hard, so find a bland stock photo. Too hard, so
| _purposefully_ generate a bland stock photo. Uninspired
| tasteless AI garbage is going to overtake everything in short
| order.
| drewcoo wrote:
| > the ideal time to hire a PM at a startup is when the founders
| can no longer be involved in all the important product decisions
|
| No, that's when the founders need to hire actual managers. Their
| staff is already used to involvement in product decisions, right?
|
| Then there are a bunch of traits and activities of PMs listed. I
| would think that the time to hire a PM is when the founders can't
| do that list of things, if that's what PMs do.
|
| > it's easy to overestimate how many an organization needs
|
| Why? The article avoids addressing that, telling us when to hire
| and how to right-size, but doesn't bother defining the problem
| being solved.
|
| My experience is that the more devs there are per PM, the more
| the PMs start thinking they're "in charge of" the devs and then
| no one's happy. I'd like to see more of a "PMs as customer
| research consultants" model instead - contribute something that
| the devs don't have time to do.
| janpio wrote:
| > but doesn't bother defining the problem being solved.
|
| An experienced product person could maybe have helped with that
| *scnr
| buro9 wrote:
| I think in ratios.
|
| How many frontend engineers to backend?
|
| How many engineering managers to ICs?
|
| How many technical writers to (all) engineers?
|
| How many product managers to (all) engineers?
|
| And I try and keep the ratios finely tuned to have the greatest
| impact but the least meddling, the least micromanagement.
|
| What the numbers for these ratios are is likely specific to your
| organisation, but if you detect meddling or too much of the "how"
| not coming from the engineers themselves, change the ratios,
| increase engineers per people or product manager, make it so that
| they cannot do this and instead have to prioritise what they get
| involved in, to step back from the micro, and to cede autonomy on
| how back to the engineers.
| phendrenad2 wrote:
| This is the only sand way to go. It's surprising how many
| places just don't have PMs, or have far too many PMs (also
| applies to QA, junior engineers, senior engineers, architects,
| HR personnel, Vice Presidents, salespeople, etc.)
| PaulRobinson wrote:
| When I was a software engineer, I used to think I was the
| smartest person in the room, and derided the work of product
| managers, delivery managers and to some extent engineering
| managers. I've had experience of engineering roles up to
| Principal and Hands-on CTO and felt that we didn't need the non-
| engineering backgrounds at all.
|
| Today, I find myself in a senior TPM role for a FAANG who also
| has "product manager" in his customer-facing job role.
|
| I cringe at my behaviour 15 years ago. I shake my head as a I
| hear software engineers using the same arguments I did. "We know
| how to do product management, you're just slowing us down".
|
| In recent years, on a few internal projects I step back and watch
| projects with no product or project management resource - just
| engineers - and the same pattern emerges over and over again: no
| clear customer-facing objectives, not enough time spent listening
| to customers, not enough work in the ramp up to design, not
| enough work in figuring out the long-term operational factors of
| owning a product, poor customer communication (no, they'd don't
| understand your technical documents, sorry, and they've told you
| that, and you don't know what to do about it, but huh, isn't this
| tricky?), and more often than not, misaligned internal objectives
| and politics meaning the product has "camps", driven by
| individual preferences and career/promotion objectives.
|
| It's a mess. Every time.
|
| You might not need product managers, but you need product
| management, and most engineers are atrocious at it. They want to
| focus on the technical work and are not prepared to commit to the
| work that comes with product management. It's often wise to just
| hire product managers.
|
| You might not need project managers, but you need project
| management, and engineers are often poor at it. You probably
| should have project managers. Product managers often have better
| organisational skills - and the attuned level of empathy needed
| to listen to all stakeholders which is needed in project
| management - to be able to do project management too.
|
| If you're still not convinced look at OSS. Most of it is only
| accessibly to other engineers, until one of two things happen: a
| project starts to ape product design decisions made by commercial
| projects, which has happened with a lot of office and graphics
| programs; or, somebody with real product management expertise
| gets involved and is able to influence the project.
|
| I know many people will disagree. They'll insist they know
| better. I expect downvotes because some people will feel
| affronted.
|
| I know this, because 15 years ago I felt the same. I was wrong.
| You're wrong if you feel that way too, and you'll realise it over
| time, particularly if you're asked to do it for a while. Product
| management is a real skill.
|
| And yes, most teams could do it better. And project management
| skills - particularly agile skills - are awful in the industry.
| But please, stop thinking the answer is more engineers.
| maccard wrote:
| > But please, stop thinking the answer is more engineers.
|
| The answer isn't more PM's either, though. In my experience
| when people are struggling, the default answer is "we need more
| X", be it engineers, PM's, money. It's very rare to have a
| group that looks at that and says "we need to do better with
| what we have" _and is able to do so_.
|
| A good PM will make sure that everything your product team is
| working on is the correct thing to work on, which is so much
| more efficient than hiring 2 more engineers to work on those
| things. A bad PM can come in many different ways, (just like a
| bad engineer - we've all worked with the Arcitecture Astronaut
| for example).
| potamic wrote:
| The article is actually making a case for fewer PMs, not to do
| away with PMs altogether. In startups, founders tend to do PM
| because they bring the vision for what to build. Additional PM
| hires in such environments aren't likely to add much value.
| Even in large enterprises, most product decisions are really
| taken by a handful of very senior roles. Most of the PM org is
| there primarily to ensure fulfillment of whatever decisions are
| taken. They get reduced to a more of a bureaucratic function,
| which is where most people's frustration arises.
|
| Nobody likes to have a stakeholder with no power to make
| decisions. A product manager who cannot tell you what comes a
| year down the line. A project manager who cannot change
| processes to improve efficiency. An engineering manager who
| cannot create opportunities for their team. Or a tech lead who
| cannot prioritise tech debt. You cannot avoid bureaucracy in
| large organisations, but you can reduce the surface. There's a
| case to be made to consolidate such bureaucratic functions
| under a single role for a team. But in smaller organisations
| and startups, it can perhaps be done away with entirely too.
| janpio wrote:
| Thank you. I fully agree with every word you wrote.
| tmarice wrote:
| > But please, stop thinking the answer is more engineers.
|
| The answer is to hire more product-minded engineers.
| cateye wrote:
| This article and many people attempting to analyze this topic
| (and many others) are missing a key element: "incentives"!
|
| Many developers are more passionate about technology itself -
| coding, solving complex technical problems, and creating
| efficient solutions. Their formal rewards (like promotions,
| bonuses, and recognition) are often tied to technical
| achievements. If a developer spends 40 hours on customer
| research, this effort might not be as formally recognized or
| rewarded as much as a technical achievement like developing a new
| authentication solution that benefits the entire team.
|
| Shifting this dynamic is not just about encouraging developers to
| spend more time on product management. It requires a systemic
| change in how organizations value and reward.
|
| Changing the incentive structure to be more user-centric and less
| technically focused would significantly impact middle and upper
| management roles. A shift would challenge the very foundations of
| their roles and responsibilities, potentially leading to a loss
| of control and influence.
|
| It's likely that such changes would face subtle yet strong
| resistance from middle and upper management. These individuals
| often have significant political power within an organization and
| a vested interest.
| SigKill9 wrote:
| Thanks for the comment. And I completely agree. Incentives
| shapes so much of how people work. I tried to capture that in
| the 3rd bullet, but your comment is more on-point :)
| atoav wrote:
| This isn't that hard. Just have your developers train people
| with your software. In every craft you learn the moment the
| rubber hits the road. A film director can watch the film in the
| editing room a thousand times, but the one first time watching
| it with a real audience will teach them more than those 1000
| hours together. A carpenter can work away on a piece of
| furniture merrily all week long and be happy with themselves,
| but the moment of truth comes when the furniture is placed into
| the customers room. The same is true for software. If you want
| your software engineers to care about users they have to get
| first hand feedback what works and what sucks, preferably with
| their own eyes.
|
| Every software engineer worth their salt has a certain degree
| of pride about doing things well. If this only ever is about
| the code, the commit history or other abstract concepts, but
| never about how well it can be used by the actual people it was
| made for, then how would they even start caring?
| vwolf wrote:
| I can attest to that. I had worked on a product for a couple
| of years and received feedback from our support team, but
| never seen how the product was used in real life. One time,
| we had a specific bug that the customers were complaining
| about, and no matter how they described it, we couldn't
| figure out what the problem was. That was until I went to one
| of the customer sites and saw how the users were interacting
| with the product.
|
| When they tried to demonstrate the bug, it was immediately
| clear to me what the issue was. That was the first time I
| really grasped the difference in how we approach software
| products. It also helped me see how the product could improve
| their job by watching how the process was in real life. Gave
| me a lot of ideas on how to make their job easier by using
| the product.
| fl7305 wrote:
| Writing GUI applications, there's nothing as valuable as
| standing behind a user who tries to do something for the
| first time with my application.
|
| Just seeing the moments of hesitation, how the mouse is
| moved while searching in menus, etc gives me a lot of
| information.
| wruza wrote:
| Watching what and how they do after a month is as
| valuable. User interfaces have two sides in this regard:
| initial experience and boring repetition experience. You
| can optimize for the former, the latter or both.
| fl7305 wrote:
| Good point. My experience is also that most users don't
| learn many of the neat features I have built in to speed
| up their work.
|
| Even if I show them a couple of times, it is often
| quickly forgotten.
| rudasn wrote:
| > That was the first time I really grasped the difference
| in how we approach software products.
|
| For me as well. I've started my "career" this way, building
| something very specific for a client (family member) whilst
| being on prem and having constant and direct feedback, so
| that's how it was done I thought.
|
| Almost twenty years later, having worked different roles
| with teams in office and remotely, I have to remind myself,
| and others around me, that we are building something to be
| used by real people with real problems and my/your software
| must not be one of them.
| quickthrower2 wrote:
| "Incentives" if you do this you better make it pay so I never
| have to leave. If I have to leave to get a payrise then I am
| getting on the Omega Star team and slowing down their ISO
| timestamp roll out to get GraphQL on my CV, so I can hit
| levels.io and get that extra $100k TC. /s but Poes law
| applies.
| atoav wrote:
| I don't think your company is worse off if you get rid of
| those people by giving them a taste of the real world.
| quickthrower2 wrote:
| No but "those people" is all people, to some extent. All
| people have life outside of work, like to make more
| money, see how unaffordable a house is and say "OK I need
| to earn $200k a year to raise a family the way I want".
| While they won't be so brazen, there is some effect of
| "doing thing thing that leads to the carrot". So the
| company needs to change that carrot - but it is hard
| because the whole industry has the carrots.
| madeofpalk wrote:
| Heh it's funny that your takeaway is "managers hate this". I
| know a lot of developers who would hate such a thing, thinking
| the only thing developers should do is write code.
| a3d wrote:
| Good devs with good communication == Better then PM
|
| Dev + Business = speed and customer centric
|
| Dev + PM + Business = one more layer, i.e. slow, i.e. some loss
| of customer voice
|
| I worked at Amazon as dev for 10 yrs. In early days 2001+. Amazon
| did not hire PMs then. Best of Amazon exp came out in that
| period. I was part of that myself. Pm is needed for things like
| building amazon prime. If at all.
| ath3nd wrote:
| That's a very based take!
|
| The whole idea of a PM boils down to address a less qualified
| non technical middle man to make all the important decisions,
| while also pigeon hole your communications with the rest of the
| stakeholders.
|
| Why does this role even exist is beyond me.
|
| It's like we can't trust the engineers with any important
| decisions, so we need some business guy who took a two week
| course and now is suddenly qualified to be calling all the
| shots.
| sunpazed wrote:
| I've been in product management for over 20 years, and I agree
| with most of what is said here. Ratios matter. CPOs end up empire
| building with an army of PMs. The organisation ends up with PMs
| owning a slice of the customer experience such as a single page,
| optimising CTRs on buttons, with no meaningful contribution to
| the product strategy or vision. It's hard to be a Product Manager
| without owning a product.
| heisenbit wrote:
| Indeed. PMs are paired on a scrum master level. Then scrum
| master - due to the fact that they are "SCRUM MASTERS" and not
| developers focus also on PM type work. To make matters worse
| the "easily interchangeable" developers are coming from an
| outsourcing company. Now the development needs to be isolated
| from the customers with more management. It is a great way to
| increase the GDP.
| ftio wrote:
| Longtime PM as well, and I strongly agree. PMs should have lots
| of surface area --- ideally, an entire product (or more).
|
| PMs should also be a lot more focused on the business' goals
| than most PMs are. It's necessary but insufficient to solve
| problems for your users. Solving those problems needs to
| translate into value for your company too.
|
| Strong, product-minded Eng/UX partners are essential in
| enabling that.
| jasondigitized wrote:
| This. The closer to the P&L the better. It forces you to act
| as a "whole product" manager and not think everything is
| solved by adding a new feature.
| NearAP wrote:
| > It's hard to be a Product Manager without owning a product
|
| I'll say it depends on the size of the product. If you're
| dealing with say ERPs (Oracle Fusion Apps, WorkDay, SAP, etc),
| a PM can't own an entire product. Instead, they'll own multiple
| features where each of those features are complex in themselves
| and being ERP typically involve integration with multiple other
| products.
|
| But I agree with the general thrust of your point which seems
| to be that the PM should own something 'significant'
| mouzogu wrote:
| > With any experienced team of engineers and designers, PM'ing is
| not a full-time job, or at least, it shouldn't be.
|
| after the free money era peaked, consultants have now pivoted to
| efficient downsizing.
|
| when my previous corp merged with another, the first people fired
| where PM's. so its nothing new. imo PM is the epitome of the bs
| jobs phenomenon.
| koliber wrote:
| > Frankly, PMs are not the ones to handle UX, wireframing,
| tracking progress, organizing stand-ups, or being the sole
| authors of PRDs/specs, etc.
|
| Who should be?
|
| There are many schools of thought on this. In the end, it comes
| down to clearly defining who needs to be responsible for all the
| different things that go into defining, designing, and building a
| product.
|
| Given the approach to product management in this article, what
| would the rest of the team look like?
| bjornsing wrote:
| I've spent some time interacting with product managers as an
| engineering manager, or head of a functional area. I've also been
| "acting" PM for an internal product at a medium size tech
| company.
|
| I think product management entails some of the most important
| things a company does. But it's really hard work, and many less
| capable PMs gravitate away from it and more towards either
| "driving" (i.e. micromanaging) the engineering team or just
| playing politics. In an organization with separate Engineering
| and Product functions / org charts this is really hard to deal
| with. You can complain up the chain of command, but bandwidth in
| that direction is (for natural reasons) very limited. As an EM
| the end result is often that these PMs make life miserable for
| your best engineers, and they leave.
|
| My current view is that the best approach is to embed product
| management in the form of a "mini-CEO" (i.e. PM) in each team,
| and if they're not technically competent pairing them with a
| "mini-CTO". Much less room for politics, and much more for
| teamwork.
| demondemidi wrote:
| "Politics"
|
| 35 years in the semi industry. I must be stupid. I really don't
| see politics. I see people trying to argue for their option and
| get support. But I've never seen this politics that people
| complain about. I'm so lucky I guess.
|
| Is politics just someone making a better argument that is the
| wrong technical decision? What is "politics"?
|
| Or am I just not at a high enough level (senior principal)?
| epgui wrote:
| Politics is what happens when you have limited resources and
| you need to decide where to allocate them. Politics are
| everywhere humans are.
| legendofbrando wrote:
| Yes to this. Too many people complain about politics as if
| it is some "outside" force and not simply implicit in the
| way that human beings organize diversified interests. Since
| each of us can only embody our own world view, politics is
| inevitable.
|
| I understand that what people typically mean is people who
| are "too political" where the pushing for interests stops
| being in service of some goal and starts to become its own
| point. But in trying to avoid the appearance of that, too
| many people fail to engage in any politics and in doing so
| actually cause more harm than good to what is important to
| them by missing the important point that it's incumbent to
| speak up for things you need and believe in because people
| who allocate resources may have insufficient knowledge or
| insufficient time to dedicate to knowing your work that
| intimately.
| epgui wrote:
| Politics would be less of a shit show if people had intro
| textbook level knowledge about political science and/or
| didn't approach it like a sport.
| bjornsing wrote:
| > I understand that what people typically mean is people
| who are "too political" where the pushing for interests
| stops being in service of some goal and starts to become
| its own point.
|
| It typically doesn't stop being in service of some goal,
| but rather becomes entirely self-serving.
| bjornsing wrote:
| That's the good side of politics, and I agree: it is
| everywhere humans are trying to accomplish things together.
|
| But when I say gravitate away from hard work towards
| playing politics it refers to something else of course.
| Getting others to do your work while still claiming credit
| is one example.
| epgui wrote:
| It's not the good side of politics, it's how it's defined
| in textbooks.
| bjornsing wrote:
| I don't think those textbooks attempt to define the
| concept in this context. Like it or not, "corporate
| politics" is a well established term.
| epgui wrote:
| Consider whether the stuff you're thinking about is
| "politics" or merely "stupidity" or "malice" (or some
| combination of these). I see no need to mix up the words.
| jack_riminton wrote:
| This is the grown-up answer that this thread is clearly
| lacking
| rjzzleep wrote:
| Politics is a when a company like Caterpillar spends a year
| trying to acquire GPU's for their autonomous vehicle teams,
| because they have 20 security and project managers that want
| to assert themselves in every conversation to get promoted,
| to get to senior leadership positions, while the company
| looses out to Chinese competitors they were ahead of.
|
| Politics is also when middle managers and 2 engineers
| conspire to steal a coworkers work to get promoted and move
| up the silicon valley startup ladder, so that the company has
| to come back a year later to bring back the original
| engineer, because none of these people were capable.
|
| If you haven't seen politics you might have been either
| blessed or didn't want to see it, but for every 1 company I
| worked with that was efficient I worked with 4 that were not.
| bjornsing wrote:
| Good examples! :)
| ngc248 wrote:
| Politics happens whenever there are more than 2 people :).
| OP above must be really lucky to have not seen politics at
| all or one of those beneficiaries of politics who are like
| "Politics ... wut? nah"
| gardenhedge wrote:
| It's possible you've never worked with politically minded
| people but I doubt it. It can be as small as an engineer
| broadcasting how hard a problem is before solving it. If they
| do that, they get the kudos for doing it. If they don't, it
| just gets done unnoticed.
| legendofbrando wrote:
| Most people who dislike political people are failing to
| place the blame on the right actor. Sounds like this
| engineer has recognized how to get rewarded at their job
| and has adjusted their behavior to fit. The actual root
| problem is that this reward system fails to recognize the
| quiet everyday progress required to make something great.
| tomrod wrote:
| In other words, in areas of limited resources where
| politics are innate, the squeaky wheel gets the grease.
| subwrmodblocker wrote:
| The semiconductor industry actually does something. In web
| development it's 100% political. Around 2018 it became easy
| enough to do web development at FAANG companies that there's
| really no such thing as merit because even the worst employee
| is as valuable as the best.
| bjornsing wrote:
| You've worked for 35 years and you've never seen anyone act
| out of self-interest to the detriment of the project /
| company? Either you're incredibly lucky or you're blind. ;)
| marcinzm wrote:
| Politics in this type of context is fighting to the death
| over a single pie versus working together to bake a second
| pie. Some of this is necessary but when you only do this a
| company will not grow except through luck.
| ath3nd wrote:
| I don't believe in Product Managers or Project Owners as a net
| good towards building a better product or a better company.
|
| The most successful teams I have been in had no dedicated
| product role, instead, all decisions were made by the
| developers.
|
| My current view is best to remove all type of non technical
| people or even mildly technical people from the developers' way
| and let them build in peace.
| alistairSH wrote:
| In that scenario, who is driving product requirements?
|
| For example, in an area with strict financial/regulatory
| compliance laws, are you expecting every engineer to be an
| expert in those laws? And have contacts at the government
| agencies implementing those policies?
| lol768 wrote:
| Engineers should ideally be working directly with in-house
| counsel or external specialists under these circumstances.
|
| This isn't just applicable to some niche organisations
| working within e.g. finance (though there's likely to be a
| higher regulatory burden there), engineers need a basic
| understanding of something like GDPR to do their job
| because it impacts every organisation handling personal
| information in any form.
| laurels-marts wrote:
| In extremely regulated environments you would typically
| have someone with legal background to boil down the
| requirements into their absolute essence and give them to
| the dev team.
| alistairSH wrote:
| So you DO have a product manager. You might not call them
| that, but that's exactly what they're doing.
| ath3nd wrote:
| That's not a product manager. That's a domain expert. You
| might have to check some regulatory checkboxes:
|
| - financial
|
| - medical
|
| - data protection
|
| and you might need different experts' opinion for that.
| Do you suggest that they are all product managers?
| tomrod wrote:
| Good product managers I've worked with are better than me
| at navigating the domain and compliance worlds as
| tourists as they are tourists in the engineering side as
| well. David Ricardo was right, comparative advantage is a
| good thing.
| lol768 wrote:
| If I consult a solicitor about data protection regulation
| and they tell me what I need to build to satisfy the
| requirements of soft opt-in under PECR, that does not
| make them a product manager!
| tomrod wrote:
| No, but it's something a good product manager does for
| you, and with the economy of comparative and potentially
| absolute advantages. This let's you focus on the craft of
| delivery without encumberance of spending research into
| compliance.
| ath3nd wrote:
| I don't consider the engineering having a deep
| understanding of the domain and compliance to be a
| "encumberance". The more engineers get into the domain
| themselves, the more they can make deep decisions about
| how to build the most effective solutions.
|
| > This let's you focus on the craft of delivery
|
| I don't give a rat's ass about the craft of delivery!
| What a reductionist thing to think of engineers as
| "delivery machines". Me and my team mates are not a
| factory that simply takes input from a task master and
| produces code to their bidding.
|
| I care only about one thing: solving the problem! That
| encompasses learning, understanding and, finally:
| delivery. To do that, I need to speak to stakeholders
| MYSELF, I need to see how they are using the product
| MYSELF, and any regulation I am gonna implement, _I_ need
| to understand in depth. I don 't need somebody to
| summarize findings for me, I can make my own damn
| conclusions.
|
| Sure, I will ask the domain experts of their opinion, but
| me and my teams will decide what to build, when, and how,
| and do we will do it together, based on all our shared
| learnings, not based on what a PM told us.
| growse wrote:
| > I care only about one thing: solving the problem!
|
| Who prioritises the problems?
| ath3nd wrote:
| The developer teams, of course. They are solving the
| problems, so why should they not prioritize them? They
| just need to have other parts of the org heard, but if
| you are solving it, you get to choose how to do it, in
| what order and with what priority.
|
| If that's not to somebody's liking, they are welcome to
| prioritize and solve the problems themselves.
| tomrod wrote:
| What area of insights does the development team need to
| be able to prioritize for better utilization of their
| product?
|
| ---
|
| > If that's not to somebody's liking, they are welcome to
| prioritize and solve the problems themselves.
|
| Ah, I see. There is a concept known as a separation of
| concerns that prevents this on most teams.
|
| There is a good saying for complex service delivery that
| most developers operate with in application development
| and support. If you want to go fast, go alone. If you
| want to go far, go together. That "together" brings more
| skillsets that most small engineering teams have on
| staff, and is typically not beneficial for them to focus
| on gaining.
| eropple wrote:
| _> if you are solving it, you get to choose how to do it,
| in what order and with what priority_
|
| In times of plenty, this works, and I think it can have
| high velocity. Especially with very small teams that all
| have high levels of direct investment in the result.
|
| There are also times of famine, however, and the work
| that keeps the lights on is often not work that even
| invested software developers want to prioritize. When
| making money is on the line, there's always somebody
| who's there to make you eat your vegetables. Who, in your
| conception of the problem, is that?
| ath3nd wrote:
| > and the work that keeps the lights on is often not work
| that even invested software developers want to
| prioritize.
|
| What kind of work is that? And why are the developers
| willingly not wanting to prioritize it, if the
| alternative of not doing it is becoming jobless? Do we
| need some kind of PM figure to say things like: "If we
| don't make this feature for the client, we are doomed, so
| start coding. Chop chop!". And do we need to keep that
| guy on the payroll for simply relaying a message?
| tomrod wrote:
| > Do we need some kind of PM figure to say things like:
| "If we don't make this feature for the client, we are
| doomed, so start coding. Chop chop!".
|
| Yes, and yes! I believe you're starting to see. Good
| management has value. Even if that is to deflect invalid
| criticism for devs.
| growse wrote:
| > They are solving the problems, so why should they not
| prioritize them?
|
| > If that's not to somebody's liking, they are welcome to
| prioritize and solve the problems themselves.
|
| There's two types of problems that developers solve.
| Problems that they, themselves created (oh no, I wrote a
| bug), and problems that are given to them.
|
| The second type (traditionally, the "business problems")
| _are_ being prioritized and solved by the people who care
| about them. Namely, the CEO and the exco. Those guys set
| overall strategy, culture etc. and then the _delegate_
| the implementation and some of the detail to people with
| more expertise.
|
| Developers do not run the business. They are delegated to
| to solve specific problems in the context of running the
| business. Not all of the business' problems will be
| solved by developers, but all of the business' problems
| should be solved in a coherent and harmonious way that
| accounts for the context of all the other problems in the
| domain (market, regulatory, finance & tax etc.)
|
| For a specific product, the place where this context is
| managed is usually by someone wearing a hat with "Product
| Manager" written on it.
| TrololoTroll wrote:
| Until you inevitably have a question and they need to get
| in touch with the expert again
|
| Middle men only improve transfer of knowledge between
| people under very specific circumstance. Usually they
| just make things worse
|
| Let children play Chinese whispers, I don't need that in
| my life
| marcosdumay wrote:
| If the PM does that, the developer has no idea what part
| of the requirements is important, and won't be able to
| deal with it when the requirements unavoidably break each
| other or reality. The developer has to be there too.
| allsunny wrote:
| I work in one of those environments and we do have those
| people (lawyers). The next question is how should we
| prioritize solving for potential legal risk vs
| reliability risk vs new feature work. You'd expect it's
| black and white, I promise you it's not. The PM has to
| figure that out.
| ath3nd wrote:
| > In that scenario, who is driving product requirements?
|
| The developer teams, who else? You build it, you need to
| know what you are building, right? I find it fascinating
| that the dev community that gobbled so easily "You build
| it, you run it", doesn't question why we are not being
| trusted with knowing and determining what to be built in
| the first place.
|
| > For example, in an area with strict financial/regulatory
| compliance laws...
|
| How often do you have a Product Manager who is an expert in
| regulatory/compliance laws and has contacts with government
| agencies?
|
| Usually the Product Manager is Josh, who just finished uni,
| and a two weeks product manager course. They will have to
| ask experts, and then translate that to the devs. It's much
| more efficient to let the devs ask the experts, which will
| let the devs themselves become well versed in the domain
| over time.
|
| I happen to work in a highly regulated industry, and we
| have an in house law expert, and an in house medical
| compliance team.
|
| None of these roles are embedded in the development teams
| though, they are simply asked for advice rather than manage
| the engineers (which would be insane).
|
| That is how it should be.
| alistairSH wrote:
| Every time I've worked on financial aid, HR, or
| financials, the PM has been an expert in those areas. I
| couldn't do my job otherwise (or, I have to fill their
| shoes).
| ath3nd wrote:
| I work in the medical field which is fairly heavily
| regulated as well. My teams have been able to do our job
| without having a dedicated medical compliance expert as
| their PM.
|
| We just have a medical compliance team and ask them for
| input, but they most certainly don't tell us what to
| build nor drive the product direction.
|
| In short, I question the need of a PM, not the need for
| domain experts (law,financials,etc).
| mike_hearn wrote:
| If you've had good results without a PM you probably had
| someone who was doing that work, but under a different
| job title. Or the results weren't as good as you thought.
|
| Good PMs are often engineers or ex-engineers themselves.
| But a good PM will do a much better job than just
| sticking a bunch of engineers in a room and asking them
| to manage the product. A lot of developers really hate
| tasks like:
|
| - Designing UIs
|
| - Thinking through complex workflows to simplify them
| (unless they're developer workflows)
|
| - Writing documentation
|
| - Often also, identifying and fixing small quality issues
| like bad error messages
|
| - Figuring out what the customer's actually need vs what
| they say they need
|
| Some devs are naturally talented and capable of doing all
| the above, plus banging out the code too. That's great,
| maybe they don't need a PM or more likely maybe they will
| become one themselves in future. But left to their own
| devices a lot of dev teams will rapidly lose the plot and
| start producing features nobody cares about, or doing
| endless refactorings, or produce something that's too
| hard to use.
| Feathercrown wrote:
| I kinda like doing those things
| marcinzm wrote:
| Why does the domain expert have to be the PM versus
| someone the engineers consult directly?
| johannes1234321 wrote:
| Why shouldn't engineers consult with a PM? Isn't that a
| key part of the role - to break down external
| requirements into engineering needs?
| lol768 wrote:
| > The developer teams, who else? You build it, you need
| to know what you are building, right? I find it
| fascinating that the dev community that gobbled so easily
| "You build it, you run it", doesn't question why we are
| not being trusted with knowing and determining what to be
| built in the first place.
|
| Absolutely this. And the engineering teams should have
| visibility of customer support and other functions to
| understand common pain points, causes of churn and
| opportunities for additional revenue-generating
| functionality. That doesn't mean answering run-of-the-
| mill questions or doing refunds all day, but it does mean
| talking to prospects, looking at escalated problems and
| keeping an eye on the wider industry.
| bingemaker wrote:
| This. Most of the developer teams are nothing but feature
| factories. There will be a point where what developers
| want to build and what the product needs will diverge. It
| is very hard to strike a balance IMO.
| growse wrote:
| This tension is why it's a good idea to align everyone's
| incentives.
|
| Bonus the product team on reliability (as well as
| velocity), and the ops/sre team on feature velocity (as
| well as reliability), and it'll balance itself out.
| ath3nd wrote:
| Who is bonusing who?
|
| I think some people simply can't get rid of the idea that
| there has to be some external paternalistic figure that
| looks over developers' shoulder and guides the poor
| hapless saps and their incentives. Do they give candy to
| the good boys/girls and coal to the bad ones? You might
| be thinking of Santa.
|
| The developers and sre's incentives are the same as
| everybody else in the company: have a great, easy to
| sell, popular and reliable product. Management types
| insisting to compartmentalize incentives is them trying
| to have an excuse for their own existence.
|
| We should all drag ourselves kicking and screaming to the
| reality that we can do much more with much less
| management layers. Even big companies, which are bloated
| beyond saving, are waking up to that fact. PMs are the
| first to go, just look at what Meta, a notoriously
| inefficient company is doing to their non technical PMs.
|
| Think for a second why nobody has had the idea of letting
| an engineer be a 'Marketing Project Manager' of the
| marketing team and be calling the shots what campaigns to
| run, what marketing materials to produce, and make
| marketers estimate with poker cards how many of their
| leads will turn to a sale. Sounds stupid, right? Yet this
| is exactly what you want us to accept the other way
| around. Not gonna happen.
|
| There is no excuse to have non engineers embedded in and
| actually calling the shots on behalf of an engineering
| team with the patronizing though that the engineers can't
| decide for themselves what to build and how to prioritize
| it.
| ryandrake wrote:
| > The developers and sre's incentives are the same as
| everybody else in the company: have a great, easy to
| sell, popular and reliable product.
|
| The hard part is how do you design a compensation package
| for a developer or sre worker bee, to incentivize these?
| How do you make their bonus depend on something as
| nebulous and hard to measure as "greatness" or "popular"?
|
| For most employees, the candy/coal model works. You're
| not going to find low-level individual contributors who
| work because they just want to make a great product.
| ath3nd wrote:
| I might verging on socialism here, but I think the best
| way to motivate employees is ownership of the company and
| direct profit sharing.
|
| Unfortunately, only the first part is practiced in my
| organization (company shares), but I am actively fighting
| for the second.
| baq wrote:
| That's what dividends should be doing, right? Or do you
| want the holy grail of percentage of gross revenue which
| is so outrageous to everyone only payment processors
| charge it because they can?
| ryandrake wrote:
| I'm going to part with the accepted dogma to say that I
| don't think that equity ownership motivates workers
| towards doing a good job, at least at large companies. If
| you are engineer number 54,291 moving a protobuf from one
| layer in the stack to another, nothing you do is going to
| move the needle on the stock price, either positive or
| negative. You could write the best, most efficient code,
| fully unit tested and crash-free, but if Morgan Stanley
| downgrades the company's stock because of some bad
| earnings call, it's going to go down.
|
| I have equity as part of my comp package, and I know
| there is zero link between how good a job I do and which
| way the Wall Street Wind blows today. So to me it's just
| like cash but with extra steps.
|
| Maybe it's different in the startup world, I don't know.
| The only startup I was part of, everyone's equity went to
| zero when the business failed, regardless of how well
| anyone did their job, so I'm not much of a believer.
| Hasu wrote:
| > The developers and sre's incentives are the same as
| everybody else in the company: have a great, easy to
| sell, popular and reliable product.
|
| Being on a team where everyone has a high level of
| personal ownership and accountability like that is truly
| wonderful, and I agree, it works great.
|
| You just have to find (or build) a company that
| explicitly filters out the 99% of people who only want a
| job for the paycheck and don't care about the customers,
| the software, or the product.
| growse wrote:
| It seems like you're arguing that the dev teams should
| spend some of their time managing the product. In other
| words, it's a 'hat' to be worn occasionally by some team
| members.
|
| Nothing wrong with that, except what typically happens at
| larger scales is that some people enjoy wearing the hat
| more than others, then the team realises that it's better
| if those people spend most of their time doing product
| management, and then they tweak their job titles ever so
| slighty....
|
| > How often do you have a Product Manager who is an
| expert in regulatory/compliance laws and has contacts
| with government agencies?
|
| In my (highly regulated) industry, _always_? They 'd be
| bad at their jobs if they didn't have this.
|
| _Edit_ actually, I walk that last bit back slightly.
| They don 't need to be _experts_ in those things, but
| they need to know enough about the broad landscape to
| understand what tradeoffs need to be made and set
| direction. Similar to a CEO not needing to be an expert
| in product, marketing, engineering, finance etc. to be
| effective, but they do need to have enough knowledge to
| know how to balance competing requirements across these
| things.
| tashoecraft wrote:
| Sounds like you haven't had a good PM or a job that
| supports having one.
|
| Saying it's often some new grad is like saying there's no
| point having an on shore dev team because the devs are
| often fresh out of university. If you continually hire
| terribly you're going to have a bad result.
|
| A PM should become the subject matter expert in the
| product they are developing. They should be able to field
| questions on most every part of it, and be able to build
| a roadmap of features. Communicate with all teams
| associated with it. Having the programmers plan all
| features is a recipe for disaster if your product isn't
| designed for developers. It's like saying you don't need
| a qa team because the developers tested it.
| dickersnoodle wrote:
| >It's like saying you don't need a qa team because the
| developers tested it.
|
| Strangely enough, that's happening at a few companies
| (run by Amazon refugees IIRC) where they think that
| making devs do QA and removing QA/QE roles will speed
| delivery. I'm in one of those companies now, and I'm
| waiting for the #FAFO loop to happen.
| ath3nd wrote:
| I can most certainly and confidently tell you that a
| dedicated QA team that only does testing is a total waste
| of money! A sre/platform team building fuzzy testing
| tools and mandating better testing practices is money
| much better spent.
|
| The developers MUST care for the quality, not outsource
| it to some external team. The desire of large corps to
| spend huge amount of $$$ to create artificial roles to
| water down ownership can never cease to astonish me.
|
| If your devs can't think of handling nulls or corner
| cases, you got a skill problem, and you should ASAP
| upskill the devs, not outsource thinking to another tea.
|
| Making quality somebody else's problem is the exact
| opposite of ownership! You want agile? Damn leave the
| devs alone, stop building walls around them and the
| product they are building!
| possibly_not wrote:
| >The developers MUST care for the quality, not outsource
| it to some external team. The desire of large corps to
| spend huge amount of $$$ to create artificial roles to
| water down ownership can never cease to astonish me.
|
| As a former quality-focused dev, I can tell you that the
| industry beats it out of you with a club. There is always
| somebody above you who cares only about their own career
| ambitions and has more leverage than you do. This leads
| to a horde of devs who just do what they're told and not
| much else.
|
| Businesses are all about risk management. The safest way
| to de-risk a business is to water down ownership, at the
| cost of injuring quality-focused devs. You're only a cog.
| You _need_ to only be a cog to them. They must to be able
| to replace you with another cog when you leave for
| greener pastures.
| andrekandre wrote:
| > I can tell you that the industry beats it out of you
| with a club.
|
| yep, i can say i've seen this over and over; more than
| anything incentives are for the next okr or whatever to
| be completed so they can move on to the next one asap.
|
| i've seen pr's sent out for review that literally didn't
| work or crashed immediately on use... as if the
| expectation is qa will report whatever needs fixing but
| thats fine cause its "in qa now" so development is
| "done".
| baq wrote:
| That's just Goodhart's law.
|
| "When a measure becomes a target, it ceases to be a good
| measure".
| jonhohle wrote:
| > advocating for better <topic of choice> is money much
| better spent
|
| That seems like a very Bay Area mindset - advocacy is
| more lauded than doing something.
| ath3nd wrote:
| Fair enough!
|
| I used "advocating" loosely here. I hate the "advocate a
| lot, build nothing" mindset myself, and I am not a fan of
| the Bay Area and its practices (to put it mildly), so I
| edited my post.
|
| What I mean is devs making tools for devs, resulting in
| better overall quality.
| jasondigitized wrote:
| You are so right on the QA thing and so wrong on the PM
| thing. If you have a PM that just came out of uni, your
| company has no idea what they are doing. Good PM's are
| really really good at communicating at multiple
| abstraction levels within multiple levels of the
| organizational hierarchy. Why? Because they have to build
| consensus and coalitions to get the things ( money,
| people, buy-in, details, information ) required to build
| really good software and build all the ancillary things
| to sell and support that software. I think what you are
| calling a PM is what I call a jr. project manager.
| tristor wrote:
| > How often do you have a Product Manager who is an
| expert in regulatory/compliance laws and has contacts
| with government agencies?
|
| > Usually the Product Manager is Josh, who just finished
| uni, and a two weeks product manager course. They will
| have to ask experts, and then translate that to the devs.
| It's much more efficient to let the devs ask the experts,
| which will let the devs themselves become well versed in
| the domain over time.
|
| I have definitely seen this happen, but as a very senior
| engineer, now PM, I can tell you this is a
| management/hiring failure much more so than anything
| else. I have long advocated that PMs /must/ be technical
| to be successful and, maybe more importantly, useful.
|
| If you're in an industry that is compliance encumbered,
| you should absolutely expect that your PMs are experts or
| at least professionally competent in the compliance
| standards you need to meet, or at minimum intellectually
| and contextually capable of getting there rapidly.
|
| Hiring someone just out of college to be a PM is a huge
| red flag that your organization doesn't understand the
| role of a PM, and that your upper level management is
| likely incompetent also. Without significant prior
| experience in some related facet to the product, it is
| not possible to be successful as a PM, and I wouldn't
| expect a new grad to be able to do much more than push
| papers. PMs should always be former practitioners, if
| possible, but at least technically competent at minimum.
| allsunny wrote:
| I agree with the point you're making. I wonder if there's a
| disconnect here based on the size and complexity of some of
| the businesses different commenters are working in.
| alistairSH wrote:
| Probably. My employer has >5000 employees, ~2500 of whom
| are in the CTO org. We serve an international market, so
| there's simply no way for a team of engineers to deeply
| understand all the regulations that impact their area.
| 015a wrote:
| I think a major complaint surfaced about the PM role is:
| Its rare for even your PM to be an expert in that area.
| Ideally, they should be. Realistically, there's one guy in
| another branch of the company with a totally unrelated
| title that everyone eventually figures out is The Guy on
| this product domain; and the PM's role becomes "interface
| with Jim".
|
| I don't generally find myself in the Anti-PM camp; but I
| think one of the valid criticisms of the role is that high
| quality hiring for it is so extremely difficult that maybe
| its existence _is_ an indication of a structural problem.
| As the article says; if the ratio of PMs to Teams should be
| less than 1:1, maybe the correct lens to view this role
| through is more of a higher-level product lead, or a
| separate product branch who act more like free agents that
| attach themselves to teams temporarily, splitting time,
| where needed.
|
| I will say, I've worked in two roles where this was the
| case; one a very large public tech company everyone reading
| this would recognize, and another a 30 person startup;
| giving PMs higher cross-team authority felt, to me, like a
| really good decision. One small positive byproduct I
| actively observed: when speaking with our PM, who was
| shared with four or five other teams, he was constantly
| aware of all the other work they were doing, and would
| actively make recommendations about how our little feature
| could plug-in with their little feature to increase the
| quality of the overall product. One small negative he
| communicated: because the company had no entry-level PM
| roles, which is where he started before they refactored the
| org chart, its non-obvious how you backfill these roles or
| create an entryway for new talent to breach the industry.
| Their current solution to this is "well, we can't really
| promote internally unless an EM or Engineer wants to switch
| domains" which they genuinely did try to support.
| naijaboiler wrote:
| What was the product being built.
| andruby wrote:
| What type of product was that successful team working on? I
| believe this can work wonderfully if the developers are close
| enough to the user, eg: building a tool for devs like github.
|
| But if the product and the users are alien to the developers
| then this is a recipe for poor UX and value (eg: building an
| accounting product)
| flappyeagle wrote:
| The best PMs I've worked with were HIGHLY technical, either
| in the same areas as the developers or in adjacent areas,
| like product design, or the domain of the product
|
| PM for retail company did long stints in merchandising at
| Costco
|
| PM for spreadsheet company was a former banking analyst
|
| Most companies hire under qualified generalist PMs who have
| to learn everything about their market from scratch; it's
| very challenging and prone to outright failure.
|
| Hire fewer PMs, and make sure they bring a key skill to the
| table. Let Microsoft and Google train the juniors.
| liquidpele wrote:
| Pffft, they train the juniors? Hahaha, that's funny.
| solatic wrote:
| https://careers.microsoft.com/v2/global/en/students
|
| https://www.google.com/about/careers/applications/student
| s/
| jsdwarf wrote:
| Sounds good in theory, but what if your company decides to
| reduce investments in the spreadsheet product and instead
| transfer the product team into a much faster growing
| product segment, e.g. SAP integrations?
|
| Then the perfectly qualified PMs start from square one
| again.
|
| IMHO it's an essential skill for a PM to familiarize
| him/herself with a new domain in short time. It also offers
| cross-pollination / the chance to do things different.
| Imagine Steve Jobs coming from a pure IT background instead
| of liberal arts / calligraphy -> Apple wouldn't have been
| so different any more.
| aleph_minus_one wrote:
| > Sounds good in theory, but what if your company decides
| to reduce investments in the spreadsheet product and
| instead transfer the product team into a much faster
| growing product segment, e.g. SAP integrations?
|
| > Then the perfectly qualified PMs start from square one
| again.
|
| Exactly the same point holds for programmers: what if
| (say, by becoming acquired) a company has to switch from
| being a, say, a Deno/Vue.js shop to becoming a Java shop?
| Exactly.
|
| So the answer is: don't do such radical changes in the
| product portfolio and way of doing work if you don't want
| the employees to more or less to start from square one
| again.
| cutemonster wrote:
| Note: "were HIGHLY technical".
|
| They had the ability to learn technical things once, then
| they can do it again. (In a short time? Not so easy to
| find out until after you've hired them, in any case?)
| 015a wrote:
| I don't feel that an organization like that is the best way
| to run a company. It may be a superior way to the reality of
| most companies today, but that reality makes achieving an
| environment like that extraordinarily difficult.
|
| Here's the reality I've seen: PMs and EMs share a very
| similar domain of responsibility. The "20% work" of both jobs
| is different; but 80% of it isn't; its communication and
| defense from the rest of the business, and organizing the
| work the engineers need to actually do. Who actually does it,
| in your org, the PM or EM, depends on who has more political
| capital between the two, which is something of a function of
| their skill level, experience, and ability to market
| themselves. Great EMs look like PMs. Bad PMs do all the bad
| things bad EMs do, like micromanage.
|
| Phrase that paragraph another way: in _most_ orgs, in my
| experience, the PM role fills a need which arises when the
| team makes a sub-optimal EM hire, and vice-versa.
|
| That's my reality; but the obvious problem with that reality
| is, if you look at the scientific, hypothetical definition of
| what a PM should do, its not that. There's tons of more
| product-focused "we want to build the best thing" kind of
| work that feels, to me, _rare_ for even Fantastic PMs to
| actually get to do because they 're compensating for an EM
| that isn't pulling their weight. Vice-versa, if you have a
| Bad PM it might not even occur to them that this "we want to
| build the best thing" class of work is a fundamental part of
| the role; ZIRP document factories that could basically be
| replaced with an LLM trained on all the meetings they've
| attended.
|
| The additional lingering problem is that, part of that 80%
| work, "defense against the rest of the business", depends
| significantly on the rest of the business stepping back and
| creating an environment where this "unit" (the EM, PM, and
| engineers) can be autonomous; and I've also nearly-never
| worked anywhere where this was the case, even leadership that
| says "its y'alls call, you've got authority in this domain"
| inevitably catch wind of some decision they dislike, for
| reasons rarely more substantiated then "it feels wrong", and
| even a small number of torpedoes like that can _seriously_ ,
| _seriously_ harm an entire team 's feeling that they're
| allowed to go on of the offensive, rather than playing
| defense 24/7.
|
| Point being: The single best characteristic of upper
| leadership, its not close, there's zero argument of this in
| my mind, its not technical ability, business experience, good
| talking skills, domain experience, whatever: Its Hiring.
| Being able to identify strong talent, keeping a pulse on the
| performance of that talent, ground-truth, all the time, and
| being willing to let people go if mistakes are made. But,
| what I've just described is _extremely_ difficult to execute
| effectively, because every actor in this game is self-
| interested and will actively misrepresent the performance of
| themselves and their unit; politics is the hardest game in
| the book.
| ako wrote:
| I don't understand, how do you handle prioritization
| decisions: if you have a 100+ customers that all want
| something, how do you create understanding of all needs, how
| do you distill that to an integrated roadmap, and how do you
| align the roadmap prioritization decisions across 20+ teams?
|
| How do you organize updating of documentation, training
| materials, enablement of support, pricing decision, updating
| of price lists, enablement of sales, presales, and customer
| success teams? How do you manage the input towards analysts
| like Gartner, that have a big impact on the decision process
| of your customers?
|
| How do you evaluate the offering of the competition compared
| to your offering, how do you determine where you should be in
| 1,3,5 years to have a competing product in the market?
|
| Most PMs are mostly concerned about what should be built to
| create a valuable product for customers, that provides
| healthy stream of revenue for the company. Most developers
| are concerned about how it should be built. That is a
| completely different responsibility.
| ath3nd wrote:
| > I don't understand, how do you handle prioritization
| decisions: if you have a 100+ customers that all want
| something, how do you create understanding of all needs,
| how do you distill that to an integrated roadmap, and how
| do you align the roadmap prioritization decisions across
| 20+ teams?
|
| That does seem to require at least a PHD in prioritization
| or a totally real role like a Product Manager indeed! A
| naive approach would be to make a spreadsheet with the
| names of the clients, their current and potential monetary
| value, group the issues by the corresponding teams and
| themes, and let the teams ask additional clarification
| questions to the clients so they can prioritize. But yes, I
| can see your point, a PM guy called Josh with an bachelor
| of arts degree indeed seems more qualified to do it than a
| bunch of software engineers, and make the better decisions.
| I dunno what I was thinking.
|
| > How do you organize updating of documentation, training
| materials, enablement of support
|
| A naive approach would be to have a frequently updated
| knowledge base. However, I understand that Josh and his
| arts degree make him the best at producing/updating of
| documentation, training materials, and enablement of
| support, so probably...Josh?
|
| > updating of price lists, enablement of sales, presales,
| and customer success teams?
|
| Sales + developers + finance sitting together? Shared
| company view of the important client metrics? Nah, Josh
| will do it.
|
| > How do you manage the input towards analysts like
| Gartner, that have a big impact on the decision process of
| your customers?
|
| Marketing departments? But I have the sneaking suspicion
| Jake (or was it Josh) is a better candidate.
|
| > How do you evaluate the offering of the competition
| compared to your offering, how do you determine where you
| should be in 1,3,5 years to have a competing product in the
| market?
|
| By analyzing competition, thinking forward and having a
| vision. Are developers supposed to only think on the
| benefits of mysql vs postgres?
|
| > Most PMs are mostly concerned about what should be built
| to create a valuable product for customers, that provides
| healthy stream of revenue for the company. Most developers
| are concerned about how it should be built. That is a
| completely different responsibility.
|
| Let me float a crazy idea out there, I hope it doesn't
| sound too far out, I am just trying to dream out loud.
| Because I believe that if we dream big, then everything is
| possible.
|
| Hear me out... How about, maybe having developers concerned
| BOTH about what should be built and how? I know this is too
| radical, and we would probably need first to have that
| notion reconciled with mainstream physics, mathematics, and
| fluid dynamics, but it's just a crazy thought I've been
| having.
|
| Just imagine a universe where engineers not only execute
| instructions from people with suits, but actively decide
| what to build themselves. Of course, that's science fiction
| and can't possibly be achieved, but just imagine!
|
| P.S Sorry for the patronizing tone. I just think the
| industry got it really wrong as a whole, and that we can
| build far better things and far easier if we treat
| engineers as adults who know what they are doing. The
| existence of a PM (or PO) role for me is the opposite of
| treating devs like adults.
| myownpetard wrote:
| Almost every PM I've worked with had an engineering
| degree and/or previously worked as an engineer. This
| "Josh" sounds like a strawman or you've had bad luck with
| PMs in the past.
|
| It also sounds like you have a PM on your team, but they
| actually have the title of SWE or Eng. Mgr. They probably
| spend > 50% of their time on the above listed
| responsibilities rather than engineering. Hopefully they
| don't get docked in their performance reviews for
| essentially performing the duties of a PM rather than
| those of an engineer.
| ath3nd wrote:
| I am very much for any SWE or Eng. Mgr taking
| responsibility and spending as much of their time as they
| see fit on anything they see fit to build a great
| product. Not only that, but I will encourage them to
| continue doing so and give them a great review score and
| potentially a salary bump!
|
| > Performing the duties of a PM rather than those of an
| engineer.
|
| The duties of an engineer are to know what to build,
| prioritize it against their other work, and build it,
| alon with the other engineer in their team. If you
| consider the "knowing what to build/prioritize" as PM
| work, so be it. I consider it engineering work.
| ako wrote:
| PM is not a junior type of job for someone called josh.
| In my experience it's a full time job, requiring
| experience in the customer problem domain, and
| engineering experience.
| anon3949494 wrote:
| I can definitely see how this is appealing for small
| technically oriented teams that want to move fast. It is
| likely however that your team will reach an inflection point
| and at some point having a *good* PM would be a net positive
| to the company.
| jasondigitized wrote:
| The worst products I have ever seen were when the developers
| acted like product managers. What you end up with are a bunch
| of really cool stuff that no one wants to pay for and only a
| few people find utility in.
| StableAlkyne wrote:
| Could you elaborate on what you mean by that? Is it the
| standard scope creep / premature generalization pattern, or
| something else?
| stavros wrote:
| If I had to guess, it's a lack of adequate market
| research.
| OnlineGladiator wrote:
| It's because engineers will build what engineers want
| rather than what the customer wants. Engineers are more
| likely to appreciate highly technical details that
| average customers don't even understand, let alone want
| to pay for. There is also likely a disconnect between
| what it should be able to do versus how easy it is to
| use.
|
| Engineers are likely to solve problems that the customer
| doesn't care about. If you know engineers that say things
| like "the customer is an idiot" then you understand what
| I'm talking about. Even if the customer really is an
| idiot that is the person who needs to use the product.
| cebert wrote:
| > It's because engineers will build what engineers want
| rather than what the customer wants.
|
| I'm not sure you can generalize like this. Do the
| engineers have RSUs or financial incentives where they do
| better if the firm does better? I'd argue they'd care
| more then. Also, a lot of engineers intentionally chose
| to work in market segments they're passionate about. I've
| been at the same company for over 13 years. I could
| likely make more elsewhere but I find the domain I work
| in quite rewarding and interesting.
| stale2002 wrote:
| > have RSUs or financial incentives where they do better
| if the firm does better?
|
| They have a larger emotional incentive to work on cool
| things that they enjoy, as opposed to the relatively
| small change in company price if their individual product
| succeeds or fails.
| NearAP wrote:
| Not the OP, but I think my comment here [1] might be a
| good example of what the OP means
|
| 1] https://news.ycombinator.com/item?id=25975417
| codingdave wrote:
| "most successful teams"
|
| For what definition of success, and at what point in the
| product lifecycle?
|
| I've been on teams as you describe. They were great - as long
| as nobody had to deliver a working product and you were just
| running out runway until the next gig. They were also great
| when the product was already built and we were just KTLO and
| deliver some new features once in a while. But I haven't seen
| such teams deliver a product from initial idea to PMF and
| sustainability.
| nfm wrote:
| What kinds of products were those teams building?
| jsdwarf wrote:
| That may only work if the target group of your product are
| developers, then it's not a suprise they have a clear
| understanding what's valuable to them.
|
| If your product targets customers outside of the IT
| department, it's a whole different picture.
| NearAP wrote:
| This mindset is also part of the reason why some products are
| atrociously bad. Developers build products with the latest
| tech, whizzes, bells and whistles and totally miss the
| 'actual' requirements and/or how their users use it. When
| bugs/issues are raised, dev complains that users aren't using
| the product the 'correct' way.
|
| At the end of the day, whether you should have a Product
| Manager or not AND the number of PMs you should have will
| depend on various factors such as the product itself, team
| size, size of the company, type of company (B2B, B2C, etc).
| But saying that PMs are NEVER needed and Developers should
| just build is wrong. Someone has wear the hat of a 'Product'
| person. Whether it's a separate person or the developer is
| dependent on the factors earlier listed.
|
| My comment here [1] and the discussions for that post is a
| good example of this mindset of PMs are NEVER needed.
|
| 1) https://news.ycombinator.com/item?id=25975417
| gardenhedge wrote:
| A mini cto is an architect in this position
| allsunny wrote:
| I wonder what the author might suggest as an appropriate ratio of
| PMs to engineers might be. I generally like 1 per 10 person team.
| I also like the idea of not having a separate product tool but
| have yet to see a good tool that can satisfy software project
| management (eg Jira, Linear) and product ops (product board,
| Airtable).
| davidthewatson wrote:
| What founders, managers, and engineers share is the team
| responsibility for founding, managing, and engineering the
| product and its value proposition. A product's value proposition
| may be mostly subjective but is easily made objective by
| cost/revenue ratio.
| GiorgioG wrote:
| Most non-technical PMs I've worked with have been ineffective
| because they don't understand or think in terms of systems, they
| only think in "screens" and "buttons". Put me in the "get rid of
| product managers altogether" camp.
| DanielHB wrote:
| Being able to show a relational database schema to a manager
| and ask: "is this the data we need in the manner we need" is
| invaluable
| Hippocrates wrote:
| The problem with most PMs is that they are not doing boots-on-
| the-ground work. A good PM should be constantly bridging the gap
| between engineering and the user.
|
| 1. Map the product or idea being built to those who will use it.
| Present it, get users feelings on it, if it is viable and needed.
| Throughout development, gather continuous feedback by demoing,
| shadowing, and adapting to new feedback. Plan and execute a
| launch, watch for snags, provide support and solutions to users.
|
| 2. Communicate gathered feedback to engineering, and do so with
| an understanding of where the project is engineering-wise, where
| it is going, what needs to change. Give engineering the "why.
| Convey the priority of everything the project needs vs what it
| has and what is being worked on.
|
| Repeat this feedback loop.
|
| But most of them seem to think they can operate entirely in
| document-land and just crank out roadmap docs and keep
| stakeholder alignment via endless check-ins and nagging. They are
| doing a "project manager" job instead.
| jack_riminton wrote:
| Having been a PM (now developer) the problem I faced was half
| the time I was having to provide documentation, communications
| and evidence for my managers. Which is of course fine but when
| you have HIPPO syndrome (HIghest Paid Person in the Office) who
| likes to make product decisions then you have to spend most of
| your time covering your back and managing up
|
| PMs get a lot of stick, sometimes justified, but they're just
| having to play office politics in order to get stuff done
| bhpm wrote:
| Yep. And then you leave and the engineers start complaining
| they have to play office politics to get things done. :)
| hilux wrote:
| PM->Dev is not the typical trajectory, although it's one I'm
| considering.
|
| How do you feel about the transition?
| martin_drapeau wrote:
| A great way to solve for this in B2B, is to hire a customer and
| train them as PM. They will hit the ground running much faster
| to bridge the gap.
| possibly_not wrote:
| Just so I understand, the best way to hire a product manager
| in B2B is to poach the employees of your customers?
| throwawaysugar wrote:
| A more charitable interpretation is poaching ONE such
| employee out of all your customers. It's not a criminal
| act, IMHO.
|
| Managers of any company that think they can't afford to
| lose a single employee are doing something wrong and should
| google "key man risk"
| steveBK123 wrote:
| My org tried this, but being in financial services no one
| thought through this problem - our customers are much better
| paid than any PM we could hire.
|
| That is to say, the only customer we could convert to a PM
| was one who was fundamentally bad enough at his existing
| client side job that he was OK capping his income at 25-50%
| of his potential.
| blehn wrote:
| My experience (FAANG) has been the opposite. PMs want to dream
| up features and put together a roadmap and then they think
| their work is done. A great PM is both creating a vision or
| plan and guiding the execution and iteration. The plan is the
| 20%.
| kylecazar wrote:
| I'm a PM (I now exclusively look for the 'technical' qualifier
| before any role I consider) -- I could not agree more with what
| you wrote. The last paragraph particularly.
|
| Lately, I've been responsible for mentoring other PM's. Sure
| there's the widely shared roadmap, but also -- I can't tell you
| how many documents and sheets are created that are literally
| never seen again by anyone other than me, and I get the feeling
| were created to demonstrate that they are working. It's a habit
| I try to break.
|
| The reason I advocate for technical product management so
| strongly is I've (over)simplified the problem in my head to be
| that some PM's are stuck at that high level of abstraction
| because they're unable to communicate with their teams on the
| detailed technical matters on a daily basis. So they end up in
| a weird grey area of project/product management.
| intrasight wrote:
| > documents and sheets are created
|
| That sounds terrible and predictable. Data managed by a PM
| should be managed and presented in the same product dashboard
| used by everyone else.
| starkparker wrote:
| When they can't use git and find project tracking software
| too complex to understand, this is what regularly happens.
| Either this or charts and tables in Miro/Figma boards.
| ethanbond wrote:
| This is too cynical IMO. Documents are actually the
| correct tool for some kinds of thought and communication.
| Issues are different, Miro/Figma boards are different.
| starkparker wrote:
| > they're unable to communicate with their teams on the
| detailed technical matters on a daily basis
|
| Yeah, I've had PMs who've ground backlog grooming sessions to
| a halt so engineers can explain in detail what each one is,
| or shared incorrect information about a bug fix or new
| feature to a technical writer for release notes because they
| were so confidently incorrect.
|
| The PMs with enough aptitude to understand and explain what
| the engineers are doing, even if they're not actively
| participating in implementation because they're applying that
| knowledge to broader strategic/roadmap decisions and cross-
| team coordination, are the best to work with.
| liquidpele wrote:
| That's what happens when you hire a full time person to do
| what should amount to 8 hours a week. They go looking for
| ways to show value, and often that just causes everyone else
| to have more work too.
|
| Usually it's places where the projects are plenty small
| enough for the normal manager to handle it but they're lazy
| and want the TPM/PM to be their secretary.
| DanielHB wrote:
| > But most of them seem to think they can operate entirely in
| document-land and just crank out roadmap docs and keep
| stakeholder alignment via endless check-ins and nagging. They
| are doing a "project manager" job instead.
|
| They are not managing product, they are managing stakeholders
| smcin wrote:
| Mainly internal stakeholders, I take it. Isn't all that
| entirely big-company politics?
|
| Whereas a PM in a small company can devote more attention to
| the product, customers, market, metrics.
|
| What's a good question to ask to find out which sort of
| animal you're dealing with?
| lp4vn wrote:
| >But most of them seem to think they can operate entirely in
| document-land and just crank out roadmap docs and keep
| stakeholder alignment via endless check-ins and nagging. They
| are doing a "project manager" job instead.
|
| Ok, maybe I came to the wrong place to say what I'm gonna say
| because I guess that a sizable part of the demographics here
| works in hot, meaningful projects, but as a corp worker for the
| last 8+ years, it has been my experience that a lot of
| companies have products that are used either internally by
| their own employees or by another corporate client that still
| pays for them out of inertia or because there is just too much
| custom business logic that now it's too costly to replace them.
|
| In both of these cases we're talking about uncompetitive
| products that are probably going to remain so before being
| discontinued. And in both of these cases companies will try
| nonetheless to create a SCRUM-like arrangement with PMs and POs
| and behave like they are building a revolutionary product,
| urgent taks and pressure for results included.
|
| It has also been my experience that in this kind of environment
| normally PMs and POs will be fully invested in doing politics
| to try to climb up the corporate ladder without much concern
| about what makes a good or usable product. They will steer the
| project in whatever direction makes them look good to the
| administration or the client at the cost of creating a
| fragmented product that many times looks like it's doing a
| random walk in terms of functionality and improvements.
|
| I'm not old enough to know how things were built in the
| 60's/70's/80's(no SCRUM/PM's/PO's I guess) but the
| catastrophist discourse that there's a deep slowdown in
| productivity compared to the previous decades and that today
| we're mostly relying on things we already did in the past maps
| pretty well with my perception.
| dan_mctree wrote:
| >but the catastrophist discourse that there's a deep slowdown
| in productivity compared to the previous decades and that
| today we're mostly relying on things we already did in the
| past maps pretty well with my perception.
|
| Mine too. Any ideas why productivity has slowed down so much?
| Is this a software online observation, or more of a wider
| pattern
|
| With software I guess part of the problem is that there's a
| lot of diminishing returns, with it being much easier to just
| crank out some initial prototype that does a lot, then it is
| to adjust some spaghetti mess that users deeply rely on. But
| that should only really affect individual projects, not
| necessarily the industry as a whole
| lp4vn wrote:
| >Mine too. Any ideas why productivity has slowed down so
| much? Is this a software online observation, or more of a
| wider pattern
|
| It's a wider pattern in fact:
|
| "The productivity paradox, also referred to as the Solow
| paradox, could refer either to the slowdown in productivity
| growth in the United States in the 1970s and 1980s despite
| rapid development in the field of information technology
| (IT) over the same period, or to the slowdown in
| productivity growth in the United States and developed
| countries from the 2000s to 2020s; sometimes the newer
| slowdown is referred to as the productivity slowdown, the
| productivity puzzle, or the productivity paradox 2.0."
|
| https://en.wikipedia.org/wiki/Productivity_paradox
| mistrial9 wrote:
| this compares apples to vitamins in a way -- what is
| possible and what is expected have changed so much in
| thirty years for office and information work, that
| reducing it to a pair of numbers seems ridiculous
| pyrale wrote:
| > Mine too. Any ideas why productivity has slowed down so
| much?
|
| It's not exactly a new idea:
|
| > The term "software crisis" was coined by some attendees
| at the first NATO Software Engineering Conference in 1968
| at Garmisch, Germany. [1]
|
| As you can see, people have had the perception that it's
| harder to crank out software than before for a long time
| now. The reality is that we're collectively vastly better
| at it than we used to be, and that what we're trying to do
| gets harder and harder. No one is paying for the kind of
| productivity software dev had in the 2000's, and no one
| will be paying us 20 years from now for doing what we do
| now. Except if maintaining older software that yields value
| - in which case, well, maintaining and expanding a
| brownfield is always harder than greenfield.
|
| [1]: https://en.wikipedia.org/wiki/Software_crisis
| steveBK123 wrote:
| My team was product managed by a gutless PM who essentially
| made senior devs & tech leads do all the legwork.
|
| Requirements gathering, mean user upset about a bug, weekly
| status call, need to break some bad news re: priorities? - send
| a senior dev or tech lead. Skipped most of the agile ceremonies
| too, busy guy. Never wrote or edited a JIRA ticket, that was
| for tech org to manage. He PMd 2 other tech teams the same way.
|
| Tech leads/senior devs knew our PM was bad news from his first
| week but he outlived all of us until finally getting hit with a
| RIF after 4 years.
|
| Management worshipping at the throne of agile become really
| enthralled with these guys and can derail an org for years. In
| theory a PMs stakeholders are the users, but in practice it is
| buffing the egos of the senior management that hired them. Can
| become a self reinforcing closed loop between senior management
| / agile consultants / PMs.
| ath3nd wrote:
| > Management worshipping at the throne of agile become really
| enthralled with these guys and can derail an org for years.
| In theory a PMs stakeholders are the users, but in practice
| it is buffing the egos of the senior management that hired
| them. Can become a self reinforcing closed loop between
| senior management / agile consultants / PMs.
|
| Beautifully put!
| ryandrake wrote:
| This was the way in almost every place I've worked. If you
| did a good job at managing upward and schmoozing and
| stroking the senior management's ego, and had those smooth
| "ivy leaguer" mannerisms, then it didn't even matter if you
| did your job. You were the Golden Boy and destined for
| greatness. But if you were too busy actually doing your job
| and didn't properly pet your management chain, you were
| setting yourself up to be the scapegoat.
| aperson_hello wrote:
| This is exactly the problem. If you do your job as a PM,
| you get pushed out because doing your job means you'll be
| ruffling feathers in senior management. So to stick
| around, you schmooze instead of doing your job because
| doing your job properly invariably pisses off management
| at some point
| idopmstuff wrote:
| > He PMd 2 other tech teams the same way.
|
| I'm with you that all of this is bad PM work, but this seems
| to be the root cause. I've been at a startup like this where
| there weren't enough PMs to start and then a couple left,
| which just led to the rest being stretched across more teams.
|
| You just can't do much of anything useful in this situation -
| your existence consists of preparing for and attending
| stakeholder meetings. I guess some people thrive on the
| pseudo-glorified existence of "managing" a bunch of different
| teams, but I found it to be as miserable as you seem to have
| found it from the eng side. I was there to spend time with
| customers and designers and engineers, and after a few months
| of doing none of those things, I quit without a job lined up.
|
| Once you get to that point, it can become even worse because
| you end up in this doom loop of management realizing that the
| core PM work is getting delegated to eng, thinking that this
| means they don't need as many PMs and then delegating more
| work to eng.
| Jensson wrote:
| > Once you get to that point, it can become even worse
| because you end up in this doom loop of management
| realizing that the core PM work is getting delegated to
| eng, thinking that this means they don't need as many PMs
| and then delegating more work to eng.
|
| At least that is better than eng doing the PM work and the
| PM getting all the credit for it.
| steveBK123 wrote:
| Exactly. "Oh no, the team doing all the work and covering
| for the other team is going to get the incremental
| resource increases".
|
| Yes. If a team is incapable of either doing their job or
| in advocating for needing more resources to do their job,
| then they do not get to have more resources. Particularly
| when another team is covering for this gap, typically,
| engineering.
|
| It never goes the other way right? How many times are PMs
| picking up JIRA tickets, handling bug fixes, joining on-
| call rotas, etc type tasks that engineering does?
|
| If non-engineering roles/orgs are created to take load of
| engineering, and are incapable of doing so, then they
| need not exist. This goes for
| DevOps/CloudOps/SRE/Support/QA/Product/Project Mgmt/etc.
|
| You can run a lean startup consisting entirely of 3
| engineers. But you can't run a lean startup consisting
| entirely of 3 SRE/QA/Product/whathaveyou.
|
| This is not a knock on these other orgs/roles. In a well
| functioning shop, they are essential. But when orgs like
| Product forget that the tail doesn't wag the dog.. bad
| things follow for everyone.
| boredtofears wrote:
| I've always found PM's that come from a UX/Design background to
| be more willing to engage with the actual people we are
| building software for. IME, it's always been BA/MBA types that
| want to draw up documentation and then chuck it over a wall
| (development) and call it a day.
| JyB wrote:
| That's why the best PMs have some kind of engineering
| background or are former eng. As small as it may be it is a
| requirement nowadays.
| mushbino wrote:
| I've worked with dozens and dozens of PMs over the years and
| almost zero of them do this. Most of this is always done by
| product designers.
| nf3 wrote:
| I guess I belong to the tiny minority of self-employed software
| developers, so my point of view is somewhat unique. In all of the
| projects where I had to deal with people representing big
| companies, I was always struck by the sheer amount of wasted time
| spent on meetings, political machinations, and bike shedding,
| instead of doing actual work that solves the client's problems.
|
| I'm really glad to be my own boss and to not have a PM over my
| head.
| 29athrowaway wrote:
| A bad product manager is worse than no product manager. And it is
| hard to become a product manager that does not do a bad job.
|
| Feature creep, not understanding software development
| methodologies, not having an intuition around technology, not
| talking to users, not talking to the team = bad product
| management.
|
| Maximizing the value of what the team is working on = good
| product management.
| robotsquidward wrote:
| Well articulated thoughts that are mostly detached from the eye-
| grabbing headline.
|
| Good PM's are important. Building product-focused teams is
| important. More of anything != more better. Duh.
| edderly wrote:
| The best product manager I worked with was just an exceptionally
| bright person, they were able to understand complexity of
| implementation (and even have a reasonable chance of doing it
| themselves) vs understanding the business need. Just basically a
| value add to the company without being an engineering manager.
|
| Unfortunately most product managers are just people who sit in
| the role. They are just gatekeepers who take either credit or
| blame. They often have little skin in the game.
|
| Overall, if you have a product management organisation, you're
| doing it wrong.
| strix_varius wrote:
| > Overall, if you have a product management organisation,
| you're doing it wrong.
|
| Agreed, the best (and most successful) products I've worked on
| have all had product ownership by actual implementers
| (engineers, designers, customer success, etc). I loved being on
| the support rotation as an engineer because it closed the gap
| of abstraction between my work and the real humans who were
| using it every second.
|
| Very rarely, I have worked with PMs who add net positive value,
| and in every case they would have made okay engineers as well.
| phillipcarter wrote:
| > Overall, if you have a product management organisation,
| you're doing it wrong.
|
| I've found myself on both sides of this issue in my career and
| I've landed on it being a good thing to have a PM organization,
| assuming your entire org is large enough.
|
| The main reason why is that when PM (or whoever plays that role
| in a team) reports up to the same engineering management chain,
| all things eventually bias towards the needs of engineering.
| Much-needed feature work that is likely to advance the business
| eventually always gets de-prioritized because there's always
| tech debt or infrastructure work that inhibits people in some
| way. Sometimes it's actually the right move to do that, but you
| need tension between two orgs that have equal chairs at the
| table to make that kind of call. That ends up not happening
| when it's a part of engineering.
|
| Of course a lot of the sad reality in our industry is that
| separate PM orgs get to have more power than engineering orgs
| because they get to own "what's good for the business", and
| when you combine that with a bunch of PMs who know how to
| follow a process or framework but don't actually understand
| their own products or users, you get a nightmare.
| earayu wrote:
| I am a software engineer, most of the time, PMs are just make my
| work harder.
| ralmidani wrote:
| Not related to number of PMs, but rather the type that I prefer
| to work with:
|
| I've worked at 4 different companies in the industry, ranging
| from < 40 person startups all the way up to JP Morgan Chase.
|
| I reject the idea that "technical" folks are smarter than "non-
| technical" folks - in fact, as an engineer I often get caught in
| the weeds and lose sight of the big picture, and need a PM to
| help pull me out.
|
| However, in my experience, the easiest PMs to work with as an
| engineer are ones who have at least __some__ actual exposure to
| code. Nothing fancy, it could have been building a website with
| HTML and CSS many years ago, writing some ad hoc SQL queries, or
| taking a Python class while doing a Master's degree.
| __something__ that helps a PM understand that writing code is
| neither an exact science nor outright wizardry.
|
| These PMs tend to advocate for the engineers they work with, or
| at least try to strike a balance between business demands and
| engineering realities. Those who get into PM with zero technical
| exposure tend to be more "business-oriented", which may be
| exactly what a business needs at a given time, but not all the
| time, and as an engineer I would rather work with someone who has
| a better understanding of my perspective as well.
| ericmay wrote:
| Now if only companies (like JPM where I've worked also)
| actually recruited and hired PMs with those technical skills
| instead of whatever bizarre criteria they use.
|
| No I'm not salty at all :p
| flipgimble wrote:
| I've worked with a number of Fortune 500 companies and seen many
| examples of a disfuncional culture. I've seen in those places
| that PMs solve most problems with the one tool at their disposal:
| meetings. Incentives for promotions are such that the bigger your
| meeting the more important you are. I've been in hi dress of
| hours of cross functions team meeting where 1-2 people did any
| work, and usually the PM talked the whole time, while 10-20ppl
| are on mute and only sign off at the end to show they indeed
| exist. The end result see teams of dejected engineers that don't
| have time for actual technical work, and are asked to give
| estimates or commitments on the spot without any research or even
| understanding of the code. I've seen PMs reject technical designs
| because they didn't like the number or "points", and engineers
| just had to reformat the same ideas into different "tickets" to
| satisfy some inscrutable PM aesthetics. Entire projects delayed
| and derailed because of lack of understanding and pointless
| status signaling rituals. On the other hand I've worked with
| brilliant PM who protected the team from such nonsense and helped
| them stay focused on the right goal. These people are invaluable
| as much as the others are detrimental.
| steveBK123 wrote:
| "Expose everyone to users " - I would note this of course has
| logical limits. I've worked in orgs where we had shared slack
| channels (and DM ability) with all customers. Not great.
|
| This meant that squeaky wheels got a lot of oil. They quickly
| figured out who in the channel actually knew what they were
| doing, and so every customer had their pet senior engineer they
| would bother all hours of the day / weekends / etc with
| questions. Support rotas and on-calls go out the door when your
| customers can directly escalate to their engineer of choice.
|
| I actually turned off all slack alerts and disabled notifications
| on my phone as a mental health exercise as a result. So the net
| result of forcing me to be maximally reachable caused me to be
| less reachable as a whole. If someone important enough really
| needed me, they had text/phone/etc.
| cloudking wrote:
| In my experience in multiple roles (product manager, project
| manager, software engineer) and dozens of successful launches
| with large engineering teams, the ideal kind of PM has a deep
| understanding of users, how software should work best for them
| AND technical experience.
|
| The problem with a purely technical team and no user-centric PM
| guidance is they'll end up building an engineering designed
| product, that doesn't resonate with non-technical users. As pure
| engineers, we love engineering, and may over-engineer solutions
| given the opportunity. Unless we are building some developer
| tools or highly technical product, this doesn't work for the
| majority of non-technical products.
|
| You need a PM who can separate the technical design from the user
| experience, but also understands how to bridge the two when it
| comes to actually building the product. No technical experience
| rarely helps, as you spend a lot of wasted time debating why
| things should or can't be built.
|
| As a PM with technical background, I'm not going to waste
| engineering time proposing radical user experiences that I know
| will require excess resources and time to build. At the same
| time, deeply understanding what users want, I'm not going to
| build a product that is too technical for them to understand how
| to use. We understand the limits of our technical stack and how
| to reduce user frustration. That is the advantage of having a
| balanced PM with both user and technical experience.
| hilux wrote:
| I've been a PM in a few B2B companies, and the reality of the job
| was never even close to the ad, i.e. we (PMs) never had authority
| over either Engineering or Marketing.
|
| "Product-led" is today's buzzword, but I'd have to personally
| experience it before I believe it.
| phillipcarter wrote:
| Yeah, IMO "product-led" is just something that sounds nice when
| you package it up with a bunch of truisms and sell it as a
| consultant. There's a nice little industrial complex of
| consultants, "coaches", and other thought leaders who haven't
| shipped any product in a decade or more but will gladly sell
| you their silly services.
|
| We're just here to do a job like anyone else, with hopefully a
| reasonable area of accountability. The thing that "drives" a
| particular initiative is what matters the most at the time -
| could be a big marketing push, engineering quality push,
| something we know sells well into enterprise markets, etc. It's
| fine.
| teaearlgraycold wrote:
| Definitely agree that the ones building should be product-minded.
| It should be normal and expected for engineers to perform
| customer interviews.
| thenerdhead wrote:
| You can summarize this article with a famous Einstein quote:
|
| > Everything should be made as simple as possible, but not
| simpler.
|
| Isn't it clear that scale governs the self-determination theory?
| You can run a company much like a startup if you choose to. Many
| people/businesses do not choose to do that and that allows
| bureaucracy and hierarchy to thrive.
|
| This isn't a "product manager" problem. This is a loss of
| identity or culture. Many of your great people will leave because
| of this eroding. Blaming it on product managers is lazy because
| it shows you aren't looking close enough.
|
| https://wikipedia.org/wiki/Self-determination_theory
|
| https://wikipedia.org/wiki/Flat_organization
| hkon wrote:
| Working in the industry around 20 years now. It has become
| painfully obvious that businesses are out of ideas. Speaking in
| simple terms. Product managers never really stick around long
| enough to learn enough about a market or a product to bring any
| valuable insights or new ideas to the table. Spend 1 year to push
| the "MVP" then it's off to the next one with a salary increase.
|
| Used to be a product guy that was 20 years + with a firm would
| have lots of ideas and hammering the development teams to ship
| feature after feature. I just don't see that anymore in the
| places I lend a hand.
| stockholm wrote:
| Designers should understand design, engineers should understand
| function - and PMs should understand the market. For instance why
| should we prioritise one segment over the other? How should we
| price the product? What are the second order effects of
| prioritising one feature over the other?
| CSMastermind wrote:
| Most product management functions should be merged into product
| design - it's impossible to design a good product without
| thinking about what features that product should have and how
| users will use it.
|
| I wouldn't eliminate the role entirely but I think most companies
| have 10x the number of product managers they need to in part
| because it's a way for non-technical people to get into tech and
| tech salaries. Now that the market is tightening it's
| unsurprisingly we're eliminating those roles.
| 015a wrote:
| One thing I've been thinking more-and-more about recently:
|
| People are unique; there's no doubt about that. But how much of
| "the product manager does product management" is genuinely just
| the title they're assigned, versus some innate capability they
| were born with?
|
| I'm becoming more agreeable to the notion that, at least in
| product development: most people should be doing more things.
| People can and should have specialization; but maybe it should be
| more organic and nuanced, like "Mike is our API guy, but he's
| also pretty good at organizing large projects and if you've got a
| big architectural ick to work through definitely go talk to him"
| versus "Sarah is more on the product side, she'll have great
| insight into user experience and she knows who to talk to in the
| organization to get decisions made faster, but she can also take
| on some smaller frontend tickets."
|
| My argument isn't really "great idea dude, let's get rid of
| titles"; because I think the critical part is, this mindset is
| deeply predicated on Agency. You need an organization that
| assigns High Definition and High Agency to teams. You also need a
| hiring process that, very specifically, treats Personal Agency as
| one of the most important qualities a candidate can have; you
| don't know Go, that's cool, we can teach you Go, what we _can 't_
| teach you is the genuine desire to want to be taught Go, and
| Rust, and some language I haven't even heard of, and by the way
| you're interested in the overall business and revenue and such.
|
| The obvious problem is, people like that are a vast minority, and
| maybe you can't really scale companies by relying on the people
| you hire being intelligent generalists. I think there's also
| something to be said in the force multiplication of technology. A
| room with five of the right people can be more effective and
| productive than a skyscraper of 500.
| pitched wrote:
| People with a lot of personal agency in this way will also slow
| things down by expecting rational decisions from management and
| asking questions when they aren't. I think this makes for a
| fantastic partner, peer or co-worker but a horrible employee.
| So I don't think it's too surprising that most hiring managers
| will be actively filtering them out.
|
| As someone who does very highly value this way of thinking
| though, how would you try to detect it in an interview setting
| as an interviewee? That's like asking them if they have good
| culture.
___________________________________________________________________
(page generated 2023-12-17 23:01 UTC)