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?"

You get the idea.

This is a great comment. Thank you.

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 is an absolutely amazing wealth of information. Thank you so much.

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

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

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.

Wow, thank you. This is amazing, I'm blown away by how much knowledge is being shared here. Made my day

Be an active user, passionate about your product.

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.