Charmaine Lee’s 10 rules for building developer tools that feel like magic
As a product manager working on Snapchat’s Lens Studio for AR developers, Charmaine knows what it takes to delight creators.
Share Charmaine Lee’s 10 rules for building developer tools that feel like magic
Hero illustration by Luis Mazón
The first product Charmaine Lee ever loved was an unassuming code editor in Neopets that let her personalize her profile with custom colors, fonts, and images in real time. Fast forward several years, and the software engineer–turned–product manager has loved many other tools for developers like the Slack API, Unity, and of course, Lens Studio by Snap AR, the AR experience builder she’s working on now. “These are all dramatically different tools used for very different purposes,” says Charmaine, “but the thing that unifies them is a feeling of magic.”
The problem with magic, of course, is that it’s not easy to define—and even harder to replicate. According to Charmaine, it’s tempting to judge the merits of a product based on its UI, but this is, in fact, a trap. “Even the most experienced product managers occasionally forget that a sleeker design doesn’t necessarily equate to a better product for users,” she says. So what does it take to build a developer product that feels like magic? Charmaine gives us her guiding principles.
1. Put less emphasis on the first-time user experience (FTUE)
What makes or breaks a developer product is what happens after the “aha moment,” or the pivotal moment when a new user realizes the value of your product. Too often, we overload the FTUE with all the complexities of a product in the hopes of sparking an “aha moment” and turning the acquired user into an activated user. We get so caught up on nailing conversions that we forget the real goal, which is empowering them to truly understand and use the product. When we launched the public beta of Lens Studio 5.0, we omitted the FTUE altogether. This forced us to ensure that the product felt intuitive enough to use without a fully guided onboarding process.
Charmaine led a brainstorm to define the goals, signals, and metrics associated with a FTUE. Try it out with this template.
What makes or breaks a developer product is what happens after the ‘aha moment,’ or the pivotal moment when a new user realizes the value of your product.
2. Focus on accelerating your users’ time to magic
What’s crucial is the time it takes for users to ditch the training wheels, so to speak, and learn to ride the bike on their own. It’s about ushering them to the magical moment where they’re not just users—they’ve become creators. They’re proud of what they can build with the tool, and can’t wait to share it with their communities. On our team, we illustrate the user journey on FigJam to see all the elements that prop up or follow an “aha moment,” identifying what sparks delight, what needs improvement, and what’s missing. In the case of Lens Studio, we realized there were about 19 steps from downloading the app to submitting a first project, so we started trimming. We also chose to not invest in actions that user testing showed us were surprisingly intuitive.
3. Meet your users where they are
Developers are surprisingly social creatures, and they love to gather at conferences, meetups, livestreams, and hackathons. I make it a point to immerse myself in these environments: I go to every AR meetup possible, travel for hackathons, check the Lens Studio keyword on X every morning. Doing so helps me speak our developers’ language and get candid, real-time feedback on ideas my team is working on. My superpower as a PM is having the time to build massive context comprising every dialogue that’s ever occurred about our tool, and being able to retrieve insights to inform product decisions.
4. Replace traditional marketing with developer relations (DevRel)
Developers are allergic to traditional marketing. Here’s what they value: an authentic voice that resonates with their own experiences, granular stories about building the product, transparency and a willingness to own up to mistakes, and a balance between accessibility and technical terminology. While designated DevRel teams often shine at companies, DevRel should be everyone’s job. When we’re all responsible for evangelizing our product and advocating for the needs of our users, we build a loyal community. At Snap AR, we encourage team-wide participation in events like Lens Fest, our developer conference, and social platforms like X, where we post project demos, share product hacks, answer questions, and ask for firsthand feedback.
5. Break down work silos to create a seamless user experience
When shipping a product or feature, it’s easy to lose sight of the larger ecosystem. From the core product to documentation and support, every element should feel integrated, so individuals on those teams should be working together to create a consistent experience. In the past, we’ve had problems with losing context around known issues and edge cases, and confusion around routing users to the support team versus the DevRel team. Now, everyone who works on our AR authoring ecosystem—including product, design, engineering, documentation, and support—reports to the same manager. This has worked wonders in terms of ensuring we’re all aligned, but there are other ways to encourage transparency and accountability across the team.
6. Ship fast, and ship often
It may seem counterintuitive, but being less precious about what you ship helps you arrive at a more polished product. We used to have a rigorous process of holding features until they were much more refined, but this delayed getting user input. Shortening our six-week release cycles to two weeks has fundamentally shifted the way we work, allowing for quicker iterations and improvements because we get features into the hands of developers right away. Presenting work in progress How do you make progress when work is always in flux? Chief Product Officer Yuhki Yamashita discusses how to embrace (and enjoy) endless iteration and shares Figma’s approach to developing collaboration features designed with an always-in-progress state of mind.
Welcome to the WIP
Being less precious about what you ship helps you arrive at a more polished product.
7. Empower your users to help each other
To reduce your developers’ reliance on the product development team for support, create spaces on forums, Discord, and X where they can collaborate and help each other. Offer open-source repositories where they can contribute to and customize functionalities to meet their unique needs, and enable plugin development so they can extend the product’s capabilities.
8. Blur the boundaries between design and development
As evident with the rise of design engineers, developers are starting to flex their design skills, and designers are learning to code. Leverage the power of AI and collaborative tools like Figma, which can help bridge the gap between technical and non-technical skills, to encourage areas of overlap on your team and bring more innovative ideas to life. For example, I recently prototyped an ad hoc feature request by duplicating our designer’s Figma file and editing the text, images, and components according to our design system. Our designer, in turn, used Dev Mode to build an AI assistant panel—which leverages documentation, YouTube tutorials, forum posts, and other resources to answer questions about Lens Studio—that worked immediately in production.
9. Do things that don’t scale
Most developer tools have significantly fewer users compared to consumer apps, which means we have the luxury of focusing on first principles instead of solely on scaling up. We can prioritize building strong relationships with our community; instead of just meeting users where they are, we can proactively create spaces for connection through ad hoc meetings, hosting workshops in schools, and providing personal support through Discord. It also allows us to build solid foundations by refining the core functionality, usability, and performance of the tool rather than rushing to add new features.
10. Make space for play—your users will thank you
When the people building a product have fun, it translates into delight for users. Embrace quirky details like ASCII art hidden in code, or shaking the cursor to get a high five. When I worked at Unity, the team scheduled extended reality (XR) hangouts every Friday, treating them as headset field trips for play and exploration. We also used this time to stress-test products and gather candid feedback. In a recent brainstorm, we dropped our most outrageous ideas in a FigJam and voted on our favorites. Building off each other’s ideas on stickies, stamping hearts, and drawing smiley faces created a safe, low-pressure environment to share and collaborate.
It helps to keep the bigger picture and potential impact of the product in mind. Every morning, I wake up excited that I get to work on AR—the ultimate magic that extends the human experience—alongside an energized team. I’m grateful that I get to shape a technology that has the potential to bring me closer to my family, who lives across the globe, to deepen relationships with my closest friends, and to elicit a sense of play and wonder.
