Biz Stone came to Draper University last month. Twitter co-founder. Medium co-founder. Currently working on something new called Jelly, a Q&A network, though he didn't talk much about that.
We get a lot of speakers. Most of them are good. Some of them are great. Biz was different in a way that took me a day or two to identify.
Most founders who come to speak talk about what they built. They walk through the origin story, the hard times, the fundraise, the scale. The talk follows a predictable arc and it ends with something like "follow your vision" or "hire slow" or another principle that's true but not actionable. The cohort applauds. Two weeks later, no one can remember what was said.
Biz talked about taste.
Not in the fashion sense. In the product sense. He said that the most important thing in building consumer products is developing a genuine point of view about what's good, and then being willing to act on it even when the data says something different. Not in spite of data. Alongside it. He was describing taste as a skill you build, not a property you have.
He used the example of the Twitter character limit. 140 characters was not a research-derived feature. It was a constraint that came from SMS, carried forward because the team had a feeling it was right, and kept because it shaped behavior in ways they liked. The constraint made the product. A less opinionated team would have increased it the first time users complained.
The cohort pushed back on this. One of the founders asked how you know when to trust taste versus when to trust users. Biz's answer was something like: taste tells you what to build, users tell you if you built it right. If users are confused by something you thought was elegant, that's feedback on execution, not evidence that the underlying idea was wrong.
I've been thinking about this distinction since.
In AI products, specifically, there's a version of this that matters. The data is very loud. You can measure everything. You can optimize against almost any signal. But what you're optimizing toward is a choice, and that choice is either intentional or it defaults to whatever was easiest to measure. Teams that don't have a point of view about what good looks like end up with products that are technically optimized but not actually good. The metric improved. The thing got worse.
We've had this experience at Zillion Pitches. We optimized our engagement metric and users spent more time in the app. We had made the report harder to understand, so they were spending time confused. The metric didn't know that. We needed to know it.
The other thing Biz said that hasn't left me:
Kill things faster than feels comfortable.
He wasn't talking about companies. He was talking about features. He talked about the number of things Twitter removed or never shipped that would have felt like obvious additions. Features that sounded good in the room, that got built, that looked like progress, and that were quietly killing the product by adding complexity without adding value. The discipline of removal is harder than the discipline of addition because removal feels like failure. It isn't.
He said the best product decisions he ever made were things that felt too severe at the time. The severity was usually right.
The cohort was full of people who had never shipped anything. Hearing this from someone who built one of the most used products in the world, and who had clearly thought hard about what made it good rather than just big, landed differently than the usual origin story arc.
I've started applying the taste question to program design. What do I actually think is good, independent of what's easy to run? That question has already changed three sessions I was planning to keep.
With gusto, Fatih.