A World Without Product Managers

I've been a Silicon Valley product manager for 23 years now, and I've come to a realization. 20 years from now, there probably won't be a separate function called "product management". The processes I've been doing for most of my career will move into engineering and design. I think this is a good outcome, but it's disorienting to be part of the transition to a new world order.

Why do I think we'll end up in a world without product managers? Product managers have historically acted as "mini-CEOs" for project teams. They owned the product strategy, gathered customer and competitive input, prioritized features, guided design, wrote the product plan, and decided (with QA) when the product was ready to ship. But now…

• It's always a good idea to reduce the length of the chain from customer-to-developer.
  • Even in my old "waterfall" days, I argued that good product managers should make themselves "invisible". Our job was to present the customer and competitive data in such a clear and compelling way that the team could see for themselves what needed to be done, and make good decisions on their own. Only insecure product managers would impose themselves into the process and guarantee job security ("I think that button should be blue… because I say so.")
  • If we can set up engineers and designers to hear customer feedback directly, and interpret it properly, then we are eliminating a potential source of data loss: the product manager's opinion.
• Specs are much lighter now. We are shipping Minimum Viable Products and learning from the market.
  • With the Lean Startup approach, rather than build a massive "Apollo Project" with a large team using a detailed spec, we ship the core features first and watch user behavior to figure out what to do next.
• Higher-level development tools (e.g. Ruby on Rails) and powerful, cheap services (e.g. Amazon Web Services, UserTesting.com, Curebit, Gigya) free engineers to think on a higher level.
  
  • The complexity of a service like When.com (which my first company built in 1998 using C++, our own hardware hosted at GlobalCenter, our own monitoring tools, etc.) required a higher level of specialization. It was so hard just to get the thing to work at all that engineers and designers had little time to think about why we were building what we were building. They had no choice but to trust the product manager's priorities.
  • When engineers and designers are plugged directly into the market, they can make better decisions and their work is more fulfilling.
• Because of these low-cost tools, consumer-grade services can be built for very little money.
  
  • A $200K angel round is sufficient to get a service up-and-running. Because it is possible to build a service on a shoestring, it becomes a competitive necessity. There is little room room for extra headcount if a function (like product management) can be absorbed by other team members.

There are plenty of challenges in this new process:

• How do you keep investors (and upper management) informed and happy? They are used to seeing hard deadlines and detailed specs, since they still have to worry about when the money runs out.
• Finding engineers and designers who are "full stack" and curious enough to take on these new responsibilities is difficult.

I feel like my job now is to find a way to infuse product management thinking into the rest of the team -- not BE a product manager. To the extent I make the decisions (or priorities), I disempower the team. This requires a kind of "letting go" that is very uncomfortable. It requires trusting a team that you may not have worked with before to use a process that is still under development.

I'm looking forward to coming out the other side. Feedback and commiseration encouraged.

A few relevant links (thanks to my teammates at Byliner):

• Stop prioritizing everything: http://www.43folders.com/2009/04/28/priorities
• Throw out customer requests after you read them: http://gettingreal.37signals.com/ch05_Forget_Feature_Requests.php
• Resist the temptation to respond too quickly to feature requests: http://gettingreal.37signals.com/ch05_Start_With_No.php
• What's it's like to work at Github: http://opensoul.org/blog/archives/2012/06/05/whats-it-like-to-work-at-github/, and how it's managed: http://tomayko.com/writings/management-style

Comments

[Daivd]

Any product manager that dictates design elements instead of listening to a UX team is doomed to fail by the way.

[Patric]

Dev Teams i've known regularily needed the "external" input of a PM to make quick decisions. Who else can have the overview over the whole software and know what fits where or if feature A is needed for the next sprint?

Sure the UX Team might have a lot of impact on those decisions, but are seldom empowerded to be in charge of the whole Product.

a) you have distributed decisions which might not be aligned over the whole product, or have long discussions about whats "right"
b) you have a dedicated person (PM) or team (UX) who calls the shots and gives the dev team fredoom to just go GitHub diving all day.

[Michael Bishop]

I would disagree that product management is dying. If anything, you see more product management opportunities in the market than ever before. Any product manager that dictates design elements instead of listening to a UX team is doomed to fail by the way.

Ultimately, product managers are necessary because you need to have someone that is accountable for the success of the product and therefore must help steer the ship in the right direction. There are many types of skills required to do this including soft skills (resolving differences of opinion on the team, analyzing customer data which is arguably more complicated to do now than ever with all the latest tools, etc.) and hard skills.

[Jason_Milstead]

I agree 100%. I, too, have been working in Product Management my entire career in Seattle starting at RealNetworks, Rhapsody, wetpaint and now at WhitePages. The PM role is slowly dying this decade as the democratization of customer insights, web analytics, business models and APIs are defining how products are built and monetized. I likely couldn't get a job as a PM today without a CS degree, however I don't feel threatened by this. The value that the PM discipline brings is about building relationships between teams, companies, investors and customers. Engineers build products but rarely can a talented engineer show the empathy that is needed to foster a productive, healthy relationship to scale a business. We have been trained to look across products and competitors to find the connections and opportunities to improve the product which is hard to do when you are buried in GitHub all day. Of course, trying to prove this value to engineering-driven organizations won't be easy.

[Ted Barnett]

Seems like the Lean Startup approach would not work so well in a client-services scenario. But I saw Eric Ries speak today and he has been pleasantly surprised to see the method applied in areas even he thought would not work (e.g. NASA). Maybe clients would have to shift to believing that they are buying *learning* (e.g. calibrating metrics for their business plans).

[Peter Montgomery]

I like this post. It brings together a lot of topic related to the way Agile has impacted Product Development and Management. Question: Outside of startups and in-house development, how do you see this being inherited with the Client Services world in which clients want to know what they are paying for "up front".