Live data from Hacker News

More product, fewer product managers

kitemaker.co

181–190 of 314 posts

Re: More product, fewer product managers

#181
post #136
post #123

Earlier quoted context omitted.

> I care only about one thing: solving the problem! Who prioritises the problems?

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.

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.

Re: More product, fewer product managers

#183

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…

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

Re: More product, fewer product managers

#184
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

Re: More product, fewer product managers

#185

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 launc…

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…

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

Re: More product, fewer product managers

#186
post #136
post #123

Earlier quoted context omitted.

> I care only about one thing: solving the problem! Who prioritises the problems?

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.

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

Re: More product, fewer product managers

#187

Earlier quoted context omitted.

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…

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

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.

Re: More product, fewer product managers

#188
post #146

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 launc…

>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+ year…

>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

Re: More product, fewer product managers

#189

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 launc…

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…

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.

Re: More product, fewer product managers

#190
post #70

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 engine…

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.

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.

Post reply on HN