Hacker News new | comments | show | ask | jobs | submit login
The Product Manager's Lament (linkedin.com)
74 points by Brajeshwar 1787 days ago | hide | past | web | 43 comments | favorite

All too typical of a tale. Too many people working on too many things, where the only person who has ownership is the guy not building any of the things (the PM).

Simple solution: Small teams that own what they're working on, soup to nuts. This probably means 1-2 devs on a team, a designer spread across 1-2 teams (depending on the scope of the team), and the PM helping all of them, where necessary, but not giving them exact specs of what to build. Product manager in an agile-ish organization is an extremely poorly named title, as their primary function is not to manage, but to communicate and facilitate things that are otherwise difficult or inefficient for designers and engineers to get at.

If the PM is giving the designers and devs exact specs on the product to build, he or she is failing in their role. The PM should be focusing on communicating succinctly the business problems to solve, and the software solutions evolve naturally from the small teams. The product manager, as a member of a team that builds software, should be expected to have some insight as to the general design of the software (maybe in the form of wireframes or whatever). But providing exact specs for what to build is a battle-tested Recipe for Failure™.

The PM should be focusing on communicating succinctly the business problems to solve, and the software solutions evolve naturally from the small teams

This may work with top x% of programmers/designers but the fact remains, majority of the programmers and designers are not equipped to take a business problem and come up with a solution. Their core job never was to think deeply about a problem in a niche domain. Now I understand at startups it is common for multiple of these roles to fall under one person but I am yet to see that system scale, especially at an enterprise level where the customer may have very peculiar requirements the product manager can really help think through before it even goes to the devs/designers.

> the product manager can really help think through before it even goes to the devs/designers.

I'm not convinced it's more likely that the PM can think through the issues better than anyone else on the team.

In any decision, in any industry, in any profession, the only way to make a good decision is to understand the cost and benefit at the same time.

IMO, almost all corporate software disfunction comes from that failure. The decider understands the cost, but not the benefit, or the benefit, but not the cost. Sales teams that don't understand the product, developers that never talk to customers, managers that don't understand how to code are all trivial examples of this.

If the PM designs the feature incorrectly without understanding how to code or understanding the current codebase, there could easily be a 10x cost difference, in terms of implementation and QA. If the developer writes a feature that no customer will accept, all implementation time is wasted.

How to fix that failure depends on the relative costs for the PM to learn the codebase, vs. the developer learning the business domain. Though both are nearly essential to a successful company.

Sure, and thus the rise of the developer-product manager. I'd consider myself to be one and I know plenty of others out there. My primary focus is to make sure what we build is what the clients want but when communicating with the developer, I will talk in terms of primary key and other technical concepts.

The same terminology would no make sense to the client and a client's terminology("I just want feature x") leaves out bunch of implementation details which a good product person should be able to clarify and fill in instead of leaving it up to the developer to guess.

Fair point. I agree with what you've said here with respect to most large corporations ("enterprise"). Generally, I think designers are better trained to think like this than engineers. Either way, this is the way I think both crafts need to evolve: both engineering and design should aim towards more of a core focus on the product, rather than just their individual pieces.

The startup world is certainly leading the charge in this right now, though I think it's often mischaracterized as a resource constraint problem, one that will presumably be solved down the road by hiring a proper product manager when the company needs to "scale". Training all employees to think strategically about business and product is a universally good thing, but especially for those building the products, especially when the software is the product.

As far as how well the system "scales", I suppose it depends on your definition of scale ;) Facebook seems to be doing pretty well with some version of this approach, and I think they're at about 3-4k employees, at least half of those are technical afaik.

This may work with top x% of programmers/designers but the fact remains, majority of the programmers and designers are not equipped to take a business problem and come up with a solution. Their core job never was to think deeply about a problem in a niche domain.

I'm a product designer, and I do see think deeply about a business problem and finding a solution as a huge part of my job. If not to find solutions to problems, what are the job of a product designer?

What is a product designer? You are the first I have met.

I'll paste from my personal website: "I love designing holistic experiences, from the big picture vision, down to the pixel grid." So, I find (the right) problems and then create a solution (product). That's how I see my job.

