What does a product manager do?
iamnotaprogrammer.com
A lot of founders don't understand what a product manager does and when to bring one in. This is an attempt at an explanation.
iamnotaprogrammer.com
Read Steve Blank and Eric Ries. Don't think about hiring someone into this role until you've done it successfully for your company first.
"For over five years I've hired four product developers for three different startups I've co-founded. None of them has delivered satisfactory results. I am a perfectionist and that may be part of the issue. I've decided to stick to product development and, instead, hire others to take care of sales, business development, operations, etc. Also, doing product development is what I love the most. I am not that good at interacting face-to-face with others."
I come from a background as a botched startup founder & 'jack of all trades' consultant (developer / designer / project manager / team lead). Anyone have any advice? What challenges would I face in transition?
The core of the PM job in a company with direct sales is:
* Talking to customers
* Translating customer-ese into MRD-ese
* Negotiating with developers to translate the MRD into (a) a release schedule and (b) a product roadmap, both of which are commitments you'll be giving customers
* Being able to make a pretty roadmap slide deck and present it to (a) internal management and (b) customers
* Translating slide-deck-ese to marketing-ese (notably, being able to write any concept from use-case through engineering decision to value proposition in terms of "feature/function/benefit") so that marcom can commission sales collateral
* Working with sales to figure out what collateral is actually needed, and helping arrange for it to be created
* Tag-teaming on sales calls, both as a way to (a) talk to customers (see above) and (b) help account managers out
* Coordinating product packaging and pricing (note careful choice of words; product pricing is the deadly radioactive core of the startup money generator and is unlikely to be trusted wholesale to a front-line PM)
I list these not because I can hope to help you do the job better or to explain how to do these things, but instead because your interviewing strategy is very straightforward: take each of these tasks and devise 2-3 questions for your interviewer for each of them. You now have a small arsenal of questions; use them to keep control of the interview, while seeming extremely engaged with the job of product management. The answers to some of these questions may also clue you in to what your prospective employer is looking for in a PM.
Good "starter" questions (have 2 more detailed questions as backup) include things like:
"What's the process by which feature requests are qualified and then transformed into committed dates for customers?"
"Do you have a beta program? If so, how does it work, and what's the primary value to the company --- is it a prospecting tool, what percentage of your features and change requests originate in beta, and how do you qualify participants?"
"What's your most effective piece of sales collateral, and who wrote it, product management, marketing/communications, or an outside contractor?"
You get the idea.
In startups, typically the founders have to play the product manager role - their biggest responsibility being converting the ad-hoc complaints/feature requests into a workable product roadmap. PMs must have regular conversations with customers, engineers, and sales team and filter all the input from these sources.
This article does a great job summing it-up: the PM role is about taking the vision, converting it to execution of a strong product, and facilitating a feedback loop that helps drive the vision forward.
A lot of times the PM is denigrated as an excess or waste, particularly in start-ups. It's true that a lot of PMs are taxes to their teams. But good PMs will bring a lot of clarity and absolute focus. I'm sure strong founders are also very capable of this but it's likely a matter of time and focus for those founders relative to other competing objectives.
Tips on doing PM well:
- Live. Eat. Breathe your product. I've spent years working on a product that I secretly detested but used that frustration with the product as a motivation to learn the product space inside-out and established myself into a position to remake the product what it needs to succeed (rebranding, significant technical overhaul, slash/dash legacy feature weights, etc.). Our customers are going from constant complaining to singing praises—that's hugely rewarding personally.
- Squash out all forms of inefficiency in the team. Every aspect of development that reduces your ability to deliver the best product is a concern. I'm engaged in everything from the architecture, feature prioritization and scheduling, end user usability and aesthetics, support workflows, license agreements, and key customer account discussions. I coordinated the entire team's shift to agile development practices including deciding the structure of each sub-team (our dev team is quite large and split across different countries)--as the PM for a large team you are in a unique role to see all sorts of opportunities for improvement. But be very careful--don't be shallow in identifying something as inefficient. For example, driving out prototyping time from devs reduces both their morale and creativity, two valuable resources. Another common mistake, seeing process as efficient… Creating checklists that engineers spend more time checking-off than delivering value to customers. Bad PMs excel at this.
- Software is the output of people and your ability to drive, motivate, and coordinate people is key to their ability to deliver the product. Process and schedules are mere tools for organizing people, don't let them dominate you, the team, or the product. The best PMs are really good with people and care about the team's success more so than their own because they know that a product and team's success will ultimately be good for their own career. The role often puts you in a leadership position with the team—don't be afraid to lead.
- You will constantly straddle the expectations of upper management, peer managers, and the individuals on your team. Knowing how to balance all of that and communicating appropriately to each set is a really important skill. Also, be prepared to be honest when the news isn't good--bad PMs will hide things and hope for miracles. Your job is to help people make the right decisions even if it means you get ripped apart in a couple meetings.
- The most important thing to deliver to the team is focus. Get the distractions out of the way and point the direction to the what needs to get done today. If you're nuanced, you can do this without making it feel burdensome or dictatorial. The best is building a team and process where the team can answer focus questions themselves.
Here's what day:day job entails (these will often change based on the size of the company and the scope of your influence—as mentioned, I drive a team of PMs for a software product that straddles the consumer/enterprise space:
- Meeting with key customers and getting requests/appeasing them around product direction (and knowing when to ignore them or probe deeper about what they really need vs what they are saying)
- Working with or sifting through market research about the space to try and forecast the demand for certain features
- Driving these requirements into a schedule and managing that schedule with development, often a negotiation between you, development, and management—this bullet really underestimates this as often this is what more junior PMs spend a lot of time doing
- Bubbling up engineering opportunities that need prioritization and/or could save costs and/or better align your team to future customer opportunities
- In larger orgs, coordinating across teams about aligning bigger customer bets and scenarios
- Drafting functional specs that range from whiteboard drawings to many-paged docs describing how things will work (totally depends on your ability to communicate, the team you work with, etc)
- Driving the overall look-and-feel of your product in alignment with usability, branding, and revenue concerns - Making the calls about what hits the quality bar to go in/out a version of the product
If you want a good start at understanding some aspects, see Making Things Happen by Scott Berkun (http://www.scottberkun.com/books/making-things-happen/).
I've worked with a number of product managers who've grossly overestimated their competence in these areas, and who've been mocked and ignored as much as possible by the development team as a result. I'm familiar with a large, well known software company that uses such a job description. I worked with a product manager who left that company for mine. He was awful. He never gave customer-focused requirements. Instead he'd define implementations as if he knew what he was talking about, and I'd have to play 20 questions to figure out what problems he was trying to solve.
The best product managers I've worked with have leveraged their strengths and trusted others on their team to do what they're best at. In my experience, these product managers have always had a very strong customer/user focus. My favorite product manager was at a medical imaging company. He had been a tech before he moved into product management, so he knew deeply what our users needed from our product, he had many connections in the user community, and he knew how to listen. We'd challenge and ask questions, but at the end of the day we deferred to him in his area of expertise, just as he challenged and asked questions but deferred to us in our area of expertise.
Engaging at a more technical level needs to be about ensuring focus, not meddling where you don't understand. For example, cootdinating architectural decisions does not mean designing the solutions (your senior devs do that) but it does mean infusing those discussions with customer centric decision making. The worst thing a PM can do is act like they know something without actually doing so--as others have noted, you need to listen and learn.
My experience may be a bit different; when I started, my boss was checked-out and looking for a career change. To learn the role, I got to know our developers really well (in the end, they have lots of power) and asked them what the PMs did well and didn't do well.
Then PM made the mistake of talking within earshot about how he was going to decide the timeline and budget for my team without talking to me. My attitude toward the guy instantly went from "whatever it takes" to "do your own homework next time, buddy".
This is a small startup. We need every win possible to succeed. And I just don't give two shits about the guy anymore. Am I wrong to think this way?
If you don't use it - you lose a ton of effectiveness. If you don't love it, well that's the first thing you need to change.
I once worked at a small company where the product manager was a new hire, but most of the developers had been around for a long time (4-5 years). In the "food chain" the manager was higher, but after years of experience working on the project and under the founder the developers had a better eye for what worked when it came to implementation.
I remember one product manager. Her first time being a product manager in software. I handled reporting. Within 3 days I knew she was good. She knew absolutely nothing, but she asked the right questions, and put the answers together in good ways to come up with insights other people hadn't had. I was on my way out the door, but I kept in touch with the company. I was entirely unsurprised that 6 months later she had emerged as a superstar.
Still there is always a challenge in telling the difference in an interview between people who are good, and are good at BS. This seems to be particularly true with product managers. But I suspect (never having hired for the position I can only suspect) that digging into their willingness and ability at asking questions is revealing.
Agreed. A product manager is like a jazz musician. You're a student of established patterns, and pay attention to everyone else on stage (designers, boss, customer support), but when the need arises, you can create something new to wow the audience.
She was asked to look at our lease reporting process. That was a process that was somewhat complex, under documented, and which nobody had been in charge of for some time.
Less than a day later she knew that I was a useful resource. She asked me for any information I had on lease statuses. I sent her a copy of the standard documentation we had on tables, and pointed to where in that there was a list of all statuses you could wind up in during the lease reporting page. She asked me for information about transitions from state to state. I sent her the source code that controlled the set of all possible lease transitions, and included brief descriptions on how to tell when that would trigger emails, etc. (There was no other documentation. Seriously.) She came to me, and said she was trying to prioritize the logic, and we had a brief back and forth discussion about what was available. Perhaps 15 minutes later I had a report for her that listed for each lease transition, how many people had made that transition in some previous time period.
The next day she had a diagram that listed the major lease states, the important lease transitions, gave volumes for how people flowed through, and gave how many people's leases ended at each status. She had also prioritized which ones she thought had the most room for improvement. This was by far the best view I'd ever seen on the lease report process in several years at the company.
I was impressed with how quickly she had come up with that, and I mentioned this in a conversation with the person who ran QA. Who said, "You're not the first to compliment her. Monica (who handled customer support) has been saying how happy she is to have a product manager who comes and asks questions about what problems people are asking customer support about. I'll be very interested to see what she does with her spec."
Jenny started 3 days earlier. Within 3 days of being handed a big hairball of a project, she had managed to impress 2 people in 2 other departments. And when said spec arrived, the comment I got from the head of QA was, "Now THIS is what I wish every spec looked like. Clear. Simple. Too the point. And it looks like it will work."
-$250k per business guy.
And I think the argument is pretty sound. He's talking about your prototype valuation. The article is focused on post-launch. Hiring a product person pre-launch is probably a waste of money, unless you have the loot to have a 20 person team pre-launch.
It was a symbiosis because odds are that Woz without Jobs will not be in a very good position. Jobs is an extraordinary seller(distortion field).
So yes, if I find a young Jobs without training and even more if it has no employees is at least -$200,000.
I'm saying if Steve Jobs today said, "I'm leaving Apple and starting my own company. As of today, I'm the only employee of this new company."
He comes to you and says, "I'll give you 50% share for $20" you'd say, "No. Since you don't write code, the company is only worth -$200k".
Let me cut to the chase. Valuating companies with stupid formulas, leads to stupid valuations. IMO.
You don't say, "non-programmer equals -200k". You say, "What do they bring to the table? Oh, you have Bill Clinton on your team and you're trying to do a government services startup -- that's a pretty big plus, even if Bill isn't coding". "You're doing a Clicker like company and you have the ex-CEO of Comcast. Maybe a plus". "Doing financial services software, and you have the ex-head of IT from BofA... maybe useful, even if he is 'just' IT".
In fact, I'll say if you have a startup company in front of you who doesn't know how to judge each individual, pass on them. They'll fail.