28 comments

[ 2.9 ms ] story [ 64.6 ms ] thread
If your startup is all tech people and at least one of you can't do the PM role, you're boned. If you're the archetypical one-tech one-biz startup, and the biz person's full-time role doesn't knock out all the PM objectives, you're boned. If you have to hire a third person to be the PM, you're doing something wrong. In most cases, if the person doing the PM role for you tells you he can't do anything else because the PM role takes too much time, you're probably getting rolled. Unless he's spending all his time traveling to customers.

The job of the PM (and my partner Dave will laugh at me for saying this) is to get prospects on the phone and find out what they want from the product. For straight-to-consumer products, finding the right people to get on the phone is part of the challenge of the job.

"In most cases, if the person doing the PM role for you tells you he can't do anything else because the PM role takes too much time, you're probably getting rolled."

Ugh, I've experienced this and it's terrible. It's not just that they're a waste of resources, they often end up creating busywork for themselves that draws in others and wastes their time.

I'm not against PMs, I'm against having certain roles purely as a security blanket. It happens to designers like me too - just this week I tried talking a startup into offering a contract gig instead of a fulltime perm position because I'm still not sure if there's enough meat on the bone long term.

Before you launch something, surely everyone in a startup is the product manager, to one degree or another?

Even if said product is the startup itself, and the customers are angels/VCs/...

I agree with this. Do not hire a PM who can't code, doesn't have design experience, and can't bring business in the door. Big company PM experience is not an asset here. I was a Microsoft PM before, and it did not prepare me one bit for the rigors of startup life.

All startups need three things: 1) coding, 2) product design, 3) hustle. Ideally everyone can do all three. The ideal PM can do both #2 and #3.

At MSFT, were you "program", "project", or "product"? My understanding, three very different, frequently confused roles there.
Program Manager -- it was closest to the metal (work day to day with engineers, designers, testers, and marketing) -- but was far too much paper pushing.
I was a program manager intern; compared to what I now know about product management, it was too far from actual code and too far from actual users to really be useful. However, as an internship it taught me a hell of a lot.
I'm just wondering why you find it necessary for a PM to code?

I've seen this sentiment a lot around HN and find it curious. I've worked with many Product Managers were fairly technical but weren't going to do any coding (or architecture).

The prevailing attitude on HN is that all founders and early employees at a startup must be coders. As a technical person with a business background (and MBA in progress) I find this attitude short-sighted, since technical employees with business background can bring a LOT of value to a startup vs hiring yet another programmer.
> The prevailing attitude on HN is that all founders and early employees at a startup must be coders.

That's not quite right, but code is the product.

> As a technical person with a business background (and MBA in progress) I find this attitude short-sighted, since technical employees with business background can bring a LOT of value to a startup vs hiring yet another programmer.

I'll bite - what value do you bring that exceeds the value of a coder? I'll assume that you're not coding, so be specific about what that business background provides.

Note - coders can talk with customers, get requirements, etc. Some of us own suits and have some VC "greenstamps" to cash in.

I forgot to ask. When is that value "full-time" and what should happen before then?

While this whole line of disucssion has been about "code", I'm interested in how things might be different when for "not software" products.

I agree with you -- not everyone has to code. I am not against non-technical founders at all. The great nontech cofounders are people who can either design or hustle with the best of them. Those are the phenomenal non-technical cofounders.

Note: MBA does not a hustler make. MBAs are made to be great at working for others in larger organizations. But getting an MBA does not preclude hustle, nor value to a startup.

He didn't mean a PM has to do all three things, just one of them, or ideally two.

The ambiguity of Boolean expressions in English is strangely fascinating.

They don't have to code, they just have to be able to do everything else not coding.

When you're starting out (like 2 or 3 people) -- it's ideal if everyone can move the needle in big ways.

A PM at that stage (someone who just writes specs / defines the product) becomes dead weight if they can't also design or hustle.

"Translate vision into execution." what?

Here's what I see a Product Managers Role to be.

1. Define the Product Features. Take input from all relevant stakeholders (Customers and execs) and translate this into a set of product features. Document and distribute. Clarify any concerns between stakeholders.

