4 ms·

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

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

polote 8y ago
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
- DanielBMarkham 8y ago
  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.

polote 8y ago

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

DanielBMarkham 8y ago
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.