31–40 of 370 posts
More than a dozen years in tech have taught me that roles are simply ways of expressing organizational wishes. You want someone who thinks about something as a product? You open a PM position. You want a team lead? Here's an EM position. Job titles are elements of fiction that allow us to play that RPG called work under different angles. What you ultimately bring to work is your unique mix of talents and experience.…
Meh, the article's solution smells like great man theory. > Tremendous people envision alternative realities, fully commit themselves to their work, and move mountains with their willpower. The last part is so reductive. It's not willpower moving mountains. It's the underlings actually making the vision come to pass. At most the "great person" is aligning the incentives to motivate the actual doers and experts.
I think it goes one step too far and throws the baby, the bath tub, and the whole house with the bathwater.
> Do you know what else they had in common? None of them were motivated by OKRs, KPIs, data, or other people’s opinion.
This is not true for Bezos for example. He was famously driving the company through data, metrics and process, and there's countless examples of "Jeff meetings" where he changed his mind after reading the data presented by others.
All those examples are tools, that you can, and often shouldn't use. It makes no sense to have a heavy process when you're small, in direct touch with the customer, and are fully driven by an idea. Similarly, it makes no sense keeping on wet-fingering it and single-person driving once you have a set of established customers and want to increase your penetration.
Same is true for all aspects of a company, from engineering to sales to marketing. As you grow you get more people working, and you need a minimum of coordination and standardization to avoid going in antagonistic positions all over. And same goes with seems between these functions. Let me tell you that I prefer having a good PM to handle these needs and that coordination rather than having to deal with synchronizing their needs as an engineer.
I went in there hoping I would have a good resource to share about the topic, but it's too sour and mono-directed into some weirdly "aw common just be smart about it" to be credible. Ironically, the conclusion of the article (no structure, just smart people everywhere) contradicts one of its central argument (everything doesn't apply everywhere).
It sets up a strawman of "delegating control to a single person", and assuming that person is either an engineer or a PM. Everywhere I've worked, the product teams/leaders and engineering teams/leaders were peers. Engineering didn't report to product, and product didn't report to engineering. Rather, both reported directly to the CEO, often as separate CTO and CPO heads, or they both reported to an executive VP or director or similar.
Because the reality is, you need both. Engineers are great at building but they're not spending time with customers or UX research to know what the market and users need. The main job of a PM is to understand what the market and users need by spending a lot of time with customers and researchers, and to marry that with the business priorities coming from executives. And then a PM and eng lead negotiate back and forth to figure out what can be built that meets everyone's needs.
The idea that a product manager role is a mistake makes as much sense as saying an engineering lead role is a mistake, or a sales lead is a mistake, or a marketing manager is a mistake. A successful business needs all parts.
(Occasionally you're building a product that's by developers for developers, where the engineers do have an accurate understanding of users/market, and a PM isn't necessary. But that's exceedingly rare.)
> You hire everyday great people. Each one needs to be great at something, obsessed by their craft, and driven by quality. You then put them together in a team, without individual responsibilities, ensuring that there’s minimal overlap in areas of greatness. My current company is full of smart people, and (for a variety of reasons) we don't have product managers. It sucks . What happens is that the things a PM does d…
Ah, so that's what a product manager is supposed to do. When product managers were introduced at a company I worked at, they did very little of any of that. They certainly weren't speaking to customers. They weren't technical, so they weren't managing our Jira tickets. And "managing leadership" fell mostly on our managers' plates. I think the PMs mostly had meetings, talked to leadership, talked to engineers, wrote documents, and presided over the (now very long) sprint planning meetings.
I can imagine product managers that did your list of things being a lot more valuable.
That way you don't have "product" people who are really just status reporting for the team, or "product" people who are really just writing bad tickets that need rewriting. You have actual product people who focus on where the product should be going.
You also don't have a "delivery manager" role. The team needs to be steered into doing this by a decent lead who can do the 3% admin required to keep on top of this sort of thing.
It's a fairly harsh take, as a whole, but there's parts of this that absolutely ring true. Once you get that "product org" in a company, it tends to progress the way the author describes, with committees and OKRs and review cycles and planning and a lot of bureaucracy. I took, naively, a product manager job at one place I worked, thinking it would finally give me formal control over the product that I'd been previous…
My normal month has always consisted of creating anywhere from four to twelve unique proposals (PRDs) for new features for the company to build, with the number created varying based on the size of the company and the amount of process needed as a result. But regardless, it has always looked like: "Our users currently have X problem, and we should build Y to solve it. Y looks like this...". Yes this comes with some coordination and communication challenges, but those are always in service of figuring out what to build next.
I understand not all PM roles are like this, but I do disagree that PM never gets better than "sorting/filtering/decision maturity theatre". I am curious: if you were simply ordering an existing backlog, who was defining the new items to add to the backlog?
I do agree with the red-flag symptoms like KPI and other “measurements”, and I’ll go as far as to say it’s extremely difficult to find a great PM and the field is riddled with mediocre ones.
In my several decades of software engineering work, good product managers were almost non-existent.
Today I’m working with one who has a strong competitive streak, is quite smart, and deeply understands our users and competition.
I’ve been making sure to give her stellar feedback during reviews and peer feedback, as I know how rare this combination is.
Edit: Reading through the responses, perhaps I should reconsider. The expectation of the role and responsibilities are misunderstood and misaligned to what businesses and engineering teams actually need.
That is to say, my team PM’s a success despite the role and not because of it.