I agree with this. In any given team, the PM should be the least expert on any given subject (e.g. what parts of the codebase to utilize, how to design the page, etc.), otherwise you've staffed the team incorrectly.

Forcing the PM to create requirements based on things she doesn't understand well is a surefire recipe for failure, as you said.

They are also very good at keeping teams isolated from useless work so they can get the important stuff done.

I'm really surprised that he didn't just recommend that they do away with Product Managers altogether.

This is probably the best Product Management approach I've heard of for early startups: http://www.quora.com/Stripe-company/Does-Stripe-have-product...

This is a dangerous approach to take lightly. Product design is a discipline in and of itself. There are very few people out there who are both excellent engineers and amazing product visionaries.

For most startups the PM role is fulfilled by the founder's vision. However, as the company begins to grow and the initial vision is achieved, it becomes harder to go without someone focusing on the product aspect.

The reason someone like Stripe can do just fine without PMs is for two main reasons: 1)Incredible market pull - they just need to be methodical about following the requests and prioritizing them in accordance with revenue/implementation sequencing/risks. 2)Stripe's engineers are the target market - Stripe is built by developers for developers to make payments easy. Much like Jobs embodied his own target market, whenever you are building something for yourself, market research becomes a bit less important... more implicit.

If the above conditions are true for your startup, then absolutely, you can follow the example. However, if you are missing either, you should really consider dedicating someone to this research and visioning.

Stripe's approach to staffing is not something that's easily imitated. Most of their employees have either previously been founders or have managed products before as a higher level employee. It's not fair to assume that every startup/company will have that caliber of employee top to bottom.

It also seems like Ries was trying to direct this post at all kinds of companies, not just early startups. Patrick himself said that Stripe's approach to staffing is an example of "doing unscalable things while you can". Not everyone is a small startup and the approach of letting everyone manage themselves doesn't work at 100+, 500+, 1000+, 10,000+ person companies.

I wouldn't recommend that approach for every startup, but if you are a small team, it's a huge plus if your engineers have great product sense (and and some design sense too).

It all depends on on this:

>The engineers who build our products enjoy, and are good at, figuring out what the product should do—not just how the implementation should work.

all fine and dandy until you move into areas developers simply have no clue about - compliance heavy, enterprise, etc.

you mention "early", this is key. PMless agile is super simple until you have live, paying customers (as in corporations, not people). breaking existing stuff is simply not possible anymore, SLAs are in play, validation efforts, etc.

throwing shit at the wall and see what sticks works in hardcore startup mode before you have a customer base. then it becomes suicidal. even in consumer space, see the various failed relaunches and redesigns.

I also like GitHub's approach http://warpspire.com/posts/product-design/ (they refer to the role as product designer) but I wonder how long it's going to work for them.

Github is a very special company in that respect as the developers are building a product they are using for themselves. Github's model couldn't be replicated in a field where this wouldn't be the case.

Feels like that PM is trying to micromanage and failing to keep his troops working in their box.

If you're going to make a spec that defines 'how' as a PM, then you need to make sure your designers, coders and QA do exactly what you tell them. This can actually work if you're an incredible genius and know the details of what you're trying to do incredibly well.

Most PMs don't fall anywhere near there, and so the solution is simple: spec the 'what' very broadly. Delegate protocol specs to the programmer(s) who will be dealing with that protocol the most. Make sure the programmers create a product that the designer can 'skin' afterwards - such as moving elements around the screen without programmer assistance. Have the QA work with the actual product and not a spec - the users will be using the product after all, not the spec.

Standard stuff...

> Feels like that PM is trying to micromanage

I didn't get that from this piece at all. At what point did the PM in question appear to be micromanaging?

> spec the 'what' very broadly.

