11 ms·

Product vs. Engineering

232 points by kiyanwang 4y ago

no_wizard 4y ago
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/ https://martinfowler.com/articles/bottlenecks-of-scaleups/
- righttoolforjob 4y ago
  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.
hackitup7 4y ago
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 4y ago
  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 4y ago
  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.
bjornsing 4y ago
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”.
- makestuff 4y ago
  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.
  - ipaddr 4y ago
    You needed a project manager SVP reporting to cio to make that work with a department for requirements
    - chrisabrams 4y ago
      Thank you for this it was much appreciated humor during my lunch break!
  - zingar 4y ago
    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.
- P5fRxh5kUvp2th 4y ago
  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.
fdgsdfogijq 4y ago
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.
- mkl95 4y ago
  > 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 4y ago
    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 4y ago
  > 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.
williamcotton 4y ago
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 4y ago
  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 4y ago
  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.
- 93po 4y ago
  You may have had the pleasure of working at places where developers are very self-directing and don't need constant hand holding. As an engineer (developer) of more than a decade that has since transitioned to product, my experience is that developers (again, just in my experiences) at places I've worked are entirely are completely incapable of knowing what to build. They don't ask the right questions and they don't understand the business needs well enough to know the right solutions. They get stuck at the smallest hurdles and I have to guide them over each and every one of them, even when it's 98% a technical problem (which legacy database should this application be populating? I don't know, let's ask the PM instead of consulting technical documentation or running our own profiling to determine this). They don't want to make decisions around anything at all. Managing questions and making decisions for a team of 6 is easily a full time job for me combined with client management and meetings. I work a lot of extra hours to do actual PM work on top of that. I realize this is also largely my organization's fault for not having a dedicated project manager, but that's still not really helping me see your argument about needing fewer non-coders.
PragmaticPulp 4y ago
> 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.
- prsimp 4y ago
  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 4y ago
  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 4y ago
  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.
eftychis 4y ago
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_Dilemma https://www.goodreads.com/book/show/2615.The_Innovator_s_Dil...
- hinkley 4y ago
  > 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 4y ago
    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 4y ago
      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).
hinkley 4y ago
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.
BerislavLopac 4y ago
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/eyJidWNrZXQiOiJjb250ZW50Lmhzd3N0YXRpYy5jb20iLCJrZXkiOiJnaWZcL0RyYXduLVF1YXJ0ZXJlZC0xLmpwZyIsImVkaXRzIjp7InJlc2l6ZSI6eyJ3aWR0aCI6ODI4fSwidG9Gb3JtYXQiOiJhdmlmIn19 https://media.hswstatic.com/eyJidWNrZXQiOiJjb250ZW50Lmhzd3N0...
- tikhonj 4y ago
  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").
metaquestxyz 4y ago
uptownfunk 4y ago
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.
iancmceachern 4y ago
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 4y ago
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 4y ago
  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 4y ago
    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 4y ago
      How do Engineering Managers work alongside those two roles?
      - singron 4y ago
        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.
zingar 4y ago
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.
extantproject 4y ago
https://archive.ph/tAAhH https://archive.ph/tAAhH
javier_e06 4y ago
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 4y ago
  [deleted]
fleddr 4y ago
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.
- danielmarkbruce 4y ago
  It's harder that it seems to figure out what to do - because many orgs don't give PMs enough time to focus on that part of the job. Mostly because research can be weeks of no outcomes - just research research research. Most product managers know they don't know the market as well as they should and they face enormous pressure to "get things done".
  - fleddr 4y ago
    Those are fair counter points. Another issue is the lack of political capital. Very often a product "owner" doesn't own much at all. Some may have reasonable decision power but it's constantly undermined by powerful other stakeholders. The problem often starts from the very top. Say a CEO tells the business to grow revenue by 20%. The business/markets then come up with terrible ideas to do that. Aggressive, cutting corners, user-hostile, but likely to work in the short term. Then they ask the PM to implement it. You can't stop it at this point.