2. Clearly define features. An extension of point 1. Work with design and technical teams to make sure that the features are clearly defined for everyone working on the product.

3. Clearly Communicate Features. Document the heck out of the product features. PRDs, IA, UI Designs all need to be clearly documented. Then COMMUNICATE these features back to all stakeholders. If someone doesn't understand a feature its the PM's role to make sure they do.

4. Prioritize features. Even if you're not working in an agile approach at some point you will need to draw a line between MUST HAVE and NICE TO HAVE features.

5. Product Advocate. A PM is the champion for a product. It's important they believe in the necessity of what they are building and are willing and able to champion it internally and externally.

From what I can tell, list of bullet points aside, the difference between a good PM and a bad PM is that the good PM is constantly talking to customers and relaying what they say. I was and have worked with the "other" kind of PM that is very good at documenting and advocating for things, but that's not the job. The job is being on the phone.
Yeah where this seems to break down is that there's a very gray line around what a Product Manager's job is as opposed to a Project Manager's job.

Unfortunately in many organizations these lines blur considerably.

IMHO that's the exact description of a good CEO in a startup environment.
Agreed. That PM role is in a bigger company. In a startup, the ceo better be doing all that and then some.
By the time any startup is using words like "stakeholders," it's no longer a startup.
Startup PM here. Article is pretty accurate. My responsibilities:

1. Act as scrum product owner: define features, fill backlogs etc. A little additional project management/release planning when needed. Keep scope creep under control.

2. Market research: talk to customers, investigate competitors, build pricing models, financial projections, etc.

3. Code a little when needed. Make prototypes and mockups. Analyze raw data from the production system and make statistical models. Test and validate when needed.

4. Strategic sales & marketing. Go after the big fish directly when sales gets over their head and the CEO is booked. Position the product and help sales figure out how to sell it.

5. Absolutely anything else that's going to further our strategic goals. Get the pizza. Find contractors for non-core development areas. Paint the walls of the office.

Shorter answer: whatever it takes.

The product manager should also be doing some Kano Modeling and figuring out the ROI on features. http://en.wikipedia.org/wiki/Kano_model

They should also own the metrics dashboard. They should now exactly which features are driving which stage of the sales pipeline. http://500hats.typepad.com/500blogs/2007/09/startup-metrics....

That's the kind of stuff you can do once you reach break even point. If you concentrate on such things early on you work on the wrong stuff.
I find the Kano useful even pre-breakeven, but most (good) PMs probably have an intuitive sense of where their products/features without doing a formal assessment
Related question:

How do you get a job as a Product Manager in a startup? Every job I find for startups/small companies is for a "ninja programmer", "code guru", "awesome programmer", etc.

Most non-technical PMs I know were former founders at startups of their own. Aside from that (cause that's an expensive and painfully round-about career path), I wish I had answers for you.
"Most non-technical PMs I know were former founders at startups of their own"

That's one way, another is to grow into it from a related role: programmer, designer, etc.

Having worked as a startup "product guy" for the last five years, I think there are some good answers to the original question.

Several notes:

1) If you fall into the trap of thinking that engineers, technologists, CEO's, and others can handle this role, you'll just be part of hundreds or startups that don't have their act together. I've sat down with way too many startups who both don't have a handle on the marketplace or customer needs and have poor processes in terms of planning / prioritizing release cycles and roadmaps. While others in the company should have a grasp of both of these elements, the key point is correctly identifying the first part (i.e., customer needs) and then mapping it to the second (i.e., the roadmap).

2) The person who fills this role should be fairly well-rounded and be sort of a weird breed in that they actually are comfortable (and good at) talking with people (customers) and yet can get down into technical details. I wouldn't go as far to say that coding is necessary but surely mocking up initial wireframes and UX should be considered as part of the job.

3) Related to terminology, I'd try to stay away from using labels like "project manager" or "program manager." These are way too broad and make it seem like the role is more focused on logistics and coordination. Above all, this role is strategic...keeping the trains running on time is just one aspect and arguably, not the most important.