Constraints and product work

Inside the box

David Epstein has a brilliant way of framing things. His book Inside the Box is about how constraints make us better.

I haven’t read it yet. But the idea, as Epstein explains it in interviews and videos, just clicks.

Mendeleev arranged the periodic table while racing to finish a chemistry textbook. A deadline helped turn years of accumulated knowledge into a system. Tony Fadell, the lead designer of the iPod, would freeze feature changes until the next development cycle. At Nest, his team designed the packaging—the literal box—before the product, forcing themselves to decide what would fit inside. Twitter’s character limit gave the product its form.

Then there is Nvidia. In 1997, it was a struggling late entrant in the graphics accelerator market, with little cash left. The usual chip-development process involved designing, prototyping and then manufacturing. Nvidia could not afford the time. It tested the design through emulation, skipped the physical prototype and sent the chip straight to manufacturing. The RIVA 128 (code-named NV3) sold 1 million units in its first 4 months.

Epstein’s point is that unlimited resources do not necessarily produce the best results. We have seen this story play out often, especially when start-ups upend slower incumbents.

Product management and constraints

I have seen it play out in product and tech teams too. Small teams, working within a sprint and without an over-engineered process, can do great work. Time-boxing adds a tangible constraint—and a dash of excitement. Without one, you stare at an ocean with no visible end. The journey gets boring.

There is another benefit to seeing work in 2-week cycles: you realise how little time there is in a year. You get only about 24 sprints. By June, the year can feel almost over because just 12 remain.

A disclaimer: I am not a fan of teams making the 2-week sprint their whole identity. Shreyas Doshi, one of my favourite product leaders, describes that as project-management rather than product-management thinking.

We need both. Product management sets the direction: what should we build to win? Project management supplies the speed: how do we orchestrate the work? True impact, like velocity, is a vector. It needs both speed and direction.