hemloc_io 4y ago
Here's a different twist on these issues that I don't think comes up all that much. (B/c it's pretty niche). How do you deal conflict between product engineering teams <-> Infra Engineering teams. Particularly when Product Engineering teams have product managers and the ability to say, business impact is X while infra teams don't. It's a pretty difficult nut to crack at least at my current org, because the near term goals (usually) align, but longer term goals separate out. Eventually the product team becomes parasitic and destroys the infra team. From what I can tell looking at orgs like this, usually the eng team picks up the slack of bouncing tasks as much as possible to keep up. (But all the extra work slows things down.) E.g. Product team wants to build feature X, their PMs and managers all line up to say it should be in Infra, infra team says no, but then leadership vetos it because it's the only way to keep the product team on track. (Because they have the most influence in management.) This happens two or three times, the infra team is now fighting over piles of technical debt in order to get things out, and can't work on new features to attract new customers to keep the current one happy. (and justify their existence.) maybe I should write a blog post about this?
- quickthrower2 4y ago
  This is a specific version of the more general "management doing something I think is sub-optimal, how do I change their mind...".
lucasyvas 4y ago
The issue has been and always will be that if you only let Product determine the what, the wrong thing will be built almost one hundred percent of the time. They lack the ability to describe the "what" in a way that's practically achievable. The exact same problem exists with Design. These people are good at their jobs, but only if they have the humility to admit that they should not be defining requirements on their own. Development, Product, and Design require an equal voice and agreement on direction for all endeavours. Win together, lose together. If Product don't include me in requirements gathering at all, it's their fault when it falls apart. That's hubris. It's equivalently my fault if I don't engage them. Engineering should never agree to build anything they didn't have a say in because they actually build it and can find problems with the "what" that were never even dreamt of. Equivalently, the best Product people I've worked with have always had a good idea I hadn't thought of. Positioning one group to have final authority is a fatal mistake. The final authority already exists naturally - it's cost/benefit/time.
hemloc_io 4y ago
Ah product teams. I'd be convinced it is a jobs program for overqualified ivy league grads, and as a SWE I thought that for a while, but a GREAT product and/or project manager is worth their weight in gold. That being said most of them I've worked with in FAANG/FAANGlike are meh to terrible. Product really suffers from the worst part of being a manager, where you don't control the outcome of other people's work, with the ability to blame shift a lot easier than being a manager since you're managing a product not people. This also makes them super mercurial and since they can move around a lot. It's doubly an issue, bc a good/great engineering team can compensate for dumb product decisions or timelines with crunch and overtime that destroys the team. Product manager can say see what a good job I did, and then dip to another team before any of the consequences are realized. They end up doing tons of useless CYA type stuff that gunks up the works under tight deadlines. 90% of PMs I've worked with paid lip service to "unblocking" you, but at best would function as an email relay. That said, great PMs are fucking fantastic at large orgs. Project managers: know who to talk to, when to escalate quickly, get everyone on the same page including bad managers, unblock engineering by dealing with all the status update bullshit. Build reasonable timelines, fight scope creep, hold people accountable, and do reasonable amounts of CYA to make disputes quick. Product managers: Do fantastic market research w/ rigorous testing, constantly talking to users, building a consensus on the team on the product vision instead of just throwing commandments to the engineers. Focuses on the important features that drive impact instead of throwing the kitchen sink in there, takes feedback from engineering on the product, and pulls everyone's work into the view of leadership. EDIT: One more critical thing PMs should do is be able to get tradeoffs and make a business decision. Under a tight deadline should we prioritize the feature working w/ constraints or delay further. Maybe another blog post.
- ninkendo 4y ago
  > 90% of PMs I've worked with paid lip service to "unblocking" you, but at best would function as an email relay. Too true. And it’s even worse on the receiving end, because all too often this “unblocking” is basically just adding an @-mention to you in Slack with zero context (hope you enjoy reading a 200-message slack thread trying to understand the context!) or just adding you as a CC to an already extremely long email thread (again with no summary of what’s being asked, hope you enjoy reading 100 levels of indented quotes figuring wtf it is they even want.) All this ends up amplifying confusion… a problem can go from 99% solved and only needing a question from another team, to several meetings where everyone’s confused, all because of miscommunication that is made worse by the very PM’s that are supposed to be helping the matter. If you can’t tell, I’ve never met or had a good PM in my life. Not one.
ketralnis 4y ago
I think we've settled on the wrong model for product management, and it's serving us poorly both at our companies and even as a society. Everything you hate about name-a-tech-company is because some product manager's bonus depends on them getting something from you that isn't what you want to actually do. I don't have a better answer, I sure as heck shouldn't be planning product strategies for the web companies I've worked for. But this isn't it.
ejfkcisodk 4y ago
Why do so many companies separate product and engineering if it creates all these problems? In my experience it works better when engineers report to product engineering managers. The only trade off is that you have to find engineers who have good product opinions, and product managers who the engineers actually want to be managed by - which helps you execute, anyway.
awill88 4y ago
Already lost me at attempting to introduce the material highlighting trust issues at a startup.. like who can “boil it down” with a group of humans as tiny as a startup’s typical size? Product and Engineering? The pretentious tone knows no bounds.. Is that even worth talking about businesses at that stage? Lame. And come on, like he’d be in touch with the scrappy startup vibe at this point knowing what he would charge for consulting.. No thanks!
mruniverse 4y ago
It feels hopeless because I don't think their incentives align. The PMs want to get features out asap. Test out ideas asap. They want to get new work into production. The engineers want to build features that are well thought out, low maintenance. This takes time. PMs can get engineers excited and get them to want to work quickly and worry about the little stuff later. The problem is the little stuff that needs to be fixed never seems to become a priority because the next new feature needs to go out. But only the engineers are responsible for the fixing.
sidcool 4y ago
Hacker News has a general disdain for any specialized non-technical power centres in an org.
thenerdhead 4y ago
Articles like this tend to get into theory rather than what is practical. Yes, organizations get stuck measuring their successes by outputs rather than outcomes. Yes, they ship features without stopping to see if real value is being delivered to users. Yes, they panic when they see market share dropping because of it. A PM's job is rather simple. To understand both the business and the customer to identify the right opportunities to produce value. Most people would benefit more by getting out of the building and talking to their customers rather than theorizing ideal functional org structures.
esel2k 4y ago
Senior Product Manager here - let me tell you it is a horrible job to do well and a constant battle (customer, politics, management, engineering, Ux, money etc) I believe more in the PM, UX Lead and Tech Lead trio and very good collaboration. All this « mini CEO » are clickbait articles - in the end a successful PM can lesd while getting constructive feedback and saying no when necessary. Unfortunately few organisations are willing to put the money into training product and product-mindset into an organisation which is one of the main reason for failure IMHO.

232 points by kiyanwang 4y ago

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/ https://martinfowler.com/articles/bottlenecks-of-scaleups/

righttoolforjob 4y ago
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.

hackitup7 4y ago

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 4y ago
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 4y ago
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.

bjornsing 4y ago

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

makestuff 4y ago
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.
- ipaddr 4y ago
  You needed a project manager SVP reporting to cio to make that work with a department for requirements
  - chrisabrams 4y ago
    Thank you for this it was much appreciated humor during my lunch break!
- zingar 4y ago
  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.
P5fRxh5kUvp2th 4y ago
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.

fdgsdfogijq 4y ago

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.

mkl95 4y ago
> 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 4y ago
  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 4y ago
> 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.

williamcotton 4y ago

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 4y ago
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 4y ago
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.
93po 4y ago
You may have had the pleasure of working at places where developers are very self-directing and don't need constant hand holding. As an engineer (developer) of more than a decade that has since transitioned to product, my experience is that developers (again, just in my experiences) at places I've worked are entirely are completely incapable of knowing what to build. They don't ask the right questions and they don't understand the business needs well enough to know the right solutions. They get stuck at the smallest hurdles and I have to guide them over each and every one of them, even when it's 98% a technical problem (which legacy database should this application be populating? I don't know, let's ask the PM instead of consulting technical documentation or running our own profiling to determine this). They don't want to make decisions around anything at all. Managing questions and making decisions for a team of 6 is easily a full time job for me combined with client management and meetings. I work a lot of extra hours to do actual PM work on top of that. I realize this is also largely my organization's fault for not having a dedicated project manager, but that's still not really helping me see your argument about needing fewer non-coders.

PragmaticPulp 4y ago

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

prsimp 4y ago
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 4y ago
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 4y ago
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.

eftychis 4y ago

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_Dilemma https://www.goodreads.com/book/show/2615.The_Innovator_s_Dil...

hinkley 4y ago
> 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 4y ago
  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 4y ago
    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).

