Korva is a scroll of the internet’s best ideas.
Cheap features make product harder
Features multiply
Product surface area expands in bursts, because people figure they can make features quickly and push multi-thousand-line pull requests. Left alone, that makes things incredibly chaotic, so product teams are constantly fighting to simplify and to find the interactions and workflows that scale best.
The new bottleneck
With engineering less bottlenecked, the bottleneck becomes understanding the workflows and needs of users and which products actually drive the most revenue. That shows up in the makeup of the teams: a higher ratio of PMs to engineers, with fewer engineers per PM expected as coding agents improve. Mercor has grown more than 10x in headcount in the last year, so product and engineering have to grow in lockstep.
Skills that remain
The skills shift too. A couple of coding-agent tools will do everything a PM needs, so tool diversity shrinks, and skill issues have almost gone away. What is left is judgment about whether time is going to the thing that will drive the most business value, and all work is starting to look higher level.
Why do more features make products harder?
Hick's law, formulated in 1952 by psychologists William Edmund Hick and Ray Hyman, found that the time to make a choice grows with the number of options. Every added feature also adds menus, settings, and interactions that must work alongside the rest. Software designers call the slow pileup feature creep. A product with many half-used features is costly to explain, test, and maintain.
Why are huge pull requests risky?
A SmartBear study of code reviews at Cisco, covering thousands of reviews, found that reviewers' ability to catch defects dropped sharply once a review passed a few hundred lines. Large changes also touch many parts of a system at once, so the effect of one edit hides inside another. Reviewers tend to skim what they cannot hold in mind. The study's authors recommended keeping reviews under about 400 lines.
Why does the bottleneck move when engineering speeds up?
Eliyahu Goldratt introduced the theory of constraints in his 1984 novel The Goal, holding that a system's output is limited by its single tightest step. Speeding up any other step changes nothing until the constraint is relieved, and then the constraint moves somewhere else. Manufacturing plants used the idea to find which machine was holding up a production line. In software, relieving the building step shifts the constraint to deciding what to build.
More from 20VC with Harry Stebbings