That's laughable. No client or internal stakeholder is ever going to spec the "what" broadly for any definition of the term, and if you let them you're setting yourself up for failure (because they're not going to like what you make, and they sign your check).

> Make sure the programmers create a product that the designer can 'skin' afterwards

And what if the programmers leave something critical out of the design? What if the designer was expecting behavior that is different from what was created?

> Have the QA work with the actual product and not a spec - the users will be using the product after all, not the spec.

QA resources use the spec to create a test plan from which they test the final product. If they don't test against the spec, what do they test against? If they're not testing against the spec, they're not exactly doing quality assurance, are they?

Your comment shows a strong lack of understanding of almost everything that was mentioned in the blog post linked to by the OP.

What about spec the "why", then engage with the team to figure out the "what", then let the team figure out the "how" by themselves. Believe it or not, the PM is not the only one with problem-solving skills on the team to tackle the mapping between "why" into "what".

Sometimes this is true. It depends on the developers.

Sometimes the developers don't have product skills but know they don't have product skills. This is also fine.

Sometimes the developers think they have product skills when they don't, and this is always a complete disaster.

I can't tell what situation the company described in the article is in. Perhaps the product manager is incompetent (there's lots of incompetent product managers out there), and the developers are correcting for this. Perhaps the developers have good product sense that the product manager is underutilizing.

But if the developers don't have the product skills they need, skills you get by spending lots and lots of time talking with customers instead of (or in addition to) writing code, no amount of process tweaking is going to fix the real problem - individuals assuming that their technical skill translates into product skills, and insisting on also doing something they're not good at.

I've often wondered why the subset of developers who lack product skills and/or the relevant domain knowledge frequently insist on getting involved with product anyway. After all, the head of human resources rarely insists on committing code.

I'm assuming this is for building a product, in which case the "why" is specced by market demand, and the "what" is little more than a goal of the product/feature - such as "product to allow consumers to record their taxes". The "how" is obviously more involved and includes things such as technology choices and specs on what the customer will interact with and how data will be stored.

The "what" would also often include essential features, such as "visual graphs or charts over time". These features would grow (or shrink) over time based on market feedback and testing.

You rarely want your programmers/designers/QA defining the "why" behind your product. If it's a startup, you're generally creating your business because of the "why" - you don't start a company and then use the company to find a "why". If it's an established company creating a new product, you'd have had market research and similar groups set up before the product even started to identify the "why".

Have the QA work with the actual product and not a spec - the users will be using the product after all, not the spec.

