[danenania]

This really resonates with me. There seems to be a trend of frowning on these types as 'generalists' who don't have sufficiently hard tech skills, but 'creates great products from the ground up' is a specialization in itself, and an extremely critical one. Someone who will do (and learn) whatever it takes to put out high quality work is someone who will be a top performer at almost any company, regardless of how they would do on a Google algorithms quiz.

This mismatch was part of what motivated me to build MakerSlate [1], a résumé optimized for just this type of creator.

1: https://makerslate.io

[mpdehaan2]

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.

[shalmanese]

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

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.

[palakchokshi]

A technical Product Manager would be a Product Engineer but the inverse might not be true. In my mind a good Product Manager is also responsible for guiding the product roadmap in the direction that addresses user's wants rather than features that are cool to implement but don't really address a user's wants or needs.

[mpdehaan2]

Yep, definitely. As a really bad analogy, if you are in the ice cream business and ask a customer, they will recommend you changes in flavors, but if there was, say, a huge chance in a new kind of popsicle, they'd never tell you about that. There's also a dichotomy between the things they'll ask for and what you need to get them to stay with you, or get other users sold. You can make an existing user really really happy (which I approve of), but in doing so, you might not be expanding market. Just trying to retain them is not a good solution, but there's a balance there.

But yeah, the customer is not usually going to tell you the world takeover strategy.

I kinda wrote something about that here - http://michaeldehaan.net/post/118860078737/the-rockpaperscis...

[palakchokshi]

Your article is spot on. I agreed with all the different product management strategies. I was going to make the argument that building what the users tell you they love is great when that thing is making you money. However you made the point much more eloquently in your article. That's a nice read. Thanks for the link.

[rrrx3]

I love this. What a great idea.