| It's a good post and a good thought. Software is a giant LEGO set with no instructions, and it takes a good mixture of how to build things and knowing what you can build. A lot of times people want to reduce product management to "visit customers, ask what they want, make a spreadsheet", but I think it's more than that. To do it well, you have to know the possibilities the existing stack could grow into, and also what it can't easily grow into, and set a vision that is well beyond what the masses point at. And you also have to know the industry enough to know how to build things that make sense to end users. In maybe 80% of the jobs I've had, non-technical product managers have been probably the single most powerful force to get me to leave an organization, because I always get very invested in a product and want to see it do the right thing, and I want to work on and design the right things. Working on the wrong things - features nobody is going to use, features that won't work, features that don't take advantage of a great opportunity or make a product great to use - can be demoralizing. I want to work on the thing that will make the most difference -- and then be able to witness that difference in hearing those stories from userland. And the second you take the design out of it (and reduce software down to implementation), for me, the fun parts are gone (unless there's some heavy C.S. or architecture parts, which in CRUD stuff is rare) and it's just implementation. Also - I will say, having done it, product management is always one of the most misdefined and potentially most disliked positions from the outside. It's the easiest to please no one while still trying incredibly hard to do the right thing, and probably the most important make or break function - because a company is totally viewed by what it decides to create. Further, a good PM can be made powerless if he can't get engineering do anything, and frequently organizational lines are set up so that he cannot. It's a position that needs to be elevated because it's so important, but instead almost gets lumped in with project management and viewed as easily interchangeable; the result is bad PMs make it hard for good PMs to get any respect. There's a huge standard deviation. Product management can also get in a bad spot when you give a few people absolute product control, and you ignore the ideas from developers and others throughout the company. So even if you are in this spot, and it's respected, you have to give voice to the entire company and try to focus sometimes hundreds of laser beams all pointed in different directions. The C.S. I majored in was about designing things, a lot of software engineering is about implementing features out of canned components other people have already designed. I think there's a lot of lost possibility in that, and we should encourage everyone to be more creative and blur the lines more in how we define software positions. |
Customers tell you what their problems are but they're not trained in telling you the solution. The mistake that's often made is that customers tell you their problem in the form of a solution. The role of the PM is to then take the solution, reverse engineer the problem out of it and then work with the team to figure out the true solution.
Where the technical/non-technical split lies between the PM and the engineers can vary. Ideally, the PM is technical enough to come up with new possibilities on their own and understand the technical implications and tradeoffs of each possibility but not every PM has the background or inclination towards that. The next best thing is that the PM works closely with the engineers to communicate the user goals and trusts engineering to find clever solutions to those goals. But the worst is a PM who thinks they're technical enough to come up with features and then steamrolls over engineering objections over the implementation.