Why do these have to be mutually exclusive? There are plenty of cases, especially in enterprise, when if you solely( relied on spec-less QA, plenty of important use-cases would be missed.

The linked article spoke about creating the QA tests before the product was finished or even designed by the designer. No plan is going to survive contact with the enemy and no spec specific enough to have formal tests written for it is going to survive contact with reality. As clearly seen in the linked blog.

The PM needs to take a step back and let the designers/developers handle the tricky details of the spec, and let the testers test the resulting product and spec from them - not the high level initial spec. You don't need to bring in your testers until you have something concrete for them to actually test against.

As something concrete so that we don't get lost in abstracts: if you are building an accounting package that needs to calculate a user's tax rate from information pulled from twitter, then having your testers create a framework for testing exact tax rates before the product is complete is folly. You may only be able to generate a 'rough band' of tax rates, and now your whole perfect spec and testing is out of the water as all the values test incorrectly.

Rather get your team to build in a way to add tax information to the system, then once they have they have the method to get the best data possible you add details to your sparse spec and bring in the testers to test the real implementation against the real spec.

Obviously there are tons of other nice patterns to follow here that are heavily written about - but the "design in stone from on-high" is a very fallible approach. Not that it hasn't worked in the past - it's had some great success - but it requires someone with a perfect image of exactly what they want and a team willing to follow that person exactly.

As something concrete so that we don't get lost in abstracts: if you are building an accounting package that needs to calculate a user's tax rate from information pulled from twitter, then having your testers create a framework for testing exact tax rates before the product is complete is folly. You may only be able to generate a 'rough band' of tax rates, and now your whole perfect spec and testing is out of the water as all the values test incorrectly.

There is a specific reason why a QA plan is formalized before development: so that QA tests for client's requirement and not what is developed. Ideally what is developed will be what was needed but it would be foolish to assume that. If the QA was simply QA'ing what was developed, it is assuming that what was developed is what was needed. That is not a safe assumption to make, especially at scale and in enterprise.

You may only be able to generate a 'rough band' of tax rates, and now your whole perfect spec and testing is out of the water as all the values test incorrectly.

I dont quite follow but a QA plan does not need to hard code values. It should have test values where possible - in this case, may be the QA could find a couple of example twitter accounts and what the tax rate info. should be if done right. If you are saying the formula for tax rate may change mid way, that is okay as long as QA is notified. This way the QA and the dev independently do their own calculation and if they do it right, QA's manual calculation should lead to the same answer as when QA uses the functional app to do the calculation.

I agree completely when it comes to enterprise, and your QA team is likely large enough and developed enough to have most of the required infrastructure set up before the product even begins. However, the article seems to be dealing with smaller teams, but in particular it has the product manager actually working with QA to specify the QA plan from the outset himself.

Your point about building up a fairly generic testing system right from the start like that seems like a very good idea. Most QA I've worked with hasn't been anywhere near that farsighted and probably where I got that opinion from - seeing QA throw out their hacked together models and hacking up a new model (and stringing together hacked up models...) From experience, I think most companies take the hacked-together route for QA and put their junior recruits in QA. This is probably different in a Fortune 50 company? I've yet to work at one of those...

I'm slightly confused. Is LinkedIn pulling a Tumblr? Is Eric employed by LinkedIn now? Can anybody post posts on linkedin.com/today? Is a link at linkedin.com/today a stable URL or only good for today? Today when/where? What's going on?!

LinkedIn is allowing a few business leaders to write long form articles and have members follow them. Go to http://www.linkedin.com/today/post/whoToFollow

"So the product manager winds up actually having to use the software, by hand..."

maybe this is startup-land naivete speaking, but I pity the company whose product manager doesn't routinely use their own product.


What if your product is creating giant networked ovens for Nabisco assembly lines?

What if the product is an Enterprise Firewall Spam Detector IDS Bad Guy Defeater Gateway Proxy with more feature check boxes than atoms in the human body and the PM (who is a PMP, obviously) has a BA in English with a minor in interpretive dance?

What if the product is a series of experimental HIV vaccines?

Not every product in the world is a consumer webapp.


Good points. You definitely got me on the HIV vaccines, although that would be one quality-conscious product manager!

The number one skill a good product manager should have is being able to understand what the users need (not always the same as what the user wants, of course). Using the product, when possible, is a great shortcut. When it isn't possible, customer understanding is going to require phenomenal communication and imagination. That said, I would still be very wary of putting someone without some domain knowledge in charge of speccing out a super complicated product.

In my experience, generally product managers expect to be using a finished product. If the product manager is finding bugs that means that the QA process didn't do its job.

I'm a lot more hands on, but only because I've never experienced a QA process that actually did its job.

I dream of a world where bugs are fixed before features are added so that the product is in a shippable, usable state at all times and the PM can play with it all through the dev cycle.

I was a PM at a bigger company (~350) before jumping into startup land. After being the CTO and de-facto PM for a couple startups, I've had an idea that probably needs some vetting:

I think when you're still small, most typical PM functions should be distributed instead of centralized, with a manager getting in the mindset of managing people who are 10-20% PM / 80-90% engineer or designer.

While the overall product/business strategy and business requirements should be owned by one or a few founders/officers, I think as many people as possible in an early stage web/mobile product company should have most of the general skillset of a PM. Highly specialized talent might be an exception if you're creating a sophisticated product or have unique interface goals. But the general PM skills -- mockups, basic design principles, writing stories, writing requirements, managing a story/requirement from creation to deployment -- should be universal while you're small.

The inflection point goal at web/mobile startups is getting MVP after MVP out the door until you've pivoted or iterated your way to a good-enough product for a good-enough market. (Or good-enough product for a specific customer.) It's an all-hands-on-product affair.

With this in mind, I think the early CTO should be a hybrid of engineering talent and director of product management. Or perhaps depending on skillset a separate person (another co-founder or the person you thought should be the first PM) is that director of PM and the CTO is more like a lead architect. The point is that rather than doing all the product management or all the VP Engineering stuff, this person (or two) manages a team of hybrid engineers/PMs, retaining some important overall product and architecture decision-making responsibilities, but empowering and helping designers and engineers employ basic PM skills individually or split among a small group such that the person or small group owns more process for a feature.

This makes sense to me, but at a startup assuming that the CEO is the lifeblood of the idea for the company (as s/he should be) aren't they essentially the PM manager that you describe here? I guess this is a moot point, but we're obviously only focusing on a startup that is heavily technology focused.

What about one where the pudding is actually a process or physical commodity and the technology portion is merely an extension of this?

Having designers develop wireframes and designs without the input of software engineers is like having a product designer design the dashboard of a car without the input of automotive engineers.

Wireframes should be signed off on by engineers before design starts, and design should be signed off on by engineers before it is approved.

Sounds like this is the root of the problem:

"When the programmers get it (the specs), they often start negotiating with him about what's going to be built. They exchange countless emails, and he's being constantly interrupted and being asked to clarify exactly what the spec means. "

A simple solution is: speaking about the project/product feature with your developers first. Understand what will take long, what won't, what can be stripped out in the first iteration. Once this is done, work with designers to push something out.

Another super simple solution is videos.

Writing takes time. Wherever possible I try to make videos for the designers or even better have live calls.

In terms of idle time, there should be always a backlog of specced out work or bug fixes that the developers can focus on. Failing that, they can work on optimising past projects, refactoring or reading about new things.

Writing takes more time than producing videos? Are these videos largely unedited? And if so, how do you measure the time lost in the inefficiency of interpreting the video?

Unedited videos, remember, this is for design briefs. For developers, videos may not be the best form.

I can imagine on some very complex projects videos being a difficult medium. But for me it's great: I just record the things I want to get done, bring up examples from other websites, use the mouse as a pointer to direct the viewers focus. I summarise what I want to be done at the end.

Usually I send over the video and checklist of things to do.

I have been working both as a product manager and as a lead developer. I think both roles are designs of companies where hierarchy are more important than the outcome. A healthy company probably lacks Product Managers, Lead Developers and System Architects and those roles are filled by loosely formed teams based on interest in the problems and products people are solving/building. Where I come from, it is called taking responsibility.

I think the article shows correctly the common problems at most organizations today. Many organizations don't have engineers who really care about usability over functionality, so simply "handing off high level wants" just doesn't work outside of a couple of rehabbed buildings in Frisco.

It's easy to have a reference to the Stripe article, where there are no PMs. But, this environment is the exception rather than the rule. After working in a few medium sized places, the ratio of engineers who place an equal level of detail on usability & functionality vs those that place a higher value on functionality/architecture is easily 1:6. And you can guess which ones are usually the Sr members. To their line of thinking, usability isn't something they have ever had to worry about.

I do agree with a previous poster that this is something that the startup culture is starting to change, but I would bet that this change won't be visible at most organizations until at least 5 - 8 years out as the engineer talent changes.

Now, I would say this problem is something that can be changed with some UX standards. The PM creates flowcharts and/or wireframes of the proposed solution > hands it over to the agile team > dev + ux discuss any flows that fall outside of established standards. As a PM myself, I would love this. To be required to only provide more end user/market requirements as needed would be ideal.

One issue with this is that usually with organizations that have these issues, the investment just isn't there in the area of UX (I sit here reflecting on my current situation).

I will bet that the product team disfunction mentioned in the article is directly reflected in said team's products. :)

In the early stage startup a Founder/CEO should also play a PM role.

It might be not obvious, but the main problem having a dedicated PM on the team, is that unless PM has very strong engineering or business experience [and in this case that person should either code or bring in money], the PM would fill very insecure , surrounded by highly experienced people, who can actually do things. Cost of somebody on the team, feeling very insecure and trying to bullshit/manoeuvre/bully his way around outweighs any potential benefit to the team.

From my personal experience, I've seen projects fail solely because of PMs protecting their turf.

That's what happens when you don't involve engineers in the project spec part of the process, they need to be consulted much earlier and be partners in helping define the feature-set and timeline, not impose it from above with an arbitrary set of features.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact