[HN Gopher] Product Shouldn't Be Left to Product Managers
___________________________________________________________________
Product Shouldn't Be Left to Product Managers
Author : mooreds
Score : 134 points
Date : 2022-06-02 14:24 UTC (8 hours ago)
(HTM) web link (candost.blog)
(TXT) w3m dump (candost.blog)
| righttoolforjob wrote:
| Product Managers today are many times attempting to be shitty
| tech leads rather than actual product managers, which is a
| completely different job. If a product manager has more than a
| superficial opinion about what engineering is doing, then they
| are not a product manager (more than by title). They should feed
| the why and when to engineering, nothing more. When do the market
| opportunities exist and why? Collect and feed the data to
| engineering (as well as other stakeholders). They should not be
| the customer proxy, not lead engineering teams, nor be some go-to
| person for "final decisions" on design matters.
| mips_avatar wrote:
| It sounds like you are dealing with a technical program
| manager. TPM does/should engage technically, and overlaps
| responsibilities with an engineering manager. Not every project
| requires a TPM so perhaps yours only requires an engineering
| manager/tech lead.
| righttoolforjob wrote:
| None of what you are saying makes any sense to me. This is
| another big problem in the software industry, that roles with
| the same name can vary wildly. A little bit like "agile" not
| ever quite looking the same and not ever quite working.
|
| A program manager for me, any kind, relates to the function
| of leading and coordinating multiple interrelated projects,
| towards a common goal.
| mips_avatar wrote:
| Yes, as I said not every project needs a TPM. So if your
| product manager is trying to take on a TPM role for a
| project contained within your team, they aren't really
| adding value.
| enjo wrote:
| Everyone in this thread needs to read this:
| https://www.jpattonassociates.com/dual-track-development/
| polote wrote:
| Very HN article. The only job that matter in an organization is
| developers, product managers are useless, marketing is when you
| don't have a product, sales people are liars, Support people
| prevent developers to know the problems and so on.
|
| It's cool sometime to have developers with a product mindset,
| because they understand better the value they are bringing and
| can help brainstorming. But first if you had only product-mindset
| people everyone would want to ship different features and nothing
| would be shipped. And also the more time developers spend
| understanding customers the less time they spend coding.
|
| I should probably write a satirical article arguing that "Coding
| should not be left to developers as product managers should code
| things much closer from their plan"
| devoutsalsa wrote:
| You're not seeing the bigger picture. Within developers, you
| have the 10x developers. But within that, there is the 100x
| developer... all of a company's success can be attributed to a
| 500kg neckbeard in the basement powered by a caffeine-adderall
| intravenous drip (for playing video games, all the actual work
| is outsourced to that one guy in Afghanistan =>
| https://www.theonion.com/more-american-workers-
| outsourcing-o...)
| MrJohz wrote:
| I don't think the article is saying what you're describing at
| all, or at least, if it is then I missed it.
|
| As I understand it, the article is basically just claiming that
| to become an outstanding engineer, you can't just code what
| you're told to code, you need to understand why any particular
| feature is needed. Obviously that doesn't replace user
| research, project management, business leadership and strategy,
| or anything like that - no developer will also be an expert in
| all of those things, and a good business, like any team, has
| differentiated roles. But a strong developer understands what's
| going on in other places - they understand the overall business
| strategy, even if they wouldn't be able to come up with a
| strategy on their own; they understand how users are
| interacting with their product, even if they aren't doing the
| user research themselves, and so on.
|
| I've worked with a number of developers for whom this sort of
| thing was a complete mystery - they could program very well,
| but if they were told one day to build one thing, and the next
| day to build the opposite, they'd just go away and do that, and
| never question why their instructions made no sense. Whereas a
| more senior developer would want to understand why they're
| getting contradictory instructions, and try and explore whether
| there's a non-contradictory solution.
| polote wrote:
| Well here is the conclusion of the post
|
| > Simply put, instead of expecting someone (e.g., product
| managers) to tell you which product features to develop, you
| should be able to tell what are the most critical problems
| your users or product are facing and find the best solutions
| that fit into your product and engineering strategy.
| nrawe wrote:
| I agree with your sentiment about the pros/cons of developers
| having product mindset.
|
| I don't know that this a HN-specific thing, but I think roles
| very easily become tribes, and everyone thinks their tribe is
| superior. E.g. I know architects who think product and
| engineers serve architecture, I know engineers who think they
| know better than product and give the "yeah-yeah" to
| architects, I know product managers who hate architecture and
| engineers because they don't see the progress they want.
|
| I often see this as a struggle for power, normally in
| situations where there isn't good psychological safety/team
| focus/communication, which leads to a scramble for authority.
| Der_Einzige wrote:
| I don't care if you view that line of thinking as something
| worse satirizing. Companies who treat developers as kings and
| get out of their ways produce amazing products, content, and
| experiences. Valve is my favorite example of this. More
| companies should strive to be like them.
| JJMcJ wrote:
| Best product managers seem to have one foot still in the user
| community.
|
| This is more common for internal applications, where you have a
| PM and likely one or more actual users involved in the project.
|
| That means when there is a new requirement two days before go-
| live, there's usually a meaningful reason, not just that a VP had
| a flash of inspiration the night before.
| [deleted]
| quelltext wrote:
| The best experiences I had were working on products I cared about
| deeply in a way a PM should AND there actually was a PM involved
| who did care about them. In fact everybody involved should.
|
| However, in a project there is a bunch of stuff you need to do
| that's mainly specific to product management. Tracking the
| feedback, talking to users, coordination with other product
| teams, covering the nontechnical pieces, etc. Every stakeholder
| does their thing. The PM in most cases doesn't code, a legal or
| compliance stakeholder doesn't try to talk to users or come up
| with product feature roadmaps, the engineers don't create the
| artwork etc.
|
| The shittiest experience is when you work on a product with a
| formal PM but you wonder what it even is they are doing, not
| engaging in shaping the details just signing off, not talking to
| stakeholders, etc. and you, the engineer, has to fill in. Buuut
| you also cannot just do whatever because the PM exists and needs
| to be consulted.
| BlargMcLarg wrote:
| You could say this for almost any primarily supportive role.
| Individuals forget these roles bring nothing on their own and
| exist entirely to empower ICs. Conversely, that means they can
| disenfranchise ICs and be a net loss just as easily.
|
| They aren't useless, but one could argue the industry needs a
| reality check on how many of these supportive roles need to
| exist (in terms of quantity) and how many of these individuals
| are contributing anything. There are plenty of bad stories
| ranging from "benevolent but capable" to "clearly power
| tripping and a drain".
| OkayPhysicist wrote:
| Part of this problem, IMO, is that we as a society have
| largely eliminated subordinate supporting roles, in favor of
| adding more organizational work to both the ICs and
| management tier. Which leads to needing more managers, which
| leads to beaurocratic bloat as the people who have the power
| to make decisions end up being in a position where increasing
| management overhead improves their standing.
| BlargMcLarg wrote:
| It all went downhill once we decided ICs should not only
| take care of the bureaucracy, but also adapt to supporter
| roles rather than the other way around. I won't rail
| against the usefulness of soft skills, but requiring almost
| every IC to be a well-spoken social butterfly just seems
| lazy in the face of the ridiculous number of supporting
| roles.
|
| Ideally it'd be more 50/50 (help-me-help-you kind of deal),
| but right now it feels incredibly one-sided at most places.
| [deleted]
| Jare wrote:
| I've seen and lived what you describe on occasion and it sucks.
| Managing the features does not mean deciding them, just like
| programming the features does not mean deciding them. Same for
| all disciplines. Establishing the process and responsibilities
| around which decisions are made is the hardest part of
| directing a project, and the default often ends up becoming "I
| direct thus I decide".
| aqme28 wrote:
| I've had that product manager before. The real Shittiest PM
| isn't the one who's absent, it's the one who does too much but
| not well. Constantly shifting priorities, unclear, yet rigid
| guidance, and unrealistic targets.
| steveBK123 wrote:
| I have a PM who basically makes A/B choices as presented by
| tech leads, and leaves it to tech leads/devs to meet with
| users..
| golover721 wrote:
| Unfortunately I have found that a really good Product Manager is
| an extremely rare thing. However the best organizations and teams
| I have worked on have always had strong product management. There
| seems to be a general lack of education and training on how to be
| a product manager. Too often folks from other disciplines, such
| as Engineering transfer into the role with no training whatsoever
| and end up doing a terrible job with it.
| germinalphrase wrote:
| To bridge off of this comment, has anyone found a particular
| Product Management resource or training that is an effective
| on-ramp to doing the job well?
| fudgy wrote:
| Inspired: https://www.amazon.com/INSPIRED-Create-Tech-
| Products-Custome...
|
| Empowered: https://www.amazon.com/gp/product/B08LPKRD5L/
|
| Good Strategy/Bad Strategy: https://www.amazon.com/Good-
| Strategy-Bad-Richard-Rumelt/dp/1...
| rshm wrote:
| Wonder if someone can share their experience with product driven
| teams as in
|
| https://www.thoughtworks.com/en-us/insights/blog/project-vs-...
|
| One recurring issue i have seen on my team is that project
| managers are acting like architects and tech leads (like other
| comment mentioned here). Wondering if the same thing.
| [deleted]
| jkkorn wrote:
| Im always happy when I bump into articles like this one.
|
| In general I think it's ultimately irresponsible to centralize
| ideation on one stakeholder.
|
| Wrote a piece with a similar opinion here:
| https://jonathankorn.substack.com/p/your-teams-relationship-...
| TameAntelope wrote:
| There are only 40 hours in a productive work week (if you care
| about your health). In those 40 hours you simply cannot do
| everything needed to manage a software project. So we specialize.
| Some folks focus more on one set of problems, and others focus on
| other sets of problems.
|
| There should be a good amount of crossover, but having
| "specialists" who "own" aspects of a software project has been
| found, over and over again, to be the most effective way of
| managing a software team.
|
| Two roles that _do not_ fit into one person 's brain are Product
| Manager and Software Engineer. Should a Software Engineer be
| knowledgeable about what the Product Manager is doing? Yes.
| Should the Product Manager be knowledgeable about what the
| Software Engineer is doing? Yes. Should those roles be merged?
| Absolutely not.
|
| Product ownership _should_ be left to the Product Managers.
| Product vision, purpose, and strategy should be available to
| everyone, and everyone should have a say, but to think that
| Software Engineers should also do Product Management is ignoring
| how much work both jobs entail.
|
| I write all of this having actually read the article, and knowing
| the article doesn't actually say anything I'm disagreeing with
| here, but I feel it's important enough to say these things
| anyway.
|
| Software Engineers are in those roles not because they cannot do
| other roles, but because someone needs to write the software, and
| writing software is a hard enough job that it's more or less the
| only thing a Software Engineer should need to focus on. I think
| people forget that sometimes.
| DragonStrength wrote:
| What if your users are developers or engineers? I haven't had a
| ton of luck with my specific niche and product management
| (niche domain; final product is a library developers code
| against) across multiple companies. I can imagine your
| statements can apply to some future market where we have plenty
| of engineers, but in the US, we have a shortage. It's hard to
| imagine how to use your advice when we cannot find enough
| engineers with the domain and technical skill combo. Let alone
| one to convert to product. What do we do for the rest of my
| career which will probably continue to have a shortage of
| engineers?
|
| Our solution is to trust the experts, but certainly there must
| be something better than "whatever the current engineer
| thinks."
| eightysixfour wrote:
| > What if your users are developers or engineers?
|
| What if they're kindergarten teachers, in medical sales,
| rocket scientists, or Amazon deliver drivers?
|
| Part of the Product Manager's job is to understand and get in
| the head of the user, if they can't do it for your users
| they're the wrong Product Manager. If they're relying on the
| engineers they the wrong Product Manager.
| [deleted]
| [deleted]
| siva7 wrote:
| This! I've seen so many teams and products spectacularly
| failing because someone thought that the lead developer should
| also be the product manager. For all the hate that software
| development frameworks like scrum get - the one thing it gets
| really right is that there are roles that should never be
| merged in a functional team.
| lamontcg wrote:
| I spent 10 years working as a software engineer on a product
| that I was originally a customer of.
|
| I found it really weird that so many engineers and product
| managers in the company never really used the product the
| company produced at all.
|
| I don't think that engineers should really be product managers,
| as an introvert I certainly didn't have the patience to sit in
| all the meetings that the PMs took every week, which is why I
| leaned on real actual PMs to do that. However, senior engineers
| ought to develop at least some Product Management Brain and
| spend a bit of time literally just using the product like a
| user and not as a developer.
|
| I don't think software development should be the only thing
| developers do, at the strict exclusion of all else. They need
| the ability to be deep in some code and go "wait, is this
| complicated garbage actually what customers really want?" and
| throw a mental exception and go have a chat with the PM and
| determine if the requirements have gotten wildly off course.
| The mentality of "PMs determine the requirements, I just write
| the code" is a recipe for a really poor product.
| DrJokepu wrote:
| Eh, some software engineers are good at product. Some are even
| good at charming clients. You got to understand the people you
| work with and adjust the processes and roles to match that, not
| the other way around.
| kettlecorn wrote:
| What makes the "Product Manager" role tricky is every person
| and every organization has a wildly different sense of what
| they do.
|
| You argue that there's not enough room in a person's brain for
| Software Engineering _and_ Product Management, but "Product
| Management" often includes planning, strategy, coordination,
| vision, culture, anything vaguely leadership, and general
| "adulting". To call all of that mushed together a "discipline"
| makes no sense.
|
| Skills like coordination and vision are just as orthogonal from
| each-other as software engineering.
|
| As a result the best PMs are often those who know what control
| to _give up_ to make the role / team function better.
|
| I've even been on teams where engineers seem hesitant to
| organize fun events because it may be perceived as stepping on
| a PM's turf, which is absurd!
|
| I think teams and PMs would benefit from splitting up the role.
| I'd love to see the creation of roles like "Associate Producer"
| (as borrowed from the film industry) that have a primary task
| of keeping things running smoothly without a strong focus on
| creative or technical leadership.
| QuercusMax wrote:
| Isn't that Associate Producer role something like a Program
| Manager (PgM) / Technical Program Manager (TPM)? That's been
| my experience at Google.
| klabb3 wrote:
| Yeah. Our problem at $FAANG was that PMs were incentivized by
| the "footprint" they had on the product. Makes sense maybe
| when doing greenfield, or for a major revamp, but man did it
| fuck up existing long-term projects that were essentially in
| maintenance mode.
|
| You'd see PMs join, change direction, narrowly grabbing a
| promo and leaving only to be repeated again by the next guy.
| Each time, the product became more complicated and much less
| focused.
|
| Things like vision and strategy shouldn't factor into any
| performance review for at least 2 years, for long term
| projects. Until you know deeply (a) how everything works and
| (b) the cost of changing things, nobody should be allowed
| anywhere near those big buttons.
|
| The only ones who knew that were the senior engineers who had
| been around forever. And they're not liked by management,
| because they tend to be nay-sayers, and they often like how
| things are. But if you asked management if they were willing
| to break existing customers the answer at the end of the day
| was always no. Yet they all wanted new and shiny things, in
| denial of the feasibility and especially cost.
| suyash wrote:
| Exactly at an IC level (specially for an engineer), it's best
| to become an expert and specialize, that is how you can bring
| most value to the organization.
| winternett wrote:
| Every board meeting now probably whittles down to complaints
| about the CEO's erratic behavior and then a review of earnings.
|
| The world has gone into survival mode and that creates the worst
| kinds of people and products... Many of these companies running
| on profit auto pilot will fail, and that may be the best thing to
| happen because they really stopped doing the good they were
| created for in bids to attract and codify investors.
|
| They'll hopefully be replaced by better companies that bring back
| innovation. We really haven't been innovating game-changing IT
| for years now in my opinion, I think that disruption will only
| happen when these legacy companies get accountable product owners
| that know what they are doing and when they stop looking
| primarily and only at the wrong (ROI) cues for product
| development.
| renox wrote:
| Meh article, sure as a dev you'll be a better Dev if you learn
| about the product requirements like a PM does, you'll also be a
| better Dev if you learn how to deploy the product becoming a
| DevOps, if you become a language expert, a SCM expert, a build
| expert, an OS expert...
| LennyWhiteJr wrote:
| I agree with the author, but it's also possible to take the other
| extreme where engineers think they don't need any input from
| product.
| drewcoo wrote:
| > Up until my mid-level engineering, I didn't think about the
| product.
|
| I think our career yardsticks are very different.
|
| Engineering is all about designing within constraints. Someone
| who's not designing to meet business constraints isn't doing a
| real engineering job for the company.
|
| Learning patterns and practices would be something you'd do in an
| apprenticeship if software worked like real engineering. Or if it
| worked like academics. Or like a trade. But you'd learn that
| while you also learned about how that all fit the larger context
| because that's part of working your way to journeyman (whatever
| that's called now).
|
| So . . . I agree with the author, but I don't see a need to
| attack product folks. We so-called engineers should probably take
| our craft more seriously.
| tristor wrote:
| As someone who moved from Engineering to Product Management, I
| agree with this article for the most part. It's really important
| that Engineers grow their product sense and other product skills.
| Not just so you can communicate effectively within your org with
| other teams and with your PM, but because it helps you empathize
| for your customers.
|
| The thing a lot of engineers (including myself at one point my
| career, perhaps) lack is empathy for their customer. Your job
| isn't to write code, your job is to solve problems for the
| customer. The value a company generates with it's software is by
| taking on customer problems and making it their problem to solve.
| Solving the problem is fundamentally the most important thing.
| But to understand the problem you need to understand the
| customer, and that requires empathy.
|
| Anything you do in your career that improves your empathy towards
| your customers will make you a better engineer because you'll
| make better decisions at every turn in ways which grow the
| business and improve customer QoL. Maybe along the way you'll
| also learn the value of PMs and maybe decide you might rather be
| one... that's kind of what happened with me.
| zucked wrote:
| As someone who is in the product realm, one thing that has
| frustrated me about engineers is how difficult it can be to get
| Engineers to see see where the puck is going, let alone to
| skate to it. Many seem to want to operate much like a computer
| - they take a literal input and give an exact output.
|
| It's so rare, and lovely, when you run into an engineer who can
| not only figure out how to do the task they're being assigned,
| but run through the next couple of steps in the future taking
| the team strengths, company strategy, and product shortcomings
| into account.
| SgtBastard wrote:
| As someone who employs both product managers and engineers,
| if you spoke about (let alone to) an engineer like this in my
| earshot, you'd be given a box to pack your things.
|
| You're not nearly as valuable as you think you are.
| truthwhisperer wrote:
| hcarvalhoalves wrote:
| I'm skeptical of the role of PMs - it often feels like a lossy
| communication layer between stakeholders, and engineering has to
| get involved in some level of detail to understand what has to be
| built anyway. I would rather encourage engineers to get involved
| and understand the domain and the project than rely on this role.
| mason55 wrote:
| > _engineering has to get involved in some level of detail to
| understand what has to be built anyway_
|
| Of course, that's a big part of the role for a senior engineer.
|
| But if you're building a real product, and not just a
| collection of random one-off features that customers ask for
| explicitly, then there's a whole set of work that needs to be
| done to enable good decision-making. It starts with defining
| who your customers are and what are the problems you're trying
| to solve for them. It goes all the way through gathering
| feedback from customers in a meaningful way.
|
| > _I would rather encourage engineers to get involved and
| understand the domain and the project than rely on this role._
|
| The fact that you use the word "project" is interesting.
|
| If someone comes to you and says "here's a project I need you
| to build for me" (could be custom development for an external
| customer, could be an internal stakeholder who gets to dictate
| custom development) then the role of product manager doesn't
| make sense.
|
| If, instead, you're building something based on a need that you
| believe the market isn't meeting, then the role of product
| manager makes a lot more sense. The product manager IS the
| stakeholder in this case. They are the one identifying unmet
| needs in the market, possible customers, business problems to
| solve, etc. For a team trying to build something new that is
| expected to be sold to lots of customers, just the part of
| defining the market is hugely valuable, because it gives the
| team a starting point to evaluate any solutions they come up
| with.
| ako wrote:
| Main role of the PM is to prioritize: what get build/shipped
| first, what later, what not?
|
| To do this a PM has to balance and understand the needs of the
| customers, the potential customers, the direction of the
| company, the direction of the market, the capabilities of the
| competition.
|
| The engineering details are better left to the software
| engineers, architects, key users and UXers.
| tlogan wrote:
| One of the most important role of PMs is to tell the team what
| not to implement. Or which feature to remove.
|
| I worked with a couple of good PMs which were good at that: and
| product and profits really improved. The worse PMs are the one
| which just say: customer x wants y - we need to implement y.
| Without thinking of market landscape, future, training costs,
| etc.
| nlh wrote:
| It's good to be skeptical, but I think the role is critical if
| done right. Someone described a good PM as "a conductor keeping
| the orchestra in sync". And even as you described - someone
| needs to be the layer to gather feedback from customers, make
| sure it's feasible to build, decide what to build vs. what not
| to build and when, make sure executives are happy, keep the
| designers on track and focused, etc.
|
| If that layer is lossy, then you simply have a bad PM (which
| doesn't mean there should be NO pm, it just means you need a
| better one.)
|
| Do you as an engineer want to be doing design reviews and
| giving feedback on page layout and usability? Do you want to be
| on 20 customer calls talking about the business, showing demos,
| and getting feedback? Do you want to present to the board what
| your next few releases are going to look like? Do you want to
| maintain a product strategy so that you have a source of truth
| to answer "should we build this?"
|
| You may say "yes" for some of those some of the time, and
| that's great and important. But if you're saying "yes" to all
| of that all of the time, then congrats, you're not actually a
| full-time engineer, you're a PM who knows how to code :)
| phillipcarter wrote:
| > I would rather encourage engineers to get involved and
| understand the domain and the project than rely on this role.
|
| What confidence do you have that an engineer would be less
| lossy in this role? It's a full-time thing when done right.
| dboreham wrote:
| PM is just an adult you need when the developers are...
| juancn wrote:
| A good PM is an advocate for the customer, but the role also
| ends up having to balance needs from Engineering and company
| vision.
|
| If you work with a great PM, it's fantastic. They can bring
| clarity to product in a way no other role can.
| efitz wrote:
| This article is a worthwhile read and I can't recommend it enough
| to anyone who wants to hit senior/staff/principal engineer or
| above.
|
| Technical skills are not enough. You're not hired to write
| software; you're hired to write software that solves problems.
| Once you realize this; you'll develop skills that complement your
| technical skills and amplify your effectiveness and value.
|
| Expecting to be given a requirements doc or spec and then
| delivering an interesting solution is rare. Building exceptional
| solutions requires you to intimately understand the problem space
| and how your software's users will think, and solving the
| problems that they might not have even known about.
|
| Anyway read the fine article.
| juancn wrote:
| The best products I've worked for took input (mainly) from three
| sources:
|
| - Product Managers: a.k.a. the voice of the customer, what
| customer want and need
|
| - Engineering: what's possible, rethinking the product from the
| tech POV, to create delightful experiences.
|
| - Executives: Vision about what the company should be in the long
| term
|
| All these crossed by a strong design team, to make sure we've a
| coherent UI, internationalization teams, accessibility,
| documentation, support, etc.
|
| When all these align, it's a magical experience where you feel
| you're making something useful. Your product not just does what
| is requested, but it solves problems for customers they didn't
| know they had in the first place, because they had no way of
| framing it, competitors start playing catch-up, and you end up in
| the lead defining a market.
|
| Typically you also end up having magnific engineering challenges
| with solutions that will make you proud of having built them.
|
| As usual, always think about what's valuable and why, and push
| for that.
| daigoba66 wrote:
| This, frankly, is the real definition of a unicorn software
| company.
| [deleted]
| dymk wrote:
| I'm pretty sure it has nothing to do with a unicorn - a
| unicorn is on a fast growth trajectory, with a large and
| reasonably-likely upside. Not necessarily one that where PMs,
| execs, and eng can finish each others' sentences, they're so
| well attuned.
| daigoba66 wrote:
| I'll admit that I didn't make it clear the sarcasm/joke.
| But I was playing on the fact that a unicorn is a mythical
| creature, just as mythical as this functioning proddev
| team.
| projektfu wrote:
| I thought they meant unicorn, as in the unicorn love
| partner who has all the great qualities and doesn't exist,
| rather than the VC unicorn, a quick-to-a-billion company.
| magicink81 wrote:
| I'm sure I'm not the only one in the audience interested in
| more details about how the specific team you may be talking
| about was organized to come together, operated, and evolved.
| Great to hear about the key role of designers being recognized.
| Kalanos wrote:
| well, yeah. everyone helps ideate on the product. you could write
| the same post and replace all the engineering terms with sales
| stuff or science stuff. for example, in biotech, it's not just
| about tech.
|
| counter argument: product managers that aren't technical are just
| product marketers
| nickdothutton wrote:
| I think people have lost sight, or perhaps never understood, the
| role of the product manager. The role of the product manager is
| to manage the product through the product lifecycle. Concept,
| R&D, launch, iteration/revision, maturity, decline and
| retirement. I've been fortunate enough to bring new winning
| products to market and to kill off a fair few. Both ends are
| rewarding.
| PraetorianGourd wrote:
| I know the title is consistent with the article, but the
| undertone of the title (to me) implies "because they will mess it
| up" but really the context is because engineers hit a growth
| ceiling without a product mindset.
|
| The title just verges in clickbait to me
| scyzoryk_xyz wrote:
| As a (young) PM - yes!
|
| How I wish engineers in my little company expressed a little more
| curiosity about our users and how the things we make solve their
| actual problems. Would be a huge load off my mind.
|
| However, I can't imagine our engineers taking over my job
| entirely and being able to just do both. They're just not the
| type of people who could handle talking to the marketing and
| sales people. Not to mention the clusterfuck that is our actual
| users and use cases.
| toss1 wrote:
| YUP
|
| If at all possible, have the actual architects and coders talking
| directly to the end users.
|
| Avoid having the product managers talking to the user managers.
| Avoid even more having executives talking to executives. (At
| least exclusively, of course one needs customer executive input
| to discover what they need, but that is really as other users,
| e.g., of the reports generated). Keeping the discussions high-
| level instead of coder-user is pretty much a guarantee of
| multiple rewirtes, add-ons, extensions, cost and schedule
| overruns, and generally poor results. Even when everyone is
| sincerely working hard to get a good result, merely the result of
| the 'telephone' game, and loss of key details which indicate real
| issues and latent structures/processes that need to be taken into
| account in the design...
|
| It may seem frivolous, but it is a key to successful projects,
| whether as a consulting org or internal enterprise development.
| mason55 wrote:
| > _It may seem frivolous, but it is a key to successful
| projects, whether as a consulting org or internal enterprise
| development._
|
| Sorry, but neither of those things usually require a product
| manager because neither of them involve building a product.
|
| The role of product manager is basically THE key difference
| between building custom software and building a product.
|
| When you're building custom software, you have a specific user
| who is paying you to solve a specific problem for them. The
| only measure of success is whether you solve their problem
| (within time/money budget). For these kinds of things, you're
| right, it's absolutely critical that the person with the
| problem and the person solving the problem work closely
| together.
|
| When you're really building a new product, you won't even have
| any users and you won't have anyone paying you who's defining
| success for you. Someone on your team needs to figure out who
| are the customers you're trying to target, what problems are we
| trying to solve for them, how can we solve those problems in a
| way that's generic enough for us to sell it to multiple
| customers, etc. That's all legwork that a (good) product
| manager should be doing because, again, no one is proactively
| defining it for the team.
| toss1 wrote:
| True, I was talking mostly about custom software, but I've
| also turned that into products.
|
| >> Someone on your team needs to figure out who are the
| customers you're trying to target, what problems are we
| trying to solve for them, how can we solve those problems in
| a way that's generic enough for us to sell it to multiple
| customers, etc. That's all legwork that a (good) product
| manager should be doing because, again, no one is proactively
| defining it for the team.
|
| And this is exactly the task that should be done, NOT ONLY by
| the project manager. Perhaps, if the PM has a stunning level
| of deep knowledge of both the engineering capabilities and
| the product's domain, (s)he might be able to make a good stab
| at it. But getting actual engineers talking to actual
| intended users and integrating that knowledge will still make
| a better product. I'm sure there are some PMs that can pull
| it off, but...
|
| How many times have you used a product and had to ask "how TF
| this this even pass first user testing"?. They'd already
| committed to what turns out to be a dumb design and it was
| too late to fix it.
| zeruch wrote:
| The part that Product groups sometimes miss if they dont have
| process/mechanisms in place for it, is feedback from field groups
| (sales, TAMs, PS, VARs, et al) who bring direct, 'real world'
| feedback...
| vsareto wrote:
| >Although these topics are not related to coding at all, they
| make me a better engineer and engineering leader.
|
| This is fine for shallow problems in the business space, but
| eventually you will get to harder problems and will need to
| collaborate with experts. Experts are experts because they spend
| many hours on those subjects. You are an expert at engineering
| because you spend many hours on that subject.
|
| Don't let your recently acquired domain knowledge make you
| overconfident enough to not reach out to experts. Everyone thinks
| they know how something works until someone more knowledgeable
| comes along.
|
| >instead of expecting someone (e.g., product managers) to tell
| you which product features to develop, you should be able to tell
| what are the most critical problems your users or product are
| facing and find the best solutions that fit into your product and
| engineering strategy.
|
| Which is fine if the problems are obvious and there are easy wins
| to be had. Your solution's effectiveness is limited by your
| expertise in the domain.
|
| This is a regular pattern I see, which is "developers pretending
| to be experts at everything because they're good at picking up
| knowledge and skills". There is a time component you can't skip
| when acquiring domain knowledge.
|
| Additionally, while it's great to strive to be an expert in both
| engineering and the domain, you're naturally doing two jobs for
| the price of one. Many domain experts with a singular expertise
| might also make more than developers striving to be double-
| experts at the lesser price of a developer.
| encoderer wrote:
| I've served many roles in tech. Engineer, lead, manager,
| director and now founder.
|
| My experience is that when a product manager has true
| expertise, that product manager is respected easily by the
| whole team.
|
| Likewise, when a product manager without specific expertise
| proves adept at prioritizing and gains a reputation for quality
| work, they are easily respected by the whole team.
|
| But in many cases the product manager is a Stanford MBA with a
| couple former roles at other tech companies and has never
| accomplished anything very impressive. And these hires are
| corrosive for a product org. They get in and hire more just
| like themselves. The problem is not the Stanford mba it's that
| all they have is a Stanford mba and confidence in their own
| skills. It's not enough to demand the respect of engineers who
| have sometimes worked years in the domain.
| gedy wrote:
| > This is a regular pattern I see, which is "developers
| pretending to be experts at everything because they're good at
| picking up knowledge and skills". There is a time component you
| can't skip when acquiring domain knowledge.
|
| Maybe that's true, but almost all the Product managers I've
| worked with in multiple companies were not experienced in the
| the domain we were working in either. They were mostly generic
| "product people" from random other domains. So it wasn't a
| stretch to say the engineers who had worked there knew more
| about the domain than the product folks did.
| vsareto wrote:
| Even in that situation, the PM should be striving for more
| domain knowledge than the devs. Devs shouldn't be expected to
| pick up that slack. If they are, they should be compensated
| for it.
| ArnoVW wrote:
| The funny thing is, developers will always have a more
| precise and detailed domain knowledge. Because unlike the
| PM, who can analyze the problem in the abstract and
| approximate, the developer must produce working code.
|
| However it is very difficult to have empathy with the user
| when you're trying to produce code. Also, you're generally
| judged on your ability to 'finish US' quickly. So generally
| you'll choose an approach 'that works'. Only to have the
| feedback 'great, but why did you not think about this?'
| spookthesunset wrote:
| > However it is very difficult to have empathy with the
| user when you're trying to produce code.
|
| Not only that, but as a dev you can get into a position
| where what you decide to work on is based more on ease of
| development or "fits cleanly with what we have now".
|
| There should be a balance. The PM should push for the
| impossible and the engineers can tell the PM why that
| won't work. Kind of... maybe not with that much hyperbole
| in my assertion.
| peteradio wrote:
| > the developer must produce working code.
|
| Bingo, I can't (well won't) build a contradiction even if
| its part of the spec.
|
| > Only to have the feedback 'great, but why did you not
| think about this?'
|
| Even worse IMO: "Great, no problems!" every time. Ok, I'm
| not that good, is anyone even running this shit?
| mooreds wrote:
| > This is a regular pattern I see, which is "developers
| pretending to be experts at everything because they're good at
| picking up knowledge and skills". There is a time component you
| can't skip when acquiring domain knowledge.
|
| I wrote about this years ago:
| https://www.mooreds.com/wordpress/archives/134
|
| Both things can be true: it's good to have some product mindset
| and you should also defer to the experts. In fact, they build
| on each other, otherwise how can you communicate with the
| experts? You have to have some common, shared language to do
| so. They might learn engineering, but it's more likely a dev
| will learn some of the domain.
| taylodl wrote:
| Absolutely true - but at the end of the day some _one_ has to
| be vested with making the final decision. That 's what
| Product Managers are for, they're vested with making the
| final call. As you point out, good Product Managers won't be
| overbearing overlords just like good engineers aren't simple
| order takers.
| ownagefool wrote:
| Which decision?
|
| How a feature UX should work based on the PM having a fair
| bit of expertise in the field? Maybe.
|
| What task you work on next? Maybe not.
|
| You see the problem with letting someone who's not an
| expert in the work decided the work goes both ways. The PM
| is in charge? Good luck getting patching on the backlog.
| Don't consult the PM? Good luck getting the functionality
| right.
|
| My takeaway is the PMs often aren't the experts in writing,
| maintaining, or running a production system, thus they
| probably shouldn't actually run the backlog. But said
| production system is pretty useless without market fit, so
| you want to strongly align with whoever your version of a
| PM is.
| taylodl wrote:
| The Product Manager owns the _what?_ , they don't own the
| _how?_ or _how long?_. They 're getting feedback and
| directing the sales team, the marketing team, the
| engineering team, the UI team, the QA team and the
| support team. It should be easy for a competent
| engineering team to get patching on the backlog - after
| all, that's table stakes. Organizations struggling with
| the mundane is the very definition of dysfunctional.
| ownagefool wrote:
| But very common.
|
| Which goes back to the point, maybe Product aren't master
| of the universe directing all the teams, but just another
| group of folks with relevant skills that should advise
| and advocate, but not direct the others groups, whom are
| the actual experts of their respective areas.
___________________________________________________________________
(page generated 2022-06-02 23:00 UTC)