Wayne Allan said something in this conversation that I think is worth carrying around for a long time: building the thing right is downstream of building the right thing.
That idea sounds almost too obvious once you hear it, but Wayne backed it up with the kind of story that makes it hard to forget. He talked about helping build a system that could handle the entire population of Australia logging in at once, and then launching it to basically no users. Technically impressive. Product-wise, devastating.
The Story That Explains the Whole Episode
That anecdote holds the whole conversation together for me. It captures the temptation engineers feel to optimize architecture, scale, and implementation quality before they have enough confidence that the thing is worth building in the first place.
Wayne has worked on both the engineering side and the product side, so he was able to describe the trap without caricaturing either role. He was not arguing that technical quality does not matter. He was arguing that its value depends on context.
What I Took From Wayne's Approach
I liked three parts of his approach in particular:
- Engineers are often in a very good position to contribute to product decisions because they can see faster, simpler ways to satisfy a real need.
- You have to stay in love with the problem, not the solution, especially when a lo-fi version of the idea could validate the core value much faster.
- When someone is attached to an idea, "yes, and" is usually more productive than a flat "no."
That last point stood out to me. Wayne was not talking about manipulation or fake agreement. He was talking about keeping a conversation alive long enough to redirect it toward the valuable part.
One Question Worth Using More Often
Near the end, Wayne pointed to one of the best habits in product work: ask people how they solved the problem in the past.
That is a much better question than "Would you use this?" or "Do you like my idea?" It gets you out of politeness mode and into behavior. It also keeps you from leading the witness with your own solution.
So if I were pulling one concrete action item out of this episode, it would be this: the next time you are validating an idea, do not pitch the solution first. Ask how the person already handles the problem today, and listen carefully to what that reveals.
