Hacker News new | comments | show | ask | jobs | submit login

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.




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

Search: