> It may seem frivolous, but it is a key to successful projects, whether as a consulting org or internal enterprise development.
Sorry, but neither of those things usually require a product manager because neither of them involve building a product.
The role of product manager is basically THE key difference between building custom software and building a product.
When you're building custom software, you have a specific user who is paying you to solve a specific problem for them. The only measure of success is whether you solve their problem (within time/money budget). For these kinds of things, you're right, it's absolutely critical that the person with the problem and the person solving the problem work closely together.
When you're really building a new product, you won't even have any users and you won't have anyone paying you who's defining success for you. Someone on your team needs to figure out who are the customers you're trying to target, what problems are we trying to solve for them, how can we solve those problems in a way that's generic enough for us to sell it to multiple customers, etc. That's all legwork that a (good) product manager should be doing because, again, no one is proactively defining it for the team.
True, I was talking mostly about custom software, but I've also turned that into products.
>> Someone on your team needs to figure out who are the customers you're trying to target, what problems are we trying to solve for them, how can we solve those problems in a way that's generic enough for us to sell it to multiple customers, etc. That's all legwork that a (good) product manager should be doing because, again, no one is proactively defining it for the team.
And this is exactly the task that should be done, NOT ONLY by the project manager. Perhaps, if the PM has a stunning level of deep knowledge of both the engineering capabilities and the product's domain, (s)he might be able to make a good stab at it. But getting actual engineers talking to actual intended users and integrating that knowledge will still make a better product. I'm sure there are some PMs that can pull it off, but...
How many times have you used a product and had to ask "how TF this this even pass first user testing"?. They'd already committed to what turns out to be a dumb design and it was too late to fix it.
Sorry, but neither of those things usually require a product manager because neither of them involve building a product.
The role of product manager is basically THE key difference between building custom software and building a product.
When you're building custom software, you have a specific user who is paying you to solve a specific problem for them. The only measure of success is whether you solve their problem (within time/money budget). For these kinds of things, you're right, it's absolutely critical that the person with the problem and the person solving the problem work closely together.
When you're really building a new product, you won't even have any users and you won't have anyone paying you who's defining success for you. Someone on your team needs to figure out who are the customers you're trying to target, what problems are we trying to solve for them, how can we solve those problems in a way that's generic enough for us to sell it to multiple customers, etc. That's all legwork that a (good) product manager should be doing because, again, no one is proactively defining it for the team.