How to hire a product manager
kennethnorton.com
kennethnorton.com
For people with PM experience, I'll ask them about the things they considered and documented in their last spec. If they think a spec is a list of bullet points, that's instant fail. If they considered all user flows in and out of the features, edge cases, user education, analytics/success metrics, release plan and time vs cost tradeoffs that's a win.
Raising your hand and asking, "Is this what you meant?" can save a lot of hassles, especially with remote teams.
Now as a PM, I try to use specs as a way to iterate faster. If you're working on a prototype of a completely experimental product, then at the beginning the important part is to make sure everyone just has an understanding of what the overall product will be-which is already quite difficult! Sometimes the best document here is literally just an annotated flow-chart.
On the other hand, when you're adding user-based features to an existing product, it helps to have stories, mockups, and in general include a lot more detail.
There's never going to be a perfect spec, but well-written (and iterated!) specs can make the development process much faster.
As a result, they are typically the closest to really knowing what has worked and what hasn't and why, which makes them uniquely positioned to decide what to do next/prioritize upcoming features, make tradeoffs. It doesn't mean the decision making is perfect, but I like to think that if you ask our engineers and designers whether our PMs are adding value, they would agree. Our 12 month engineer retention and internal survey data indicate that that's at least directionally accurate.
In brief: it's a waste of time because it assumes that one knows all the variables when creating something. If you are truly creating something, then by definition it's not be done before; thus, no one can know all the consequences of implementation. You're better off having an open mind and be quick to experiment and learn.
* How does this person deal with vast uncertainty? Are they excited? Scared? Is their first reaction to impose structure or are they comfortable with lack of structure? If it's the latter, can they meaningful convey confidence with the lack of structure?
* Can this person teach? Can they figure out how to take an abstract idea and articulate it cleanly? When someone doesn't get it, at what point do they fall back to utilizing authority? Are they good at listening closely to what someone is saying to them and framing an argument in their terms?
The only people who are afraid to jump off into the deep end are those who can't swim.
Excellent additions, "ability to deal with ambiguity" is a critical skill for PMs.
I was sort of curious about this line:
>Generally I'll ask questions until I'm sure the candidate is smarter than me.
Are these the sort of brain teasers we see in engineering interviews or something else?
The time I flew on the Enron corporate jet to meet Jeff Skilling https://www.kennethnorton.com/essays/enron.html
and I have been referencing this for a couple of years: https://www.kennethnorton.com/essays/leading_cross_functiona...
Goes out in person(!) and talks to customers.
It's very easy to add new features to products, but until you sit down with a customer, listen to them, and watch them use your product you won't have a clear understanding of their needs. Good product managers realize they are very close to a product and need to constantly take a step back.
If you're skeptical, sign up for a UserTesting.com account and watch people navigate your site. You'll be surprised.
Designers, Engineers, Sales perform well when they have deep narrow focus and goals. The Product Managers' job is to allow them to excel in their specialist role much like the conductor of a multi-piece orchestra.
Fundamentally, the PM's the one who gets the product shipped, whatever that entails. If the product is shipped, the PM makes it a success, including shipping followup features or products.
I've heard a few general descriptions, from "does anything except write code" (not true in many circumstances) to "mini-CEO" (implies greater degree of authority than often present). The best one that's stuck is "captain of a pirate ship"; you have to figure out where the ship is going, influencing without authority.
On a general level, rough job scope can be in the "design and plan" categories through to execution, driving everything forward, getting approvals and making sure all the edge cases are covered (both in the product and overall, e.g. legal approvals, trademark searches, etc) - plus measuring success, and making sure those metrics are defined and measurable in the first place. Listening to customers, or organizing user studies before launch, and incorporating feedback at every turn.
You sit in the middle of the product vision, and while engineers might want to make decisions that seem like good ideas from a technical standpoint, you are the guardian of the context which makes them into great ideas (or not).
Similarly, feeding back technical issues and restrictions into the UX design process, and providing those intuitive leaps when you realise if the design goes like this, and the technical architecture like that, the whole thing can be done in a tenth of the time to 99% of the effectiveness.
My impression is that it is a very hard role to describe because it includes "whatever needs doing" and will vary by product and the team around you. It will include making sure everything gets done and tied together including not just the product itself but the documentation and any licensing agreements and ensuring correct marketing information is prepared for the product at the right time (and the marketing team understand the product). It may include what is normally considered business development and associated liason with legal. It may include booking and preparing for a trade show.
In a big company playing a linking role and getting the right people talking can be important even if you then step back.
Very importantly it should be someone able and prepared to take decisions that might not be big and require senior management but that need making and aren't really either engineering decisions or design decisions.
I consider myself a PM and this is what I do:
Srum Lead
Sprint Planning / Release Management
"Tier 3" Support
Documentation Editor
Question Answerer Guy (Why does this piece of software do this and why is this link not blue?)
I'm also the liaison between management and the engineering staff.
There is some more official type stuff on wikipedia. http://en.wikipedia.org/wiki/Product_manager
They may not do all the work, but they're the ones covering all the little details: making sure an email goes out when a new user signs up, reviewing that copy, watching retention, etc.
You'll see a lot of job descriptions for product managers reference 'Mini-CEO', which is pretty apt.
Product management is particularly important in non-software companies where the obvious product isn't software. Your e-commerce website is just as much a product as your hipster glasses. Failure to manage it results in the classic IT dept. dysfunctional relationship where everyone hates IT and IT develops a thick skin and says no a lot.
I've been toying with the idea that I'm cut out to be a product manager and this just convinced me.
Also this:
"In fact, that's the first test - how do they react when I say 'I'd like to pose some theoretical problems, is that okay?' The best of the bunch are usually bouncing out of their chairs with excitement. The super smart sometimes counter with questions of their own."
Asking me this alone would make me substantially more interested in the job.
However, if you do "naturally gravitate to product management" -- that is you find yourself in those roles or have been assigned to those roles without effort or conscious action -- then it is a good sign of fit.
I'm sure it does, but that's beside the point. People who fit this description may not be great product managers, but they will likely be more satisfied in a product management role than in a design or development role.
i do not believe in generic pms. experience in pre-sales, consulting, development, something product related is so important, it builds up that spidey sense.
There's a lot in Ken Norton's post, but it's all worth taking to heart. Now, if someone could point me to a good article on interviewing PMs...
I'd love pointers to other such great resources that shed light on what makes a good, no great, PM.
First, find a PM to talk to, especially one you admire who's made the switch. Everybody's situation is different, and having someone to mentor you through it is invaluable.
Second, make sure you have the right motivations. A friend of mine says "run to product management, not from engineering." If you want to switch because your current manager is a jerk, you hate the project you're working on, or (gasp!) your PM is an idiot, you might be doing it for the wrong reasons.
You could test it out with a small project at first. Stepping up and saying "I'd love to take on more of a PM role on this feature/bug/release" will often be positively received by a healthy organization.
Startups are ideal places to make the switch (that's where I did it.) Everyone is used to wearing many hats and the "all hands on deck" attitude is much more welcoming of someone raising their hand and volunteering to be a PM. Smart, bigger companies (like Google or Facebook) often have formal programs for moving into PM. At Google, for example, we even have a six-month rotation program that lets you try it on for size.
And if you're convinced you want to do it and your current company discourages you, find a new one.
I first wanted to say thanks for putting up this essay on product management. I don't think quality pieces on the subject are easy to come by, and I think you give a lot of valuable and tangible insight on it.
Second, it looks like you favor past experience as a PM --- but what about college grads? Do you think it's usually a better idea for someone just beginning their career in the "real world" to start out as an engineer first? Maybe this sounds obvious as I've stated it, but I have a few friends that started their careers as PMs and have been successful. Interviewing a college grad might be a little trickier, no?
Lastly, I definitely agree that a big part of being a good PM, or maybe a good manager in general, is making good, or even just reasonable, decisions on a regular basis. There are seemingly endless small choices that need to be made that add up to a lot, and many of these choices (I've found) aren't going to be dead obvious. A decision, however, needs to be made and it's important that to make a decent one without dedicating too much time to it based off of your understanding of the goals of the project, your experience, and your gut instinct.