I don’t know Ben’s background, though I see his current role as a senior PM at GitHub. I also work with PMs in the heart of the bay - have done the PM role, have run operations across a few companies, and have presently returned to engineering.<p>I think this characterization of engineers is off, and in a way that appears to inflate the value of the PM role. It’s taken from (a PM’s) ideal perspective of himself, where he is the gatekeeper to the business knowledge of the organization. They know the “why” and the engineer knows the “how”.<p>Now maybe at a huge organization, this ideology gets entrenched - but at companies smaller than (let’s say from experience) 300 people, this is neither correct nor best.<p>What’s best - I believe - is the increasingly popular concept of “product-minded engineer”. And, while I’ve not seen it coined, I’ll introduce “engineering-minded pm”.<p>What’s the difference? A lack of knowledge hoarding, healthier knowledge transfer and decision making, and reduced waste. I’m not even going to think or talk about increased velocity, just reducing the waste will naturally increase focus and take care of many other problems.
It seems like every PM has a slightly different job from every other PM, even at the same company. Across companies there's absolutely no comparison.<p>What I've noticed at Google is that through a combination of personality and bureaucratic convenience, the PMs have taken over completely. I like the PMs I work with so this is not necessarily a bad thing, but I don't think it was intentional. When we're trying to launch a feature or make a big product change everyone just accepts that the PMs word on if/when we will do it is law. If we disagree with the PM we simply escalate to a more senior PM. I don't think it was meant to be this way, but nobody else is empowered to make these kinds of decisions so it falls to the PMs by default. Plus they tend to be very well connected across the company because they work with everyone, so they can make things happen.
<i>>> customer comes to you asking for a 1/4” drill (a solution). Their stated problem may be the need for a 1/4” hole, but what they’re really after is the ability to hang a picture </i><p>Yes, this. I began delivering much better solutions when I began incorporating, "okay, I can build that, but what do you want to <i>do</i> with it?" at the very beginning of any requests I receive. I'd say it's about 50/50 on whether the initial request would would meet the desire completely, or fail in part or in whole.
“Customer Analyst” is a much better title for the role held by “Product Managers”.<p>More than anything engineers need to understand the customer needs. The title “Product Manager” creates confusion that this person should own product features, which is a dysfunction because the skillset to collect data on customers is fairly disjoint from the ability to make design tradeoffs.<p>It would also emphasize how time should be spent - actually talking to customers - rather than mostly negotiating detailed waterfall specifications that usually trail (not guide) actual product development
Building a solution in search of a problem might be the classic engineering pitfall, but reading the title made me think about the flip side of that.<p>Is finding problems in search of a solution the classic PM pitfall? I’ve seen more than a few products suffer from feature bloat and inevitably collapse under a lack of design and UX cohesiveness.<p>I can’t say I’ve reached product sense zen, but I imagine it lies somewhere in between these 2 extremes. Meaning, being okay with ‘finishing’ products, but having the intuition to find and work on the next high-impact product.
I'm a few years into this Product Manager journey, and I think this is the level 1 of Product. The basics are to focus on the pain and customer need instead of just grooming features that come in and delivering those features. If you have trouble with this, I like to use a focus / flare / focus model. First think through your solution (privately) and list out the benefits and drawbacks in terms of your user experience / needs. Then double down on imagining your user interactions and actually go talk to them about the idea. Pay a lot of attention to where their reality and your assumptions don't align. Be very curious. Then with that new grooming of the customer experience, focus on how to communicate the meaningful pain points to your engineering team. If needed, you can even walk them through the journey you took. At the end of the day, the more you can get them to empathize with your chosen customer, the fewer blindspots they will have and the better their intuitive solves will be.
I've definitely seen some examples of over-technically focused engineers, but this piece goes too far to portray engineers as hapless sheep that need to be herded into a useful business purpose, lest they wander too far into an interesting technical problem and never return. Establishing problem requirements and definitions is something every engineer is trained to do and is really not such a difficult thing to do, but once that's done it's no longer the primary job focus.
By understanding the problem, you can bring multiple people together to figure out how to solve it. We all have different skillsets and sometimes the best solution isn't in our skill set or is a combination of skill sets.<p>I see this with my boss. He always brings feature request to me and we have to work backward to get to the problem. Then we usually come up with a simpler solution once we understand the problem.
"...given a sufficiently defined problem, the solution is often the easy part...The real challenge lies in understanding customers’ true needs"<p>When is the problem every sufficiently defined?<p>I disagree that the “real challenge” lies in understanding customers' "true needs". In my experience the customer and their needs are exceptionally easy to define, and the product managers (often times) over analyze the situation causing more difficulty which inevitably delays solutions.<p>I agree that customers rarely know what they want or need, in detail. However, imho the development team is perfectly capable of understanding what they actually want/need inherently or with minimal training. That’s not to say that product management isn’t necessary because it is, but is it more important to be able to suss out the minutia pertaining to the differences between two relatively equal and acceptable solutions than it is to provide a service? I think not.