Computer and the Human
DevRev is trying to get rid of the PM. Really?
I often hear from early prospects that they think one of DevRev’s goals is to get rid of PMs. And in many sit-downs with startup founders — interactions in which I get to learn the most — I hear them talk about (a) the role of a product manager, (b) the blurry lines between different PMs: a project manager, a program manager, and a product manager, and (c) the role of founders in effective product management during the journey of — an often elusive — product-market fit.
In organizations with strong developer (or design) culture, I sense a certain schadenfreude in developers when they hear the prospect of getting rid of the PM. Most developers hate process, and the idea of being managed by folks who don’t code. As craftspeople, they appreciate depth, uninterrupted flow, deep work, and constant chiseling. As a corollary, many of them have this deep-seated contempt for breadth, which is a proxy for “shallow” in their minds.
In the book, Range: Why Generalists Triumph in a Specialized World, David Epstein delves into the dichotomy between generalists and specialists. I feel it’s a false choice to pick one or the other, because the best builders I’ve met have T-shaped skills. The best developers have depth in one layer of the stack, yet they are generally curious to debug problems across the full stack. The best specialist doctors are equally good at “working the whole body” with their knowledge and curiosity of general medicine. I can go on and on about this with examples, but that is a topic for another blog (on paradoxes).
Computer vs. Human
I believe that what the developer is really asking of the manager is to stop fighting fires all the time. Peter Drucker, in a 1967¹ treatise headlined The Manager and the Moron, speaks about this very same issue in middle management.
¹ I apologize for how the 1960’s assumed a manager to be a man. We’ve come a long way since then!
I reckon we’ve a similar issue in the mid-office of software and SaaS companies. A fire-fighting PM is constantly in meetings, handling escalations, attempting to align people — working hard, yet not realizing what the veritable computer could have done to organize their lives, made their customer meetings more meaningful, or helped them see the forest for the trees.
What Peter Drucker’s computer can do in today’s day and age
Cluster. Classify. Communicate.
Over the course of these last twelve months, we’ve spoken with hundreds of companies and their founders, CTOs, CPOs, and CCOs. They speak passionately about these broad categories of problems:
We’ve tons of data, logs, and metrics, and yet we’re constantly firefighting with transactions: on-calls, escalations, new-feature-requests, incidents, and the like. We don’t have a clue on what trends are emerging², which features are our Achilles’ Heel³, what feature requests are adjacent and truly cluster together, and what’s keeping our developers busy⁴
We’ve no dearth of channels, systems of record, and tools for planning, and yet we need countless number of people — and meetings — to communicate between disconnected departments and with anxious customers
We’d love to be more product-centric, user-centric, and operationalize the concept of product-led-everything to reduce cost of operations, go-to-market, and customer success and improve productivity
The computer can help with many of these things, if the system were to solve for syntactic and semantic search, ease of customization, (machine-assisted) continuous planning, real-time collaboration, and autonomous recommendations. The PM, then, would not have to stop people in the hallways to ask: “is it done” and “when will it get done.”
² how do we cluster and classify
³ can we deliver product and user analytics to all
⁴ can we grasp the continuous “commerce” of GitHub
Product-Led Growth (PLG) is Beyond Just Growth
Product-led thinking has the potential to make back-office project and program managers into product managers — mid-office professionals curious about design, shelfware, end user engagement, and customer success. It would be so much more liberating for developers to prioritize and deliver, driven by an outside-in view than simply based on resource allocation, burndown charts, and arbitrary efficiency and productivity KPIs.
Good product managers want to be like general managers, worrying about go-to-market, product enablement, and overall monetization. But good PMs also want to bring this product- and user-centric mindset to every sphere of a software company’s activities:
- Product-Led Engineering: how developers and PMs agree on feature flags and features, user analytics, metrics, A/B testing, consumer-grade APIs (and webhooks), feature request clustering, customer-centric sprints⁵, and revenue-driven prioritization
- Product-Led Operations: how production incidents get auto-routed to developers based on their Git and CI/CD activity, features get deployed in production, sandboxes get created and destroyed with 1-click experiences, and microservice outages quickly get translated to impact on users and features
- Product-Led Support: how users converse in real-time with front-office staff, cases get deflected and questions answered in real-time⁶, tickets get created from inside the app, and PMs communicate back with end users in the app
- Product-Led Growth: and last but not the least, how end users become the advocates who act like micro-sellers of the product, because they believe!
⁵ account-centric outcomes in every sprint, not simply features
⁶ as they would on a Google Search box
At DevRev, we are striving to have our PMs become awesome product managers who (a) design, i.e., think and propose visually, (b) spend inordinate amounts of time in customer meetings building gut and data around needs vs. wants, (c) lose sleep on in-app everything⁷, (d) solve problems in engagement with nudges, gamification, and low latency thinking, and (e) solve tough business problems that must be “looked at from 16 different angles.”
Getting burned out fighting constant fires would mean the computer has failed the human, because after all, the computer — in the cloud now — is also being paid to think!
P.S.: And if you haven’t come to conclude already, the PM is here to stay, just fight fewer fires.
⁷ training, support, discovery, onboarding, purchases
