These are indeed things that product managers do. However, in a software startup, the product manager's portfolio is the founder's portfolio; in other words: you'd better be a good product manager (or be ready to become one).
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."
Interesting, this week I'm in the interview loop for a PM position at a notable company.
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?
I was a PM for a couple years at an established startup.
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?"
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.
I'm a PM at a large, well known software company. In fact, I lead a team of PMs and have been in a PM role for several years after running a failed software startup during university and a stint as a sales and marketing guy at a solar start-up.
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
A number of these PM tasks go deeply into the development world: defining development processes, architecture, and managing developer checklists.
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.
This is a good point and something I should have made clearer. As PM, you ar first and foremost the customer advocate. Drop the ball here and you fail.
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.
Well put. I'm currently in a situation where my PM has started to believe he knows more than he does (thanks to the assistance of me and the developers in the office).
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?
The bozo bit is starting to flip... Give the PM the benefit of doubt; I'd be direct with him about why you don't think his actions are right--tell him what you expect from him and why the way he's behaving isn't constructive. If he doesn't listen, do your job, watch your back, and communicate to your boss how this guy isn't healthy for your team.
Yeah, I'm trying, but unfortunately politics are getting in the way...the PM and CEO are best friends from way back at previous companies. PM was laid off from his last job and sometimes I wonder if he got the job only because he needed one. It's tricker than it looks.
Quite interesting. As a developer, one thing that has frustrated me to no end is product managers not interacting enough with the developers. In my corporate career, I have seen too many of them talking abstractly about the product and hoping that the developers will magically figure out what needs to be done. After handing over a sketchy PRD, the job is done. " 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)" - This is so important.
Not sure which is better form that quote. Someone who protects the company from shit, or someone who funnels the shit away from everybody else in the company?
I would imagine its hard to hire a good external product manager.
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.
The job of product managers is not to know, it is to learn. Far too many people have that backwards, including product managers. The best ideas rarely come from the product manager. But the best product managers do a good job of finding ideas that are out there in the users, QA department, developers, etc, and figuring out which ones deserve to be tried, how to integrate them into the product, and how to judge their success.
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.
"The best ideas rarely come from the product manager"
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.
Yes, I remember specifics of how Jenny Kaplan (then Roosa) impressed me. (No need to hide the name of someone I'm complimenting. :-)
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."
I don't recall what article about startup valuations it was, but it was posted here a few months ago, and one of the pieces of advice was: when valuing a fresh, new startup(< 10 employees), deduct -$200,000 for every product/project manager on the payroll who doesn't also hack code.
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.
I will. Steve Jobs had Wozniak partnership , without him he would be not what he is today, he wouldn't had the experience he has(he started very young), either the money and fame. He wouldn't had the opportunity to work with(and learn) from extraordinary people he has.
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.
Jobs is a terrible example. If he founded a company he'd be a finger snap from surrounding himself with an A-List tech team, the likes of which SV VCs only dream about. It's the fact that he could find the talent if he needed it that the valuation would obviously be greater than 0. Your point is moot.
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.
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.