hinkley 4y ago

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.

BerislavLopac 4y ago

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/eyJidWNrZXQiOiJjb250ZW50Lmhzd3N0YXRpYy5jb20iLCJrZXkiOiJnaWZcL0RyYXduLVF1YXJ0ZXJlZC0xLmpwZyIsImVkaXRzIjp7InJlc2l6ZSI6eyJ3aWR0aCI6ODI4fSwidG9Gb3JtYXQiOiJhdmlmIn19 https://media.hswstatic.com/eyJidWNrZXQiOiJjb250ZW50Lmhzd3N0...

tikhonj 4y ago
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").

metaquestxyz 4y ago

uptownfunk 4y ago

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.

iancmceachern 4y ago

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 4y ago

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 4y ago
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 4y ago
  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 4y ago
    How do Engineering Managers work alongside those two roles?
    - singron 4y ago
      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.

zingar 4y ago

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.

extantproject 4y ago

https://archive.ph/tAAhH https://archive.ph/tAAhH

javier_e06 4y ago

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 4y ago
[deleted]

fleddr 4y ago

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.

danielmarkbruce 4y ago
It's harder that it seems to figure out what to do - because many orgs don't give PMs enough time to focus on that part of the job. Mostly because research can be weeks of no outcomes - just research research research. Most product managers know they don't know the market as well as they should and they face enormous pressure to "get things done".
- fleddr 4y ago
  Those are fair counter points. Another issue is the lack of political capital. Very often a product "owner" doesn't own much at all. Some may have reasonable decision power but it's constantly undermined by powerful other stakeholders. The problem often starts from the very top. Say a CEO tells the business to grow revenue by 20%. The business/markets then come up with terrible ideas to do that. Aggressive, cutting corners, user-hostile, but likely to work in the short term. Then they ask the PM to implement it. You can't stop it at this point.

