Korva is a scroll of the internet’s best ideas.
How the ratio began
Early internet companies had founders talking straight to engineering and design about what to build. As they scaled, someone had to take over the details of execution, and product management became a specialist job. Then a staffing ratio settled in: every time you hire six engineers, you add a designer, a PM, and an engineering manager.
The cost at scale
At a company serving a billion daily users, that ratio produces a lot of engineers and so a lot of product managers, including on work like notifications infrastructure, where engineers understand the system perfectly well. Hiring that many PMs infantilizes engineers and designers who are capable of good decisions but never had to make them, because a PM was always there to babysit.
Whatnot's approach
Whatnot, the live-stream shopping marketplace, was built on the premise that product management is a trade, not a qualification. PMs go where one problem needs real leverage, and elsewhere design and engineering go through the same steps, product review included. PMs map to problems and core projects rather than to engineering teams, so some years a team has no PM even with plenty of product work going on.
Why did product management become its own job?
The role is usually traced to a 1931 memo by Neil McElroy at Procter & Gamble, who proposed that a dedicated brand man should own each soap brand, starting with Camay. The idea spread as consumer goods companies grew and needed someone to coordinate marketing, manufacturing, and sales. Software companies adopted it later, and by the 2000s the product manager was a standard role at large technology firms.
How do repetitions build decision-making skill?
The psychologist Anders Ericsson and colleagues described deliberate practice in a 1993 paper in Psychological Review. It means repeated attempts at a task with fast feedback, and it separated expert performers from others in fields like chess and violin. Product decisions fit the pattern when a person makes a call, ships it, and sees the result. A person who only reviews other people's calls gets far fewer of those attempts.
Why do bigger teams get slower?
In The Mythical Man-Month in 1975, the computer scientist Fred Brooks observed that adding people to a late software project makes it later. One reason is communication: the number of possible pairs of people on a team grows roughly with the square of the headcount. More people also means more handoffs and more reviews. That observation is now known as Brooks's law.
More from Lenny's Podcast: Product | Growth | Career
