Comment by mharroun | Hacker News Reader

Comment by mharroun | Hacker News Reader

Speaking from startup perspective.

While there are a hand full of exceptions. IMHO the dedicated role of a product manager is exceptionally counter productive.

Unless they are a founder they tend to lack technical expertise of capable enginners and enginnering managers as well as have a disconnect from the core drivers of what can make the buisness sucessful.

Maybe I have just had bad luck but in my 12 years of experiance with 6+ startups it's either the founders or buisness competent technical leaders who have driven a company and its products to suceed. "Formal" product managers I have come to associate with elements that kill startups... things like kingdom building, playing politics, information withholding, setting timelines and expectations without any real clue what it really takes.

We need buisness competent enginners, systems to feed feedback from sales and customer service to product enginner teams and engineering leaders who can communicate with other departments and understand buisness goals that they must build towards.

What is not needed a role who does not know sales, customer service, marketing ,or enginnering who puts systems in place to seperated thoes units for their own personal benafit.

At the end of the day, engineers need to know what they should build. Customer feedback, usage analytics, and all the other signals about what people might like need to get collected and distilled into actual feature ideas. And those feature ideas need to get broken down into development projects that can test the underlying assumptions and hypotheses.

In other words, product management work needs to get done, one way or another.

Saying you don't need product people, you just need engineers who can do product work, is like saying you don't need engineers, you just need designers and salespeople who can code.

Sure, you could ask engineers to do all the product management. But then they'd just be PMs, except with engineering titles.

All that said, it sounds like you've worked with some pretty bad PMs in the past. And a bad PM can certainly be worse than no PM - kinda like how a bad engineer can make their entire team less productive.

This is common-sense, intuitive, and practical advice.

It's also wrong.

The piece you're missing? The technical definition of the problem changes as we engage with solving it

So there's no "collected and distilled". This is not a grocery shopping trip. Instead there's heavy user interaction, playing, and coming to grips with both the tech and user and how they live and work together. You can't capture that in a stack of printouts or Word docs.

There are two problems with project/product management in tech. First, value discovery is a completely different activity than value delivery optimization, although they use mostly the same tools and skills. You can't tell from the outside which is which -- and we train most all of our management skills around optimization. Second, the intuitive way we humans have of solving problems, where we break them into pieces, "componentize", then optimize -- it's the wrong way of looking at it. Our natural intuitions lead us astray. (It's not a manager thing. Tons of great technical folks have taken a shot at managing and made these same mistakes)

Disclaimer: wrote a book on how this works at the team level. Currently working on one about the program and product management level. https://leanpub.com/info-ops

It took me many years of watching this fail over and over again before it finally clicked what was going on. The PM skills are desperately needed. It's the framing of the work that begins to take us down a dark path.

I dont understand your point,

The comment above says, that to have a good product we need someone that understands the users. And if we want someone to be good at something he has to do that most of his time. So we need PM.

I don't think your answer is relevant, also because project management and product management are complete different disciplines

Apologies. I did a poor job of explaining myself. I completely agree that they are different disciplines. Yikes.

I'll try one more time. I guess if this were easy to explain it wouldn't be done so poorly everywhere.

By looking at the Product Manager's role in terms of componentizing responsibilities, duties, and skills -- which both the original author and the commenter did -- there is an underlying assumption that is false. That assumption is that these things you're supposed to understand and manage are discrete items. There's a factory metaphor, whether either author realizes that or not. Ideas come in from the users, bug system, and other places. The Product Manager assembles and works these ideas, identifying a MVP, breaking them down into smaller features, and so forth.

Perhaps this could be restated as such: There is a discrete set of information and processing that must be done to translate external stimulus into items ready for work (And yes, I think everybody agrees that this information changes over time, but the assumption is that you fix it in place at least long enough to go through a release cycle)

This assumption is not true. Yes, there is a discrete set of ideas that need processing, and the result looks the same -- but not only does the information change as time moves on, the developers concept of the world the user lives in changes the more they intimately interact. Now in a small team you join the team at the hip with some users and it works out. As you scale up, however, that's not an option, and it's much easier for a developer working as a Product Manager to spot where the world changed than a person trained only in management. (A developer who has no product experience in this particular startup would the same problem, by the way. You're looking to identify business model impedance mistmatches, places where we were coding for one universe we thought existed when in fact we were mistaken.)

That's not something you can somehow document or think your way out of, since so much of "the universe we thought existed" exists as invisible, implied assumptions. All you can do as an external manager is manage those things you can identify and record. When you're doing value discovery, the most important value ideas you'll find start subconsciously and then become visible.

We have this same problem in project management -- conflation of what I can see, record, and optimize with what the actual work is. In both cases, the underlying assumption of physicality and how we deal with physical problems comes into conflict with fluid, fluffy, and ephemeral way that humans actually think about and work through problems. This is not a problem in a ton of other areas where there actually is physicality, like hardware-only product development, where the cycle times are long. (Or at least not in the same way). But it is when you're doing traditional software-heavy product management.

Hope that helps. It was on-topic. It's just a difficult thing to write about in a simple way. Thanks for the feedback.

ADD: One of the things that makes this so difficult is the amount of invisible and many times unacknowledged work that happens. So you could ask a successful founder/Product Manager what their job and responsibilities were, and you'd get a list just like the one provided. Go out and try to execute on that list, though, and you'd screw it up.

Most times founders do have very good intuition because they are building product for themselves first and the various complexities may not be important earlier in the cycle. However if you are going in the new field and well past "early days" then having product managers with field experience could be very useful. For example, you want to build new glucose meter and you know the tech but have no idea about regulations, customer preferences, competition, history of dead products etc. In addition to what has been described in article, I would say followings are also responsibilities of product manager:

* Design meticulous user studies, evaluate prototypes with customers, identify problems earlier.

* Research options for external interfaces for the company including supply chains, offshore options, vendors, partners.

* Do analysis of competition, their strengths and weaknesses. Estimate their future trajectory, influences, cost structure, customer opinions and actions.

* Perform retrospectives for successes and failures that happens within the company. Create systematic log of these analysis and ensure failures don't repeat but successes do.

* Make sure there exist systems for various data collections including human resources, engineering (bugs, backlog, hours spent, LOCs), customer support etc. Help turn these data in to dashboards. Lead analytics and insights in all aspects.

* Take a detailed look at the history of the field. Why past product failed? Why some won in competition and some lost? What customers rejected? How laws changed destiny of products? Lead the "lessons learned" storyteller role.

* Create systematic database of who's who in the field. Everyone from previous founders, star engineers, politicians, activists, biggest fans, partners etc.

* Ensure there exist efficient measurable pipeline for lead generation to customer acquisition to customer exit interviews. Influence strategies for sales, marketing, evangelization. Ensure company can preemptively avoid or at very least detect churn much earlier.

As you can see, founder alone may not be able to do all of these + product design + engineering efficiently and comprehensively. I would also say good product managers are never just product managers but also able to take over partly or completely sales and/or marketing. Also many good product managers are not generic MBA types but rather very specialized in specific field with solid design skills and experience in their field. The way I look at it is founders provides intuitions while product manager brings data and systematic analysis.

Reply on news.ycombinator.com