[HN Gopher] Product vs. Engineering
___________________________________________________________________
Product vs. Engineering
Author : kiyanwang
Score : 141 points
Date : 2022-10-17 05:53 UTC (1 days ago)
(HTM) web link (martinfowler.com)
(TXT) w3m dump (martinfowler.com)
| javier_e06 wrote:
| The Us vs. Them dynamic always fails. The "We are all in this
| together" bs also fails because is empty rhetoric. What works is
| surround ALL SIDES of the organization with people with superior
| soft skills.
| [deleted]
| fdgsdfogijq wrote:
| What I have noticed even in top engineering companies is an
| interesting dichotomy. Product determines the "innovation",
| engineering determines how to build it. I wonder if thats
| because, if you let engineers do both, you end up with a mess and
| accomplish nothing. Programming is hard enough, programming
| within well defined barriers and goals is much easier. You have a
| low risk cycle of design -> code -> test.
|
| The issue is that often product is not technical enough to bake
| in technical possibilities to how they think about innovation.
| Not always, but I have seen this happening even on recommendation
| and ML marketing systems for some of the large most sophisticated
| companies.
| SkyPuncher wrote:
| In my experience, it's way too easy for engineers to geek out
| on the how without addressing the "why". I'm guilty of this
| myself, from time to time.
|
| When product is leading the charge, it often means they've
| validated a need from a customer and are ready to address it.
| When engineering leads, they're often pushing a capability
| without having evaluated it against customer needs.
| mkl95 wrote:
| > if you let engineers do both, you end up with a mess and
| accomplish nothing.
|
| Hard disagree. When left on their own, a product oriented
| engineer delivers value orders of magnitude higher than a
| technical product manager.
| fdgsdfogijq wrote:
| As an engineer I want to agree. But for a large corporation,
| I think they prefer the risk averse approach of strict
| requirements for engineering.
| gopalv wrote:
| > I wonder if thats because, if you let engineers do both, you
| end up with a mess and accomplish nothing
|
| No, it is because an Engineer (with technology selection
| blinders on) will jump to a What/How before the Why actually
| lands in a conversation.
|
| The why will be recorded as "what the customer wants", we jump
| from problem to solution too fast.
|
| In fact most of the times the product org only provides a
| "What" to the engineering team which is where most of the
| problems are buried & plays it close to the chest with the
| "Why".
|
| I was an engineer reporting to the CPO in my last job and my
| entire job was to diffuse the "Why" down to the engineering
| org, so that they felt purposeful about the problems they were
| solving & to push back on the What if there's a better solution
| possible. But I didn't get to redefine the "Why" part of the
| question, even though I really wanted to do it to make more
| progress in the directions I was already headed.
|
| Once you got "what", then you get to "how", "who", "when" and
| usually "how much?".
|
| The message usually bounces off the end of that and goes back,
| to the customer who's eventually going to solve the "how much"
| problem.
| sdevonoes wrote:
| You let your engineers diffuse the "Why".
|
| You let your engineers figure out the "How".
|
| You let your engineers implement the "What".
|
| ... at the end you let your engineers figure out everything.
| So tiring.
| passwordoops wrote:
| >is because an Engineer (with technology selection blinders
| on) will jump to a What/How before the Why actually lands in
| a conversation.
|
| I'm in marketing/biz dev now at an engineer-led company, and
| in a meeting last week a dev team presented a new UI that is
| a MASSIVE departure from our current approach. At the end of
| the demo, they informed us that a) it's being released in 2
| weeks, b) do you think the clients will like it, and c) can
| we charge more for it?
| ketzo wrote:
| > a) it's being released in 2 weeks b) do you think clients
| will like it
|
| Oh god, that gives me the sweats. Godspeed.
| PragmaticPulp wrote:
| > What I have noticed even in top engineering companies is an
| interesting dichotomy. Product determines the "innovation",
| engineering determines how to build it. I wonder if thats
| because, if you let engineers do both, you end up with a mess
| and accomplish nothing.
|
| The top companies have product and engineering working closely
| together. This allows product people to go deep on optimizing
| their product skills and engineers to go deep on optimizing
| their development skills, both of which are most effective when
| performed in conjunction with each other as part of a strong
| team.
|
| There are great product-minded engineers and great engineering-
| minded product managers out there, but it's much easier to find
| people who are simply good at their domain and know how to work
| closely with people in other domains to get things done.
|
| Some companies try to cargo-cult this by drawing a dividing
| line: Product defines the "what" and engineers define the
| "how". Product works in isolation, hands things off to
| engineers, then engineers churn through tickets in isolation.
| This is not good at all.
| zingar wrote:
| The elephant in the room for me is that it's only the existence
| of "product organizations" that create the problems described
| here. Product skills are a vital PART of a multi disciplinary
| team, but should not be separate or - heaven forbid but just the
| unfortunate reality - consider themselves in management over or
| otherwise in charge of any other part of the team. You want to
| make software? Fine, come be part of the team with me. We'll work
| together and make great things happen. Don't fool yourself that
| things will be better if you just tell me what to do.
| bjornsing wrote:
| I'm not too fond of the "separate Product and Engineering
| organizations" model... The whole idea of having one branch of
| the org chart telling another what to do is kind of flawed. I
| think it's often better to divide up the product over many
| separate small teams, each with a product focused "mini CEO" and
| a tech focused "mini CTO".
| lifeisstillgood wrote:
| Yes.
|
| Take a rough guide to military planning and you see "strategy,
| Operations and Tactics" not "business vs tech".
|
| And the prevailing direction is towards "mission command" -
| where each level provides the resources down to the next but
| it's not "directing" as opposed to "hand off"
| P5fRxh5kUvp2th wrote:
| 100% this, what ends up happening is product wedges themselves
| between business and technical so they wield the power due to
| having business' ear, and any attempt by technical to
| communicate directly with business is met with severe
| reactions.
|
| The thing to understand is that very likely your technical
| people are smarter than your product people. In addition, part
| of software development is being able to identify what needs to
| be solved. Any developer with a modicum of experience knows how
| to do this.
|
| Just as you have a technical leader on the team, you need a
| technical architect on the team. That person can interface with
| the business or the business analyst (or both) as needed.
|
| separate teams is a degenerate case for strong software
| development.
|
| I once literally had a business person ask "who should be
| involved in this conversation" and my response was "product and
| technical so we can advise". Product responded after me with
| "Product" and the lack of technical there was deafening.
|
| It becomes a power play, the theory of the different
| departments works out about as well as putting a racist and a
| black man in a room to collaborate on race relations.
| taude wrote:
| theres a lot of orgs where product people will be onshore and
| the technies offshore, so the model and barrier kind of makes
| sense (for this operating model), and typically the Product
| people will be the more expensive/smarter/critical resource
| in this case.
| kenhwang wrote:
| In my personal experience, that model has rarely led to a
| good product, good technical implementation, or even good
| development velocity.
| P5fRxh5kUvp2th wrote:
| In this setup you need onshore to manage that offshore team
| or you're just asking for pain.
| esotericimpl wrote:
| The key to this is to only hire "product" people who grew out
| of either Design or Engineering, Anyone who started as
| "product" is a wanna be general who provides minimal value.
|
| My usual first question to any product candidate is do you
| find yourself coming from a Design, UX, or Engineering
| background?
| lliamander wrote:
| People with _relevant_ industry experience, even if non-
| technical, are also good candidates for product roles.
| cj wrote:
| I've had luck hiring people with "dev bootcamp" level
| experience who didn't excel as an engineer post-bootcamp,
| but know enough technical jargon to communicate,
| collaborate, and understand engineers.
|
| Often these are people who became bored with day to day
| coding having more interest in the business side of the
| company
| [deleted]
| robocat wrote:
| > putting a racist and a black man in a room
|
| Suggestion: Avoid prickly metaphors. Especially ones that
| imply reader is situated in a particular country?
|
| Reason: Everyone can be racist. In a place with only black
| men, is nobody a racist?
|
| Disclaimer: White guy on an Island. Sorry for off-topic
| content, I try not to make it a habit. I am generally against
| PC bullshit.
| noobker wrote:
| >very likely your technical people are smarter than your
| product people
|
| Intelligence is multifaceted. That business listens to
| product and not to engineers could be seen as a type of
| social intelligence of which engineers are notoriously
| unskilled.
|
| Regardless, framing any portion of your organization as
| "smarter than" (implicitly "better than") isn't going to help
| in terms of fostering collaboration.
| wittycardio wrote:
| Yes it is multi faceted. But in this industry one of those
| facets is worth more.
| Nemi wrote:
| I am an engineer by trade, but I would argue product is
| more important than engineering. WHAT you work on is
| ultimately more important than HOW it is achieved from my
| experience. Yes, bad engineering will ruin a product, but
| it is all moot if you are not working on the right thing.
| So many companies I have worked with are working on the
| wrong thing. Another way to put it is, a company with a
| great product that has bad engineering will outperform a
| company that has great engineering but a bad product.
| Product/market fit rules all. Once I understood this I
| was able to work with the product team better.
| lliamander wrote:
| > Intelligence is multifaceted. That business listens to
| product and not to engineers could be seen as a type of
| social intelligence of which engineers are notoriously
| unskilled.
|
| To some extent that's true. I'm sure that product folks
| tend to have higher verbal intelligence (on average). But
| all forms of intelligence are highly correlated with each
| other, and engineers are likely higher overall. Many
| (though not all) of the engineers I know are quite
| articulate, even when English isn't their first language.
|
| Much of the difference in "social intelligence" might just
| come down to being more outgoing and assertive, rather than
| an actual difference in ability.
|
| > Regardless, framing any portion of your organization as
| "smarter than" (implicitly "better than") isn't going to
| help in terms of fostering collaboration.
|
| I agree that the other poster's framing was hostile, but I
| am sympathetic to their frustration. I think it is helpful
| to remind product and business leaders that your engineers
| can be great allies in solving hard business problems.
| MajimasEyepatch wrote:
| Also a lot of PMs are former engineers. One could argue a
| person capable of doing both at a high level is "smarter"
| than a person who cannot. Certainly they would have a
| unique perspective compared to people who have only been on
| one side or the other.
|
| But like you said, intelligence is multifaceted, and
| comparing people's intelligence is pointless and divisive.
| rektomatic wrote:
| >very likely your technical people are smarter than your
| product people
|
| I'm guessing you work in the technical side of things?
| [deleted]
| P5fRxh5kUvp2th wrote:
| should I guess you're not and that your sole reason for
| responding is defensiveness in wanting to believe you're
| smarter than software developers?
|
| Or maybe we can try again?
| ButterBiscuits wrote:
| > should I guess you're not and that your sole reason for
| responding is defensiveness in wanting to believe you're
| smarter than software developers?
|
| You can guess that, and honestly it's not even a terrible
| guess. But it makes you a hypocrite. If you're offended
| by someone making this kind of assumption about you,
| reciprocating it isn't going to bring down barriers to
| communication.
|
| > Or maybe we can try again?
|
| You deflected entirely from the comment, which is fine.
| But then why reply at all? It sounds like you just want
| to be defensive.
| bkuehl wrote:
| Our company did a restructuring a couple years ago where the
| web/user-facing part of the dev team was moved under the same
| branch with Product. At first I was skeptical, but it has
| worked out very well. Product Managers and the developers feel
| like they are on the same "team" working toward a better
| product. There's a lot more collaboration with PMs trying to
| get developer input/insight, etc. Things used to be a lot more
| siloed, and I think it really hurt innovation.
| drewbeck wrote:
| This is a really intriguing approach! I can see why it works.
| crazygringo wrote:
| What you're describing is how it's already usually done, from
| what I've seen.
|
| But the PM still reports to a director of product, and the TL
| still reports to director of engineering.
|
| And when the director of product and director of engineering
| have different visions and priorities and criteria for
| promoting, that's the problem described in the article.
|
| And you certainly can't have engineering report to product or
| vice-versa... I've seen both before and it's utter disaster.
| makestuff wrote:
| yeah i was at a startup that had SVP of product and SVP of
| engineering. For the entire year I was there 60% of the time
| was spent in meetings where they just blamed each other.
| Engineering would say product didn't tell us what to build so
| we just built what we thought they wanted and product would say
| they told engineering what to build but they did it
| incorrectly.
|
| The company I am at now has a leader who has product and
| engineering reporting to them for their charter basically
| following the mini-ceo/cto you described. It has its issues but
| works much better than the alternative.
| zingar wrote:
| The leader who has product and engineering reporting to them
| is a CTO. Someone who only does one of those things is not a
| CTO and shouldn't have C-level decision making power.
| ipaddr wrote:
| You needed a project manager SVP reporting to cio to make
| that work with a department for requirements
| chrisabrams wrote:
| Thank you for this it was much appreciated humor during my
| lunch break!
| CSMastermind wrote:
| I disagree but the thing I'd disagree most about is calling
| your product managers a "mini CEO". That exact mistake as led
| to some of the worst product outcomes I've witnessed.
| wobbly_bush wrote:
| Curious, what about that title caused bad outcomes?
| CSMastermind wrote:
| I think it sets the wrong expectations for those product
| managers but in terms of their duties and in terms of
| collaboration with their team members.
|
| I've seen product managers who thought they were _managers_
| actually in charge of the people on the team and this led
| to frustration. OR they thought they were decisions makers
| who had some measure of authority instead of just another
| member of a team with a specific role. In general
| collaboration with
|
| And when I think about the product managers, I've worked
| with who described themselves as "mini-CEOs" they lacked
| basic product management skills. For example: focusing on
| the what over the why, being overly process driven, and
| lacking a cohesive vision for what the product will be long
| term.
|
| I can't tell you correlation-causation here. Whether the
| description of "mini-CEOs" attracts people who are bad at
| product management or whether telling someone their job is
| to be a "mini-CEO" causes them to behave poorly.
| hipppocamp wrote:
| > I think it's often better to divide up the product over many
| separate small teams, each with a product focused "mini CEO"
| and a tech focused "mini CTO".
|
| This only gets you so far. It tends to optimize for speed of
| teams but at the detriment of the overall product.
|
| Eventually you end up with splintering of ideas, terminology,
| duplicate functionality and features that almost work the same
| way. You see it across all big companies and products. AWS is a
| great example of the mess they've made between services and how
| they don't always play well together and you end up with teams
| actually competing as they assert that their product should own
| something that's others shouldn't. I wouldn't be surprised if
| Google is in the same mess (Drive is a fucking cluster of a
| mess and it's basically impossible to use for anything
| productivity related - and don't get me started on how Google
| Classroom works within that ecosystem that's a double yikes).
| Same goes for Atlassian. What's the saying? Don't ship your org
| chart?
| AndreasHae wrote:
| Can you think of any FAANG scale orgs that haven't run into
| having a fragmented product landscape? Maybe there's just a
| hard limit of how much complexity one business unit can
| handle before it stops being able to scale up. With that in
| mind, decentralized teams with tight product+tech
| collaboration seem to be a successful model. Otherwise we
| would probably already have seen an example of a successful
| tech company with centralized product/tech departments.
| Jare wrote:
| The fragmentation issues doesn't need FAANG scale, and is
| already a possibility for any org that scales past 50
| people or so. If a team has the potential to interfere with
| another, or the need to depend on another, you already have
| the primordial soup for conflict and widening cracks.
| kcexn wrote:
| Isn't Apple very successful with centralised product/tech
| departments?
| [deleted]
| vsareto wrote:
| That's usually what happens: assigned product people to
| engineering teams who focus on what the engineering team works
| on, then they report one level higher.
|
| You shouldn't be seeing a new decision-making Product person
| every month or so - that's bad news bears.
|
| It gets to this state naturally if your product is fairly large
| and has loose/well-defined modules that are distinct from one-
| another.
| PragmaticPulp wrote:
| Fortunately, this article isn't either. The second half of the
| article is about breaking down that wall (From the article):
|
| > Eliminating the wall between Product and Engineering is
| essential to establishing high performing product teams.
|
| (Quoting parent post):
|
| > The whole idea of having one branch of the org chart telling
| another what to do is kind of flawed.
|
| Completely agree, and all of these approaches are destined to
| fail if it turns into different branches of the org chart
| fighting with each other.
|
| Most of my issues with separate product orgs have come from
| product executives who feel the product/engineering
| relationship needs to be more of a handoff or prescriptive
| relationship. It's not.
|
| > I think it's often better to divide up the product over many
| separate small teams, each with a product focused "mini CEO"
| and a tech focused "mini CTO".
|
| Whatever you do, don't call them "mini CEO" and "mini CTO".
| This generally implies that the CEO is at the top, which breaks
| the whole collaborative team idea that we're going for in the
| first place.
| spacemadness wrote:
| I'm dealing with this right now and it feels like we're at
| constant war instead of collaborating.
| hackitup7 wrote:
| Early in my tenure running a Product team I decided that one of
| my goals would be for PM/Design and Engineering to be as close as
| possible. I would literally say that I wanted them to view one
| another as brothers/sisters, and tried to set the example that we
| would go to bat for engineering (and expect the same) in almost
| all cases. I think it was probably one of the best organizational
| decisions I ever made.
| mrcwinn wrote:
| I'm a Chief Product Officer at the moment with both experience
| around product design, UX/UXR, product management -- but also a
| very deep software engineering background.
|
| I certainly have some blind spots, but it's a real advantage to
| be able to communicate a cohesive narrative and build "one"
| team (with lots of fantastic disciplines and even, at times,
| some intentional silo'ing). I can describe the why behind our
| prioritization, but also keep in view the strategic engineering
| investments we'll make to support our product vision over the
| long-term. Will it scale forever? Who knows.
|
| But I absolutely believe in fully-integrated product teams. You
| can really ship some amazing work when you get it right.
| ipaddr wrote:
| I have seen cases where pm is close to developers or close to
| the business leaders. Sometimes too close to either group
| excludes the other. A balanced pm is preferred.
| uptownfunk wrote:
| Hard to get right, becomes a mess if you don't. The toxic us vs
| them attitude can quickly take over and jam up any hope of
| progress. Having them on one team is helpful. Also having a
| healthy org culture of no blame games, mistakes are not ideal but
| they happen, and focus on spreading happiness to your customers
| in a sustainable way for everyone also plays a role.
| no_wizard wrote:
| This is part of a whole series[0] that I am reading and finding
| quite insightful.
|
| I think the "pull quote" for me, was this, from the immediate
| article:
|
| _Establish team working agreements at all levels. Ensure every
| team member knows what role they're playing_
|
| I think this is a real problem not just in scale ups, but in a
| lot of engineering organizations. There's no working agreements
| on what roles that each part of the company plays and expects
| others to play, its often weighted against some preference of
| higher up management (often VP / executive / director depending
| on the size of the org and influence each layer has) that creates
| these silos and break downs.
|
| I think its uncommon to think of start up environments like this,
| but it is entirely true, once you get past a certain number of
| employees and start having more delegation layers (directors /
| VPs) you start to run into these silo problems quickly if you
| aren't aware of them or don't actively do something about
| preventing them.
|
| Whole thing is worth reading though, very insightful to me at
| least!
|
| [0]: https://martinfowler.com/articles/bottlenecks-of-scaleups/
| righttoolforjob wrote:
| Bad (and common) engineering managers avoid agreements on
| purpose to:
|
| 1) cover their asses
|
| 2) change anything at will
|
| If you never agreed to anything, then you can keep demanding
| whatever, and blame whoever as well. It's a really shitty
| management style. I left such an organisation not too long ago
| where I would say that the engineering department survived not
| because of, but rather despite of the head of that department.
| First few years nobody had a clue what he was doing most of the
| days and when he decided to get actively involved it was
| obvious he had no clue about anything. He still has no clue but
| he's made sure to surround himself with incompetent yes-sayers
| to cement his position.
|
| A real political genius.
| PragmaticPulp wrote:
| > Leaders should set a principle and expectation of a blameless
| culture. When something goes wrong, it's a wonderful learning
| opportunity, to be studied and used to continuously improve. An
| example of this is the concept of a blameless post-mortem.
|
| I understand this idea. I've read several books on the subject
| and worked to integrate it into several teams now. I think it's
| an admirable goal.
|
| But the blameless culture idea becomes counterproductive when
| taken to extremes. I've been in a couple "blameless cultures"
| where a small number of people were _clearly_ to blame for every
| project falling behind, but every retrospective was about how we
| could have organized our work better, or planned better, or been
| more clear about the expectations. No, at some point, the only
| way we 're going to ship better is to shine some light directly
| at the one poor performer on the team that everyone _knows_ is to
| blame. That doesn 't mean being mean or rude or calling them out
| in public, but something must be done.
| [deleted]
| __turbobrew__ wrote:
| Yea there is a balance between giving engineers power to
| effectively do their jobs and limiting the amount of damage
| they can do. You can put up more guard rails for engineers, but
| it will most likely make it harder to do their job or deal with
| production emergencies. What is also tough is if you have a
| group of highly privileged engineers who can manage not having
| guard rails except for a few cowboys who cause problems. You
| can limit the capabilities of the entire group to deal with the
| cowboys, but then you are making all of the responsible
| engineers less effective.
|
| One solution is to move the cowboys to a position where they
| can do less damage, another is to make the cowboys responsible
| for their repeat offences, or you can just go full up blameless
| and have to deal with outages caused by repeat offenders.
|
| I have seen this in action at my org -- we basically have a
| chaos monkey who is a person. They cause an outage and not even
| a week later they are doing dumb/overly risky actions again.
| prsimp wrote:
| In my experience, there is a thin line between "blameless"
| cultures and "responsibility-less" cultures. Blameless cultures
| accept that we are all human, make mistakes, have off periods,
| etc. "Responsibility-less" cultures are as you describe -- they
| eschew honest conversations about the actual forces that affect
| projects. Instead they tend to repeat the same process
| discussions ad nauseum, typically discussing symptoms rather
| than the actual causes.
|
| Since we as humans often prefer to avoid conflict (sometimes at
| all costs), it's not uncommon to see companies tilt towards the
| latter. This is exacerbated in "scale up" environments when
| rapid personnel changes make it difficult to build the kind of
| trust necessary for direct, honest communication.
| sophrocyne wrote:
| Create a culture where making mistakes is ok, but failing to
| learn from those mistakes is unacceptable.
|
| Not mine - That's a Dalio principle. But one that is very
| sorely needed in many work environments.
| SkyPuncher wrote:
| Yea, that's a culture that lacks any sort of accountability.
|
| When patterns continue to repeat, one of two things needs to
| happen:
|
| * Management recognizes this is a culture/process issue which
| many people are affected by. Management must fix it.
|
| * An individual continues to repeat the same type of error,
| despite having had the opportunity to identify, learn, and
| address it.
| fleddr wrote:
| Too much fluff. Keep it simple.
|
| A good PM can clearly articulate what is to be build and why. In
| my experience, the why is often completely lacking. Zero
| research. Shady A/B tests with unclear conclusions. Pretty much
| the "why" is often somebody deep down in the business emailing a
| random idea. And it seemed cool and people want to please people
| rather than dismiss them.
|
| With a clear and simple goal and why, if you have half-decent
| engaged engineers, they can now _think along_ on how to best
| achieve the goal. This could refine the feature itself, its
| visual design, anything. The idea that product people have
| monopoly knowledge on product is ridiculous.
|
| So with a clear and hardened idea you build it. Then we come to
| the other part that PMs never seem to engage in: feedback.
|
| Did it work? Did anybody use the feature at all? Was the goal
| met? Did we get user feedback? Often lacking as engineers are to
| focus on the new sprint.
|
| Engineers can't grow or feel product ownership if they're so far
| removed from its real world impact.
|
| And as for my second trigger: don't "negotiate" technical debt.
| The idea that it's negotiable is why it won't get done, so make a
| stand and remove room for negotiation. It very much is in your
| power to do so.
| eftychis wrote:
| I think this runs back on "Innovator's Dilemma"[1] and "... they
| didn't think if they should build it."
|
| I say it is also a failure of scaling and power struggle. Because
| you have to have a VP for engineering and a VP of product to show
| to your customers and to your employees right?
|
| As the article does well to point out that backfires in so many
| ways: "engineers get stuck due to lack of context." Imagine the
| market needing a bridge and internally to be playing pantomime on
| "we need a beam I think of x weight..." Try to build a plane that
| way I dare you. Software is fine as you can just convince the
| customer to buy extra hardware.
|
| That sucks of course if you expect to consider your employees as
| resources in a factory chain because of course those models apply
| cleanly to engineering work... (That last sentence was
| sarcastic.) Companies do it because it is cheaper to have people
| multi task in the short term and ticks boxes. That's what kills
| companies so I am fine with that I guess. More companies will
| sprung that will be better hopefully.
|
| 1.
| https://www.goodreads.com/book/show/2615.The_Innovator_s_Dil...
| hinkley wrote:
| > Try to build a plane that way I dare you.
|
| This may be why modern Boeing is so fucked.
|
| source: worked on the 787 program, the hardware for our team
| was selected before there was a team. Our part was only
| successful and on time in large part because I'm a stubborn
| asshole.
| eftychis wrote:
| Thanks for the input! I have only second and third hand input
| from the 787 program so didn't want to imply anything there.
| I hope Boeing fixes that managerial issues leading to what
| you describe as I am a fan of its historical product in
| general. (If I am reading your comments right and I am not
| blinded by my pre-conceptions.)
| hinkley wrote:
| Boeing isn't Boeing anymore, it's McDonnell Douglas wearing
| a Boeing skin suit.
|
| I think that example is slightly tangential to your thrust,
| but sort of illustrates the bigger problem that when a
| project is operating anywhere near the boundaries of
| logistical possibility, it becomes very hard to incorporate
| perspective from the people with boots on the ground, who
| know ten ways to get something done and that your
| suggestion isn't one of them.
|
| It's the same problem General Contractors have with trying
| to herd architects who try to design at the limits of
| materials science and don't understand that there's a large
| gap between physics and execution, where building codes,
| manufacturing defects, and the ravages of time all live.
| Not to mention costs (exotic materials often require exotic
| labor).
| BerislavLopac wrote:
| Stubborn Assholes is the name of my new post-punk trash-metal
| crossover band.
| hinkley wrote:
| The very first figure in this article illustrates one of my pet
| peeves: We see a classic S curve productivity chart and then we
| immediately attribute it to some sort of management failure
| instead of pure unadulterated reality.
|
| As it turns out, the S curve is a plot of the area under a bell
| curve; at the beginning of the project it's hard to get traction.
| At the end it's hard to cross all the T's and dot the i's. Most
| of your velocity comes in the middle, which is why it's so hard
| to plot an intercept.
|
| We usually make the fiction of the intercept into reality by
| accumulating tech debt more quickly. If you're very lucky with
| your engineering culture, you are maintaining the slope of the
| line at the end because you built a culture of competence along
| the way and you are now capable of completing more tasks per unit
| of time than you were at the midpoint, often by sacrificing
| throughput before the midpoint.
| williamcotton wrote:
| The role of "Product Engineer" is a deeper solution to this issue
| that I find appealing.
|
| But let's do away with the term "engineer" almost completely,
| because what the average web application developer is doing is
| hardly engineering. The tools are at the point where most of the
| computer engineering has been abstracted away to the point where
| developers can primarily focus on business logic. Most
| experienced web application developers that I know have already
| been doing product work in their day-to-day routines. People who
| actually write code in direct contact with customers and their
| needs is highly efficient.
|
| Our industry needs an order of magnitude less people who do not
| write code. In my view everyone should be a programmer of some
| sort. Our management tools are programmable yet management will
| not lower themselves to the ranks of the manual laborer and
| instead will choose to hire someone to program their management
| tools for them. This is highly inefficient. I'm sure we would see
| less meetings if management actually had something worthwhile to
| do with their time.
|
| I do see a need for computer engineers in that they should write
| the tools that the other programmers use for these kind of
| domain-specific purposes.
| williamcotton wrote:
| This should in turn reduce not only the layers of management
| but the need for managers to make up for the inefficiencies
| between "person dictating idea" and "person implementing idea".
|
| It's also a sign to me that our tools for product development
| are too general purpose and we would benefit from less capable
| and easier to learn and use DSLs. Those DSLs should at least be
| extendable from in-house computer engineers who do in fact
| worry about things like data storage, CPUs, and memory
| management.
| agomez314 wrote:
| Great insight. Like Hal Abelson said, nowadays it's more of a
| matter of how "you use various kinds of programming styles and
| techniques like combinators to glue things together." This
| lowers the bar to programming to more people, making the excuse
| "i'm not technical" less and less relevant.
| metaquestxyz wrote:
| BerislavLopac wrote:
| My experience in this area boils down to this:
|
| First of all, I think that the title "product manager" is not a
| very good one, and is actively harmful. While it is technically
| correct, the word "manager" in most people evokes the idea of
| managing people, and there is a very short step from there to
| seeing PMs as ones who "manage" everyone involved with the
| product development. "Product owner" is not much better either.
|
| But we don't have a much better term, so PMs it is.
|
| For all practical purposes, the amount of features a software
| product can have implemented is virtually unlimited. In reality,
| features can only be added over time, and the role of product
| managers is to guide the prioritization by making product
| decisions. Long time ago, in a talk at a startup event, I
| compared PMs with the people being quartered in medieval times
| [0]: the product development process is pulled in different
| directions by various "horses" - groups more or less directly
| involved in the development and use of that product, and the PM's
| role is to balance those horses and prevent any one of them of
| dragging the whole thing in its direction. (I have identified
| those horses as, respectively: sales, marketing, end users and
| engineering. This is a common arrangement, but others are
| possible in some environments.)
|
| Ultimately, the PM should have enough understanding of particular
| interests of each of those groups to be able to make informed
| decisions. Sometimes, the priority will be to make the product
| easier to sell (e.g. add this feature this potential customer is
| asking for); at other times, the priority will be to resolve some
| technical debt to make deployment faster; and so on. Obviously,
| that understanding does not come from vacuum; it requires talking
| to the representatives of the all of the "horses" and gathering
| all the necessary information.
|
| In practice, it is common - as some other comments have mentioned
| - for the PMs to succumb to the pressure of the "business" side
| of the equation (sales and marketing). As a technical lead, I
| have always made a point of working together with the PMs and
| help them keep that balance.
|
| [0]
| https://media.hswstatic.com/eyJidWNrZXQiOiJjb250ZW50Lmhzd3N0...
| tikhonj wrote:
| In my ideal world the role would be called something like
| "product developer" with the responsibility to develop and
| articulate a clear vision for the product (with a holistic
| understanding of "product").
| dsmmcken wrote:
| "Product Designer" is becoming a more common role at big
| companies these days, and tends to have a similar role to a
| traditional PMs. Usually from a designer background.
| Jenk wrote:
| Does "Product Lead" evoke similar (negative) thoughts for you?
| I find that title (and anything "... Lead") carries the least
| connotation.
|
| And IME, in an org that has PLs, PM becomes "one who manages
| PLs" - otherwise, if there are PMs but no PLs, I get the
| impression they are mostly Project Managers, rebranded to
| Product Managers, but without any of the Product responsibility
| or thought.
| BerislavLopac wrote:
| Yes, "Product Lead" does feel much better. +1
| [deleted]
| wobbly_bush wrote:
| > at other times, the priority will be to resolve some
| technical debt to make deployment faster; and so on
|
| It's interesting you mention this. In my experience, PMs have
| only owned end-user experience, they come up with end-user
| project prioritization. The consolidation of asks from various
| departments was instead done by dev managers/directors/VPs. So
| for example, a dev manager decides between a customer-facing
| feature and some tech debt to make deployments faster -
| contrasting short term deliverables with long term velocity of
| the team.
| BerislavLopac wrote:
| > they come up with end-user project prioritization
|
| Then they have failed from the beginning. Technically,
| _everything_ you do affects end-users - including faster
| deployments - although in some cases that effect is more
| obvious than in others.
|
| In a perfect world, each product (or, in a complex system, a
| well defined subset of features within a product) should have
| a dedicated representative of each of the "horses", who
| should agree on the priorities - with the product lead (thank
| you @Jenk!) guiding the process and helping resolve the
| conflicts.
| wobbly_bush wrote:
| > Technically, everything you do affects end-users -
| including faster deployments - although in some cases that
| effect is more obvious than in others.
|
| I agree with this. This is why the dev
| managers/directors/VPs own the _delivery_ of the business
| goals for the year. They balance the customer-facing
| improvements with internal improvements which affect
| development velocity (deployments, ops, how easy is it for
| new employees to onboard onto a code base, how easy is it
| for someone with <2 years experience on a codebase to ship
| a feature, etc.).
|
| So PMs in collaboration with dev managers own _what_
| customer-facing improvements to deliver, and the
| responsibility of _how_ to deliver and the actual delivery
| falls on the dev managers.
|
| I'm not proposing this as a new model, I'm saying this is
| what I've seen been followed in some companies.
| sdevonoes wrote:
| Product developer (or Product Engineer since we use the word
| engineer everywhere). Compare team A = {software engineer,
| product engineer, design engineer, qa engineer}, and team B = {
| software engineer, product manager, design engineer, qa
| engineer }. Team A screams "all team members collaborate the
| same way when it comes to build a product". Team B screams
| "there is 1 manager, and the rest are not"
| iancmceachern wrote:
| I've seen it work, and I've seen it not work a lot.
|
| The key to getting it to work is to build an environment, a
| culture, where the product testing and feedback is baked into the
| process and communicated directly to the engineers and designers
| doing the work.
|
| It looks a lot like a race team building and operationalizing a
| new racing platform. The movie ford vs Ferrari captures it well.
| Pragmatically in what I do (design medical devices and robotics)
| it looks like regular "labs" where you test your prototype
| product in real world conditions, gather feedback, and iterate
| the design based on that feedback. It doesn't work when those
| functions are siloed. I.E. The lab people run the lab in a
| vacuum, write up theor findings, send them up through their
| management then back down through engineering management then to
| the individual designers. This doesn't work, it's like the game
| of telephone, the end is never what was initially communicated.
|
| What works is to entrench those two together. The designers doing
| the work attend and are part of the labs. They know first hand
| what to do and why. It cuts out the miscommunication and also
| cuts out 50% of the needless work and meetings.
| ng12 wrote:
| I've become pretty skeptical about "Product Management" as a
| function. I feel like it's one of those ideas that's cargo-culted
| from Google without anywhere near the same rigor.
|
| A good product person is worth their weight in gold but holy hell
| there are a lot of charlatans out there. These days I prefer to
| work at companies without PMs, as an engineer the odds simply
| don't work in your favor.
| zingar wrote:
| So much snake oil. So many people have "shifted from product
| owner to product management", but I've yet to meet anyone who
| can tell me the difference.
| VinLucero wrote:
| Fair discourse: I have worked at Google, Credit Karma and now
| Sivo (YC W21) as a (technical) program and product manager.
|
| I know for a fact that Google doesn't actually have "Product
| Owner" as a role in their org chart.
|
| At Google, the separation is:
|
| Product Manager (Vision), which is focused on gathering
| business needs and driving the Feature Roadmap.
|
| Program Manager (Execution), which focuses on finding ways to
| unblock delivery of the vision with cross-functional teams,
| such as getting designs, legal approvals, etc.
|
| I recently experienced a Product Owner for the first time
| when hiring one at Sivo (YC W21).
|
| It seems like Product Owners exist to accelerate the Roadmap
| vision into Epics and Stories in solutions like JIRA so
| product visions are more actionable by engineering.
|
| Similarly, while not a role at Google, I have heard that some
| MegaCorps will have "project managers" that often report up
| into Program Managers. This is similar to the product owner
| and product manager relationship.
|
| Hope that helps!
| ketzo wrote:
| How do Engineering Managers work alongside those two roles?
| singron wrote:
| This is how you end up with 8 bosses like in office
| space. EM, TL, ATL, PM, PgM are all telling you what to
| do and asking for status updates. I wish there was
| someone to liase and multiplex all that, but I think they
| all think that's what their job is.
| cbsmith wrote:
| Product Management certainly predates Google by at least a
| generation. Indeed, Google is notoriously skeptical on the
| product management role and requires their product managers to
| have a technical background to at least some degree.
| extantproject wrote:
| https://archive.ph/tAAhH
___________________________________________________________________
(page generated 2022-10-18 23:00 UTC)