Build lean, learn quickly

My approach is to build only what's necessary to answer the question in front of us, and to treat every round of testing as an attempt to break the idea rather than sell it. The faster you find out something is wrong, the less it costs to fix it, and the more confident you can be when the evidence actually holds up.

Needs first, aesthetics second

Successful products solve a genuine problem well. Good aesthetics are the result of good thinking, not a substitute for it. When I'm working on something, the question I keep coming back to is simple: does this actually meet the need? Everything else follows from that.

Hold out for the hell yes

Most products launch to a polite shrug. Teams mistake the absence of strong objections for validation, but lukewarm is just a slower kind of failure. After hundreds of hours of testing with real people, I've learned to tell the difference between "yes, that works" and "yes, I actually want that." The first gets you a product. The second gets you one people come back to.