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