hemloc_io 4y ago

Here's a different twist on these issues that I don't think comes up all that much. (B/c it's pretty niche). How do you deal conflict between product engineering teams <-> Infra Engineering teams. Particularly when Product Engineering teams have product managers and the ability to say, business impact is X while infra teams don't. It's a pretty difficult nut to crack at least at my current org, because the near term goals (usually) align, but longer term goals separate out. Eventually the product team becomes parasitic and destroys the infra team. From what I can tell looking at orgs like this, usually the eng team picks up the slack of bouncing tasks as much as possible to keep up. (But all the extra work slows things down.) E.g. Product team wants to build feature X, their PMs and managers all line up to say it should be in Infra, infra team says no, but then leadership vetos it because it's the only way to keep the product team on track. (Because they have the most influence in management.) This happens two or three times, the infra team is now fighting over piles of technical debt in order to get things out, and can't work on new features to attract new customers to keep the current one happy. (and justify their existence.) maybe I should write a blog post about this?

quickthrower2 4y ago
This is a specific version of the more general "management doing something I think is sub-optimal, how do I change their mind...".

lucasyvas 4y ago

The issue has been and always will be that if you only let Product determine the what, the wrong thing will be built almost one hundred percent of the time. They lack the ability to describe the "what" in a way that's practically achievable. The exact same problem exists with Design. These people are good at their jobs, but only if they have the humility to admit that they should not be defining requirements on their own. Development, Product, and Design require an equal voice and agreement on direction for all endeavours. Win together, lose together. If Product don't include me in requirements gathering at all, it's their fault when it falls apart. That's hubris. It's equivalently my fault if I don't engage them. Engineering should never agree to build anything they didn't have a say in because they actually build it and can find problems with the "what" that were never even dreamt of. Equivalently, the best Product people I've worked with have always had a good idea I hadn't thought of. Positioning one group to have final authority is a fatal mistake. The final authority already exists naturally - it's cost/benefit/time.

hemloc_io 4y ago

Ah product teams. I'd be convinced it is a jobs program for overqualified ivy league grads, and as a SWE I thought that for a while, but a GREAT product and/or project manager is worth their weight in gold. That being said most of them I've worked with in FAANG/FAANGlike are meh to terrible. Product really suffers from the worst part of being a manager, where you don't control the outcome of other people's work, with the ability to blame shift a lot easier than being a manager since you're managing a product not people. This also makes them super mercurial and since they can move around a lot. It's doubly an issue, bc a good/great engineering team can compensate for dumb product decisions or timelines with crunch and overtime that destroys the team. Product manager can say see what a good job I did, and then dip to another team before any of the consequences are realized. They end up doing tons of useless CYA type stuff that gunks up the works under tight deadlines. 90% of PMs I've worked with paid lip service to "unblocking" you, but at best would function as an email relay. That said, great PMs are fucking fantastic at large orgs. Project managers: know who to talk to, when to escalate quickly, get everyone on the same page including bad managers, unblock engineering by dealing with all the status update bullshit. Build reasonable timelines, fight scope creep, hold people accountable, and do reasonable amounts of CYA to make disputes quick. Product managers: Do fantastic market research w/ rigorous testing, constantly talking to users, building a consensus on the team on the product vision instead of just throwing commandments to the engineers. Focuses on the important features that drive impact instead of throwing the kitchen sink in there, takes feedback from engineering on the product, and pulls everyone's work into the view of leadership. EDIT: One more critical thing PMs should do is be able to get tradeoffs and make a business decision. Under a tight deadline should we prioritize the feature working w/ constraints or delay further. Maybe another blog post.

ninkendo 4y ago
> 90% of PMs I've worked with paid lip service to "unblocking" you, but at best would function as an email relay. Too true. And it’s even worse on the receiving end, because all too often this “unblocking” is basically just adding an @-mention to you in Slack with zero context (hope you enjoy reading a 200-message slack thread trying to understand the context!) or just adding you as a CC to an already extremely long email thread (again with no summary of what’s being asked, hope you enjoy reading 100 levels of indented quotes figuring wtf it is they even want.) All this ends up amplifying confusion… a problem can go from 99% solved and only needing a question from another team, to several meetings where everyone’s confused, all because of miscommunication that is made worse by the very PM’s that are supposed to be helping the matter. If you can’t tell, I’ve never met or had a good PM in my life. Not one.

ketralnis 4y ago

I think we've settled on the wrong model for product management, and it's serving us poorly both at our companies and even as a society. Everything you hate about name-a-tech-company is because some product manager's bonus depends on them getting something from you that isn't what you want to actually do. I don't have a better answer, I sure as heck shouldn't be planning product strategies for the web companies I've worked for. But this isn't it.

ejfkcisodk 4y ago

Why do so many companies separate product and engineering if it creates all these problems? In my experience it works better when engineers report to product engineering managers. The only trade off is that you have to find engineers who have good product opinions, and product managers who the engineers actually want to be managed by - which helps you execute, anyway.

awill88 4y ago

Already lost me at attempting to introduce the material highlighting trust issues at a startup.. like who can “boil it down” with a group of humans as tiny as a startup’s typical size? Product and Engineering? The pretentious tone knows no bounds.. Is that even worth talking about businesses at that stage? Lame. And come on, like he’d be in touch with the scrappy startup vibe at this point knowing what he would charge for consulting.. No thanks!

mruniverse 4y ago

It feels hopeless because I don't think their incentives align. The PMs want to get features out asap. Test out ideas asap. They want to get new work into production. The engineers want to build features that are well thought out, low maintenance. This takes time. PMs can get engineers excited and get them to want to work quickly and worry about the little stuff later. The problem is the little stuff that needs to be fixed never seems to become a priority because the next new feature needs to go out. But only the engineers are responsible for the fixing.

sidcool 4y ago

Hacker News has a general disdain for any specialized non-technical power centres in an org.

thenerdhead 4y ago

Articles like this tend to get into theory rather than what is practical. Yes, organizations get stuck measuring their successes by outputs rather than outcomes. Yes, they ship features without stopping to see if real value is being delivered to users. Yes, they panic when they see market share dropping because of it. A PM's job is rather simple. To understand both the business and the customer to identify the right opportunities to produce value. Most people would benefit more by getting out of the building and talking to their customers rather than theorizing ideal functional org structures.

esel2k 4y ago

Senior Product Manager here - let me tell you it is a horrible job to do well and a constant battle (customer, politics, management, engineering, Ux, money etc) I believe more in the PM, UX Lead and Tech Lead trio and very good collaboration. All this « mini CEO » are clickbait articles - in the end a successful PM can lesd while getting constructive feedback and saying no when necessary. Unfortunately few organisations are willing to put the money into training product and product-mindset into an organisation which is one of the main reason for failure IMHO.