Studying Lee Robinson, Cursor's new VP of Developer experience
Lee Robinson helped Vercel reach more than $200 million in ARR and Next.js reach 1.3 million active developers. This study of his writing and interviews turns that work into a practical system for documentation, education, community and developer marketing.
Lee Robinson is Cursor's VP of Developer Experience and previously led developer experience at Vercel. In this solo episode, Jack studies Lee's public writing and interviews to extract the principles behind his work.
The result is a playbook for treating documentation as product, teaching with realistic examples, closing the feedback loop with individual developers, earning trust through technical honesty, and communicating with unusual clarity.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
Why should documentation be treated as part of the product?
Documentation can make or break a developer product, and it now appears everywhere: on the website, inside the editor and in the context retrieved by AI tools. A feature is not finished without reference documentation. The best docs help beginners understand the first step while still giving experts precise details, examples and escape hatches.
What makes technical documentation easy to use?
Write the way you speak, remove jargon and idiom, and make pages easy to skim with clear structure and many examples. Use progressive disclosure so the simplest path appears first and deeper detail arrives when it is needed. Precision and brevity are compatible with completeness when information is layered instead of dumped onto the reader at once.
Why do developers need both a quick start and guided learning?
A quick start answers 'can I make this work now?' while a guided path builds a durable mental model. Reference pages alone are not a curriculum, and AI answers often optimize for the immediate task without teaching the sequence of concepts. Products should support both the impatient developer and the person trying to understand the system properly.
Should documentation acknowledge product gaps and workarounds?
Yes. Hiding a limitation does not remove it; it only forces every developer to rediscover it. Document the workaround while the product is being improved. Use automated checks for broken links, JSDoc close to the code, AI-assisted review and direct feedback mechanisms, but keep human judgment responsible for whether the explanation is genuinely useful.
What does it mean to treat community as an exchange rather than an audience?
A developer community gives as well as receives: people report bugs, suggest fixes, open pull requests and explain where the product fails them. Meet developers in the places they already spend time and treat those conversations as product work. The goal is not merely to broadcast announcements to a large follower count.
What is the feedback loop Lee advocates?
Talk to a developer, keep asking why until you understand the underlying problem, fix it quickly, then tell that same person what changed. Teams often perform the first three steps and forget the last one. Closing the loop proves that feedback matters, creates a relationship and gives the developer a reason to try the product again.
Why is education such effective developer marketing?
After testimonials, education is one of the strongest forms of marketing because it creates value before asking for anything. Turn repeated support questions into guides, show realistic applications rather than toy hello-world demos, and explain how your own product was built. Reference material and structured learning serve different needs, so a complete education system contains both.
How does technical honesty build trust?
Developers notice buzzwords, broken code and promises that exceed the product. Demonstrating real use, including how the team dogfoods its own tools, is more persuasive than inflated claims. Lee's public advice is to stay humble and compare the product with its own previous version rather than manufacturing attacks on competitors.
What does concise communication look like in practice?
Put the bottom line first, make the message scannable, address likely fears, and state exact dates, costs and actions. Personalization should reflect the recipient's actual context rather than inserting a first name into a template. The reader should be able to understand what happened, why it matters and what to do next without decoding the writer's process.
How should a developer community handle conflict?
Moderate with kindness and firmness. Encourage a culture where people give far more than they ask, allow productive tension long enough to surface the real disagreement, and move personal conversations into private channels. Muting before blocking gives people room to reset without sacrificing the safety of the wider community.
Links & references
- Lee Robinson ↗
- Lee Robinson on X ↗
- Peter Yang interview ↗
- Swyx interview ↗
- Gonto interview ↗
- Developer marketing community ↗
This episode is brought to you by WorkOS.