Aaron D. Francis and I covered a lot of ground in this episode, but the thread I kept coming back to was this: users often hand you a solution when what you really need is the problem underneath it.
That is a useful framing at any point in software, but it feels especially important right now. If agents are getting better at implementation, then the value shifts toward the people who can think through the full vertical slice, understand the human need, and decide what ought to be built.
Aaron has been building Solo while teaching and writing for developers, and that mix made this conversation especially practical.
Three Questions I Kept Hearing
Aaron kept returning to versions of the same questions:
- What are you trying to do?
- What did you expect to happen?
- Why are you trying to do it that way?
I liked that because it gives a better path than just accepting a feature request at face value. If someone says they need a button, the real work is understanding the intent, the expectation, and the mismatch between the product and their mental model.
Where This Gets Hard
The hard part is that you still need a product point of view. Aaron was not arguing for turning every user request into a roadmap item. He was arguing for separating the signal from the implementation suggestion.
That showed up again when we talked about being "technically correct." A product can be internally tidy and still be frustrating. The examples around duplicated affordances, back-button data loss, and paving the path people naturally want to take all point to the same lesson: usability sometimes requires letting go of the cleaner technical story in favor of the better human one.
The Part I Especially Agreed With
I really appreciated Aaron's emphasis on empathy. Even if you are not in the room with users, you can still imagine the person on the other side of the screen trying to finish work and go home. That is a much better starting point than assuming the user should have known better.
So if I were turning this episode into a small practice, it would be this: the next time someone asks for a feature, do not start by evaluating the feature. Start by asking what outcome they were trying to reach and what they expected your product to do.
