Product and Process

Deciding what to build, how much of it, and how to know when it is enough. This is the work that decides whether the engineering matters.

A lot of what gets called a technical problem turns out to be a requirements problem wearing a costume. Teams reach parity on a feature nobody uses, build the general solution to a specific question, or spend a quarter on something a single conversation with the customer would have killed. One story that keeps coming back: a plan built entirely around what someone believed an executive wanted, where nobody had asked the executive.

Episodes here cover requirements, estimation, MVPs, scope, prioritising by consequence, and keeping engineering pointed at the friction the rest of the company actually feels.

55 episodes · browse the full archive

Other topics