Dylan Field on Figma and Product Taste
Source: Lenny’s Podcast (live at Figma Config) Speaker: Dylan Field Source URL: https://www.lennyspodcast.com/dylan-field/
Key ideas
- Intuition as hypothesis generator: product intuition is not a verdict — it generates hypotheses that must be debated, tested against data, and winnowed. The best leaders distinguish their hypotheses from facts.
- Simplification as a continuous job: irreducible complexity means every addition interacts — “one plus one sometimes equals one and a half.” Simplicity requires active, ongoing effort, not a one-time design decision. Everyone is responsible for it, not just leadership.
- Minimally awesome product: from co-founder Evan — quality, features, deadline: choose two. Software can iterate, so you can ship features + deadline and improve quality over time — but you must not lose quality in the iterative phase either.
- Ship fast and iterate: Figma took 3.5 years to launch and ~5 years to a paying customer. Dylan’s conclusion: “get it out as fast as you possibly can.” FigJam shipped quickly and succeeded; Dev Mode took much longer but required it to find the right value proposition.
- The PM role: the best PMs create frameworks with a point of view and strategy that bring everyone along — so the whole team has shared headspace about what they’re building and why.
Product taste and intuition
Dylan frames product intuition as a hypothesis generator, not an oracle. A hypothesis needs to be put forward, debated, tested against data, and worked down to a “working hypothesis” from which to move forward.
The input side: Dylan reads every mention of Figma anywhere on the internet (Twitter, support channels), asks a lot of questions, and tries to get to root problems rather than surface requests. “Sometimes people are saying ‘I need X’ but they really want Y or Z.”
The output side: when he is shown a design and it feels too complex, he furrows his brow and insists there must be something simpler. This is intuition as a forcing function for a specific kind of question, not as a final answer.
Changing his mind: he asks for concrete artefacts and examples, asks follow-up questions, and says “let’s go find the answer to these questions and come back.” When people return with data, he moves. He is aware this can bottleneck the organisation and manages for it.
Simplification
The central principle: irreducible complexity. From an essay Evan introduced early on — “one plus one does not equal three, it sometimes equals one and a half.” Every addition to a system makes it more complex and potentially worse.
The challenge for a tool like Figma: it needs to become more powerful, but doing so without adding complexity is extremely hard. There are parts of Figma’s product where “we made all the right local decisions and yet together they’re too complex and they’re not working anymore.” The fix is to revisit the system.
The dictum: “Keep the simple things simple. Make the complex things possible.”
Everyone is responsible for simplicity, not just the CEO. But top-down forcing function is part of the mechanism.
Early Figma and the community-first go-to-market
Dylan scraped the Twitter social graph using Gephi (a network visualisation tool) to identify the most central designers in the design community. He then looked at their work, identified the ones he admired as a “fanboy”, and reached out to buy them a coffee. Most said yes.
The initial purpose was learning, not acquisition. Getting feedback from designers who are “really good at giving feedback” improved the product faster. Conversion to users and evangelists came from the product improving as a result of those conversations, not from a formal growth programme.
Lesson: reaching out to people you admire works; the design community is generous.
First paying customer was Shishir Mehrotra’s team (then called Krypton, later Coda). Dylan turned the car around mid-drive home to fix what turned out to be a wifi issue. Shishir didn’t know he was the first customer until Dylan introduced him as such years later.
Minimally awesome product and the launch decision
From co-founder Evan: quality, features, deadline: choose two.
- Ship features + deadline → improve quality iteratively over time. Works for most software because iteration is possible.
- Ship quality + deadline → fewer features, but minimum quality bar.
- Ship features + quality → push the deadline.
Counterpoint to “ship fast”: there is a minimum bar of quality for what you ship. Iterating on quality is still necessary — you cannot ship fast and then ignore quality forever. Dev Mode was an example where speed wasn’t the answer: it required multiple failed directions before they found the right value proposition for developers.
The term: minimally awesome product — the smallest scope that is genuinely great for its scope.
The PM role
Dylan’s view: if you zoom out, the lines between PM, designer, and engineer are always blurry. A team needs all these qualities together:
- Technical understanding
- Business objective awareness
- Taste and craft
- User dialogue
- Visual/UX care
Where PMs fall down: treating the role as process management and losing sight of the user problems and the strategy. Good PMs “create frameworks with a point of view and strategy associated with them, so everyone knows what the destination is and how to get there.”
His test: if a PM’s work could be replaced by more process, they’re not doing the strategic work. If their framework disappears and the team loses shared headspace, they were providing real value.