One reason I wanted to talk with Will King is that he brings a background I do not hear referenced enough in software conversations: industrial design.
That ended up being a really useful lens. It gave us a way to talk about software not just as logic and interfaces, but as something people interact with through habits, assumptions, limitations, emotions, and mental models. In other words, through human factors.
Human Factors Are Product Factors
One of the most helpful parts of the conversation was Will's point that software teams often think very clinically about consistency, layout, and automation while missing the bigger question: easy for whom?
He connected that to things like age, background, timing, and user expectations. The same feature can belong in the critical path for one audience and be a distraction for another. The same interface can feel obvious to one group and opaque to another. I liked that framing because it expands product thinking beyond "is this clean?" into "is this right for these people?"
Product Debt Feels Different Than Technical Debt, But It Accumulates the Same Way
Will also gave a really useful explanation of product debt. He described an education product that kept adding more course types and more ways of learning because each addition sounded valuable on its own. But in aggregate, it made the experience harder to understand and harder to complete.
That is product debt in a very recognizable form: a pile of individually reasonable decisions that makes the product heavier, noisier, or less trustworthy. I thought that was a strong complement to the technical-debt language most engineers already know.
He also made an important distinction later in the episode: if something is broken, fix it. If people simply do not like your chosen solution, that still matters, but it needs interpretation rather than immediate obedience.
A Better Way To Use Agents
Will's closing advice was one of my favorites in the season so far: use agents more for gathering than for executing.
That fits the rest of the episode really well. If agents help you explore adjacent ideas, pressure-test assumptions, or think through different user demographics and constraints, they can make you better at observation before they make you faster at implementation.
So the practical takeaway I would carry forward is this:
- use agents to bring back possibilities, not just code
- give them richer context about the users and the situation
- then use your own judgment to decide what matters
