Why Figma Wins

Companies are a sequencing of loops. While it’s possible to stumble into an initial core loop that works, the companies that are successful in the long term are the ones that can repeatedly find the next loop. However, this evolution is poorly understood relative to its existential impact on a company’s trajectory. Figma is a prime example of sequencing loops. They’re now widely viewed as successful, but the key factors in their success and what bets they must make to get to the next level are less widely understood.

The core insight of Figma is that design is larger than just designers. Design is all of the conversations between designers and PMs about what to build. It is the mocks and prototypes and the feedback on them. It is the handoff of specs and assets to engineers and how easy it is for them to implement them. Building for this entire process doesn’t take away the importance of designers—it gives them a seat at the table for the core decisions a company makes.

Building for everyone in the design process and not just designers is also the foundation of Figma’s core loop, which drives their growth and compounding scale. That network effect is made possible by Figma’s key early choices like:

Architecting Figma to be truly browser-first, instead of just having storage be in the cloud
Their head start in new technologies like WebGL and CRDTs that made this browser-first approach possible
Focusing on a product purpose built for those designing vector based digital products

Figma’s compounding growth is not only due to product market fit, but is also driven by the alignment between their product and distribution. There are limits to Figma’s success if it remains only valued and spread within companies. In order to break through that asymptote, Figma must build a global network effect across the ecosystem. Figma’s value to new users should compound as Figma’s adoption grows, even for solo users outside of organizations. Figma has begun making its bets on how it will become a platform—namely centered around communities and plugins. While it’s still early, these bets can be unpacked and understood.

Many companies are now at this inflection point. They have found success with their core product and are trying to push themselves to the next level of value to customers and scale. Our understanding of building platforms and sequencing towards them is still nascent. From how to shift the allocation of resources between a company’s core business and its potential future expansions to how to structure a platform to catalyze its growth and more. Until the playbook is well understood, it is more art than science. There are many decisions to make, including which layers should be centralized, whether the ecosystem should be driven by open source contributors or profit-seeking enterprises, how broad in scope to allow the ecosystem to grow and where to not let it grow, and more.

Whether they can catalyze compounding productivity in design is a core question for the coming years. Engineering is one field that has exhibited significant compounding progress over time. Whether Figma’s bets in building out global network effects will be able to push this level of progress in design will be an important question to watch.

The Arc of Collaboration

When Figma first launched, its value proposition was primarily around making design collaborative. If design could happen in the browser, then designers could work together on the same projects. In fact, they could even work on a design at the same time.

In 2014 as I helped diligence Figma (disclaimer: I worked on Greylock’s investment in Figma, but I don’t have a personal stake in Figma. sadly.), I used to sit with designers at startups and watch them work. The top right corner of their screens were always a nonstop cycle of Dropbox notifications. Because design teams saved all their files in a shared folder like Dropbox, every time a coworker made a revision they would get a notification. And often there were complex naming conventions to make sure that people were using the right versions.

Figma solved this problem. Designs in Figma are not just stored in the cloud; they are edited in the cloud, too. This means that Figma users are always working on the same design. With Dropbox, this isn’t true. The files may be stored in the cloud, but the editing happens locally—imagine the difference between sharing Word files in Dropbox vs. editing in Google Docs.

Any time a user edits a design, they are in effect checking out a temporary copy. This is why two users editing a file simultaneously creates issues. When designs are edited with Figma, there are no conflicts. And since revisions are a first party feature of each design in Figma, there’s no need to have complex files with names like “profile_design_v23_final_draft2”. Similarly, designers can comment directly in each other’s files, instead of sending emails with feedback.

the one with less loops is better. I know, it’s the first time I’ve ever said that

I used to be confused by the Figma’s team consistent framing of Figma as browser-first. What was the distinction between this and cloud-first? Over time I’ve come to see how important this distinction has been. When many creative tools companies talk about the cloud, they seem to view it as an amorphous place that they store files. But the fundamental user experience of creating in their products is done via a standalone app on the desktop. Figma is browser-first, which was made possible (and more importantly performant) by their understanding and usage of new technologies like WebGL, Operational Transforms, and CRDTs.

From a user’s perspective, there are no files and no syncing that needs to be done with others editing a design. The actual *experience* of designing in Figma is native to the internet. Even today, competitors often talk about cloud, but are torn over how *much* of the experience to port over to the internet. Hint: “all of it” is the correct answer that they all eventually will converge on.

Designers loved Figma and this drew initial distribution. And with features like team libraries, designers have incentive to pull in other designers on their team into Figma. But a tool designers love, while a prerequisite for success, does not fully capture the root of Figma’s traction so far. While Figma has been building the ideal tool for designers, they’ve actually built something more important: a way for non-designers to be involved in the design process.

Tools for Design, not just Designers

While Figma was building better tools for designers, their browser-first approach had a much more radical and significant impact on non-designers.

We often forget that the purpose of the tools we use at work isn’t to increase our individual productivity, but the entire team’s productivity. Companies themselves often forget this.

The best tool for individuals may also be the best for the entire team. But it’s the latter that matters. And beyond some level of enhancing individual productivity, it’s the team aspects that increasingly matter. Word processing is a good example of this. There used to be lots of experimentation and customization around individual features like typesetting. But once this was good enough, the focus has shifted towards collaboration. And for most use cases, few care about typesetting today. Increasingly our tools must understand and align with how we collaborate. This was less important when collaboration was logistically difficult and prohibitively costly, but as collaboration becomes easier its importance has risen. People’s work is less siloed—and their tools must reflect this.

The best tools enable collaboration that was previously unthinkable.

Historically it has been very difficult for non-designers to be involved *during* the design process. If PMs, engineers, or even the CEO wanted to be involved, there were many logistical frictions. If they wanted the full designs, the designer would need to send them the current file. They’d then need to not only download it, but also make sure they had the right Adobe product or Sketch installed on their computer—costly tools that were hard to justify for those who didn’t design regularly. And these tools were large, slow, specialized programs that were unwieldy for those not familiar with using them. It was hard to navigate a project without a designer to walk you through it. Comments were done out of band in separate emails. Even worse, if a designer made an update before viewers had finished looking at the file, the file would be out of date—without the viewer being aware.

The experience was just as bad for designers. Even if they wanted their PMs and engineers to give feedback, they’d need to handhold them through the process. Designers would have to export the designs into images, send the screenshot, and later figure out how to translate the feedback into changes in the actual design. The feedback loop was so slow that they’d need to pause their process while waiting for feedback.

Of course, what really happened is that most of the time non-designers just didn’t engage as much with the design process. The pain of reviewing designs wasn’t the primary problem, but there was enough friction that reviewing often never happened.

Figma fixed this.

Sharing designs with Figma is as easy as sending a link. Anyone can open it directly in their browser. It’s as easy as going to a website, because…well…it literally is going to a website.

Once they have the link, non-designers will always have the latest design. They can comment directly in the designs, without disrupting the flow of designers. And with collaborative editing, they can talk through changes in a meeting and watch as they are implemented in real time.

These technical changes are kindling for a far more important social norm shift. Figma makes it possible for non-designers to be part of the process earlier and throughout it all.

Figma made companies realize that non-designers should and could be more involved in the design process and how crazy it is that other design tools aren’t built with the experience of and interactions with non-designers in mind.

Tightening the Feedback Loop

Figma allows closer collaboration between designers and non-designers, but the second order impact of this on the social norms of teams is far more impactful. Historically, there has been so much friction in the design process that design is brought in after most decisions have been made. And conversely, there is a limited set of changes non-designers can push for once the design is set.
Tightening the feedback loop of collaboration allows for non-linear returns on the process. Design can be drafted simultaneously with the product, allowing feedback to flow in both directions throughout the process. Aligning the assets used by design and engineering allow more seamless handoffs, and allows for more lossless and iterative exchange.

Designers can get feedback continuously from engineers or PMs on their team. Some will have sensitivities about non-designers sticking their nose too deep into the design process. In some cases they might be right, but this cost pales in comparison to the benefit to designers.

Bringing non-designers into the process is what gives designers a seat at the table of product and business decisions.

For too long we’ve systematically siloed functional areas like design, sales, and customer service. But modern companies are internalizing that if their core loops are truly an iterative process, then functions like design must themselves be part of the feedback loop of the company. Design decisions cannot be entirely abstracted from the rest of a business—they are as intertwined as the decisions made in product and engineering.

Historically, design has been opaque as a business unit due to the logistical and technical difficulties of making the design process legible to others. But as these hurdles are increasingly solved by companies like Figma, we’re seeing teams navigate how to best integrate design with the rest of a company’s processes. This should be no surprise, as we have seen the same arc play out in engineering over the last few decades.

Means of Ascent

Much of Figma’s current success is driven by its ability to spread within companies. Figma becomes more useful as more people within a company use it, driving advantaged speed and scale of penetration within companies.

Figma was quick to recognize that the constraints on design at companies is often not a problem of pixels, but of people.

Many of Figma’s competitors are great tools for designers. But that’s who they are for—designers.

Figma is a tool for teams to design. Not for designers alone.

now you’re all stuck inside the orange box with me

By bringing both designers and non-designers alike into Figma, they create a cross-side network effect. In a direct network effect, a homogenous group gets more value from a product as more of them join. In contrast, a cross-side network effect involves two (or more) distinct groups that grow in size and value as the other group does, too.

Figma’s cross-side network effect between designers and non-designers is one of the primary and under-appreciated sources of their compounding success over the last few years.

As more designers use Figma, they pull in the non-designers they work with. Similarly, as these non-designers use Figma, they encourage the other designers they work with to use Figma. It’s a virtuous circle and a powerful compounding loop.

Cross-side Network Effects

Cross-side network effects often get less attention than direct network effects—partially because our vocabulary around network effects is less robust than it should be, but primarily because they are typically viewed as being specific to marketplaces. While it’s true that cross-side network effects are most commonly seen in marketplaces, it’s wrong to think that they only exist in marketplaces. Supply and demand is the most famous of cross-side network effects, but not the sole source.

Figma’s direct network effect among designers helped it grow early on, but has limits on its ability to help Figma spread. The set of designers that a designer works with directly is a limited set—and unlikely to change often. While they may spread it via word of mouth and social referral to many other designers, the network effect has an asymptote on distribution.

Figma’s cross-side network effect offers an additional vector. Designers who use Figma share their designs with engineers and PMs, introducing them to Figma. As these non-designers learn to appreciate Figma, they then evangelize it to other teams of designers they work with on different projects. These cross-side network effects jump across teams and help Figma metastasize throughout entire organizations.

more loops is better. Phew, all is right with the world

This impacts monetization and purchasing at companies. Paying for a new design tool because it has new features for designers may not be a top priority. But if product managers, engineers, or even the CEO herself think it matters for the business as a whole—that has much higher priority and pricing leverage.

Product-Distribution Fit

It’s this cross-side network effect that has most shaped Figma’s growth. Like planting seeds, Figma can start small with a scattering of individuals using it at each company—but each of them can lead to serious expansion throughout their companies. Once Figma is adopted by a few designers, all their colleagues across departments get exposed to the product and especially its collaborative features and see how much better the experience is for them. They then encourage its usage and adoption across their other teams and projects and so on.

This is what gives Figma the compounding growth rate it has. While it took Figma some time to ramp up its growth, there is now a predictability and compounding that is impressive.

The core of Figma’s product is the core of its distribution loop. That is incredibly rare and powerful. True alignment between product and core distribution loops is what’s needed to catalyze outlier ability to compound in growth.

Like many of their peers in this generation of companies, Figma has developed a two-step sales motion: landing and expanding via a bottom-up, product-driven approach, then doing top-down sales once usage of the product has metastasized. Preparing for this entails a whole slew of enterprise features, building up the sales machine, and much more. Over the last few years Figma has begun to build these out, though there is still a lot of work for them to do here.

This new type of enterprise companies is a mix of both product and growth-driven consumer and sales-driven enterprise. We are still early when it comes to companies understanding how to re-architect their org structure, GTM motion, pricing model, and more to best fit this model. And like SaaS before it, this bottom-up to top-down model will mature from art to science over the coming years. Though Figma has significant work to do to make their traditional enterprise sales process robust, it would be disappointing if they stopped at simply recreating the traditional enterprise sales process. Practitioners are starting to understand that these sales loops can be understood in the same way growth loops have been and that there are ways to drive significantly advantaged sales velocity and scale via product and ops. Figma is one of the companies on the frontier of this, and there is an entirely different series of essays to be written about the maturation of this nascent field.*

Building an Ecosystem

Where does Figma go next?

There is always more to improve in the core product. But there comes a time when companies need to start thinking about the next sequence of their growth.

The competitive landscape has also matured. Competitors are beginning to copy and encroach on Figma’s core strengths. As they converge on Figma’s views on the space, they pressure Figma to push forward. Sketch, for example, has shifted its pricing model to subscription and oriented around teams and has focused on moving more of the product into Sketch Cloud. In the last year, they’ve gone from being entirely bootstrapped to raising a venture round from Benchmark. This capital and support has fueled a more aggressive move in Figma’s direction with a strong focus on collaboration, especially bringing Sketch to the browser and building team collaboration.

Adobe has made similar moves. Though powerful and widely used, Photoshop and Illustrator were not particularly specialized products for designers of digital products. In 2019, they launched Adobe XD as a direct competitor to Sketch and Figma.

Figma has been focused for the last few years on its value and spread within companies. Figma’s next challenge is to improve its value and spread across companies in the ecosystem at large.

Global Network Effects

There are cross-side network effects that drive compounding value within companies using Figma. But how does it spread to new companies?

Given Figma’s growth rate, it clearly does, but in less consciously compounding ways. Many people work across companies, especially agencies, and spread Figma to their clients. Similarly, when people leave their jobs and join new companies, they bring Figma with them. And of course, word of mouth helps spread it. These are all effective and amplified by Figma’s intrinsic collaborative benefits, but they operate on their own natural cadence.

Thanks to Figma’s hard work, the value in signing up is much higher for someone whose company already uses Figma. There are already teammates to collaborate with. There are assets and design libraries specific to their company. There are components that their team has built that they can reuse.

But for users who don’t have co-workers using Figma, none of this value exists. They have the single-player benefits, but no direct increased value from the hard work Figma has done to add so many new users over the years.

life is just an endless pursuit of trying to draw charts that go up and to the right

Figma’s challenge is to create not just local network effects within companies, but global network effects that make Figma more useful to all users as it grows in scale. There are many directions Figma could expand its scope*, but our focus in this piece will be on the directions they have already begun to take.

say it together now: more loops is better!

In 2019, Figma began to plant the seeds for what their ecosystem loops across companies will be. With their launch of Figma Plugins last August and Communities more recently, they are starting to push the frontier of collaboration and productivity across companies.

this is my best graphic. It’s all down and to the right from here

Empowering Creativity through Communities

Communities push their network orientation further by allowing users and companies to publicly share their designs.

Historically, when sharing designs on sites like Dribbble, it’s often only the output image file that’s shared. It’s hard for others to see and use the full design themselves, including the layers and components that went into it. Even if the actual design is shared, the friction of opening it in whichever program and resolving any dependencies is non-trivial.

Sharing Figma designs removes this friction. Anyone can instantly open a design and start using it for their own projects. This enables users to frictionlessly become creators too, not just consumers.

Some designers have shared their UI kits, components, and design systems using Github. This has the right idea, but Github isn’t meant for design. Forking a repo may be frictionless in engineering—but it is not for designs. The designs must still be downloaded and loaded into your app. For design, Github is more akin to a hosting site for downloading files. In many ways Figma’s Communities are a reflection of Github’s philosophy and intent, but built with design in mind. Duplicate a shared design, and a copy is instantly saved to your workspace and ready to be edited.

This frictionless process makes it easy for people to share and build upon each other’s designs. But perhaps more importantly, including the entire design is a better abstraction layer that allows for new benefits.

Instead of just receiving the final output, recipients can see both the underlying components and assets within a design as well as more complex interactions and animations around designs. A great example is this design shared by Figma’s design director, Noah Levin, of smart animations within Figma. By sharing the entire design with the community, others can not just see the animations—but play with and tweak the actual designs and animations directly. This makes it easier for them to learn how to use smart animations, or even just copy parts of Levin’s demo into their designs.

The Promise of Plugins

I’ve been using Figma to create very niche memes to send friends. Figma is great, but as I’ve gotten more particular I’ve begun to add colored rectangles (with rounded corners because I’m not a barbarian) behind any text to make it more readable. This is a small but annoyingly rote series of tasks to do. Recently, I discovered the plugin Substrate for Text which simplifies this exact process. Now I can just select the text, activate the plugin and this text background gets auto-generated instantly. This plugin is made by a designer, Andreslav Kozlov, who lives in Russia. On the other side of the world, Andreslav had felt the same problem I had, built a plugin to solve it, and shared it with the internet. And that improved the power of Figma for me, making it far easier for me to immediately spin up memes mid-conversation with friends.

though maybe he should also be blamed for the increased speed with which I can troll my friends now

this isn’t how this meme is meant to be used either

This is a small example of the promise of plugins. Figma’s plugins make it extensible so designers can augment their workflows, be empowered with new abilities otherwise impossible, and easily share them with others.

i hope you appreciate the precision of my squiggles in the productivity curve

Most Figma plugins today simplify tasks that would otherwise be very repetitive or painstaking. Today, companies can build private plugins to address their specific needs. For example, companies have built plugins that automatically generate dark mode designs, pull in external data and lint for common design errors, or make it easy to generate design assets in the right orientation. These plugins level up their entire teams.

The real power of plugins, however, is in making them publicly available across the ecosystem. Plugins are collective progress available to all users. Whether creating charts, custom maps, pulling data into your designs, redlining for engineering handoff, or random blobs, plugins leverage up designers’ productivity. And plugins like Figma Chat show that the frontier can be pushed out even further by enabling entirely new abilities for designers.

As companies scale, it becomes harder to sustain consistently increasing value to customers. With more customers, it becomes harder for one company to address all the unique use cases and needs. Companies must also increasingly service less ideal customers as they expand beyond their core audience. This is especially true for users who don’t have all the compounding benefits of working with a team that all use Figma.

your local and global utility curves should look like synchronized divers. That’s what everyone says right?

Plugins help Figma fight this drag. As they scale in users, more plugins will be created, making the product better for new users and spurring more designs to be created.

Architecting a Platform

Companies like Sketch have shown the importance of a robust plugin ecosystem (and of course, Adobe before them has a long track record of encouraging plugins). It’s impossible for a single company to build all the features and tools needed by each user. Platforms are needed most when the diversity and scale of use cases is larger than can be built—or often even understood—by the company. Sketch’s plugins allow the value to Sketch customers to grow at a faster pace than Sketch can ship new features. Figma will also likely stay focused on a generalized and core set of features, leaving a huge surface area of user workflows for plugins to address.

this graphic will probably get its own essay

Companies are still early on in understanding the nuances of becoming platforms. More and more companies are reaching the scale and dynamic range where this is a priority, but for the most part, they are individually recreating the wheel. In a decade, there will be clear frameworks, metrics, and supporting ecosystems for building platforms; today there are few. This is a natural maturation, and one that all business models go through, such as SaaS and subscription over the last decade.

Because of our lack of shared vocabulary around building platforms, it’s hard for many to understand the subtle but important delineations between the approaches of different companies. It’s easy to assume, for example, that all plugin systems are built the same, but this impulse is often incorrect.

Sketch: a Case Study

Take Sketch’s plugin ecosystem. The API is well documented and the plugin coverage is high. However, plugins are outside the scope of the core product. Users installing a plugin are most commonly directed to the Github page of the plugin, which they must manually download and install. This is another example of the gradients of what it means to put your product in the cloud. Even if Sketch is in the cloud, its plugins are local files. There is friction in downloading and installing them. This is compounded in a work setting as teams must manually make sure employees are using the same plugins if needed.

Because plugins are not first-class citizens in the Sketch product and handled out of its scope, plugin management is very decentralized. Plugins can register to be listed on Sketch’s site and enable automatic updates, but otherwise Sketch is very hands-off. There is no official Sketch source for how popular a plugin is, nor do they have to approve plugins. Instead, users must rely on Github stars or reviews on third party sites. There is no oversight on plugins causing performance or stability issues.

This shouldn’t be mistaken for criticism. The weaknesses in Sketch’s plugin architecture show only because of how successful they have been at encouraging a robust community of plugins around Sketch.

Platforms are emergent ecosystems, more akin to building a consumer social network than a traditional enterprise sales company. This is one of the core dilemmas of building platforms. They are complex organic systems that have to be carefully cultivated (gardening vs. engineering mindset) and it’s hard to predict beforehand what direction they will go and the scale they will achieve.

Sketch cannot be faulted. To this day it’s still unclear how ambitious plugins can and should be. By defaulting to a relative hands-off approach, they allowed the community to flourish unhindered by them. And it’s by seeing Sketch’s success with plugins, as well as their struggles, that others like Figma and Adobe XD have been able to have increased confidence in the importance, potential, and levers of a plugin ecosystem.

But while Sketch cannot be faulted, their choices have stunted the full potential of plugins built around them. Sketch understands this. They are rearchitecting their plugin system right now to be fully in the cloud, which is a necessary step in the right direction.

Complex systems do not absolve companies of their need to make clear choices about the architecture, policy, and norms of their platforms. If anything, they magnify its importance. The structural choices made by companies ripple forward as the ecosystem emerges around them. And the direction and scale of the resulting platform are a function of the physics set by their initial conditions. We shape our abstractions, and thereafter they shape us.

Figma: Forming Foundations

Figma’s plugins are very early, but promising. Natively built in and browser-first, when you click to install a plugin, it’s available instantly. There’s nothing to install after all, just access privileges to activate. That’s magical.

Like all good magic, the work to make this feel effortless is quite arduous. Figma’s plugins must be secure, performant, and stable, especially since they are creating a plugin ecosystem for a browser-first system. Users should be able to trust that using plugins won’t expose them to security risk or hurt Figma’s performance. And both developers and users should feel confident that the APIs the plugins depend on won’t be suddenly deprecated or broken. Without these preconditions, plugins will always be at best a small aspect of Figma. This trust and stability is the bedrock of a strong ecosystem.

i think the takeaway is that plugins are like rainbow cake?

This difficulty is best seen in Figma’s engineering blog posts on building their plugin system. Within a month of their post on how they decided the architecture for plugins, they learned of vulnerabilities in their approach and had to switch it out.

Ensuring the platform can be trusted is not just a matter of technical architecture. Figma doesn’t just host plugins, they also have a centralized approval process, more similar to Apple’s app store than to Sketch’s approach. Plugins that want to be listed must pass Figma’s policies around safety, business, usability, and legal.

The Path to Platforms

The business policies are worth noting in particular. While safety, usability, and legal are about maintaining the integrity and trust of the platform, Figma’s business policies are about shaping what they think the plugin ecosystem should look like. For example, they allow monetization but prefer plugins be accessible to all users. Choices like how much to encourage an ecosystem of plugin businesses vs. a more open source community are important ones. There is no obviously correct answer, and it can and often needs to change over the life of a platform. One need only look at the makeup of Uber drivers, WordPress plugins, or Airbnb hosts over time to see this.

Building platforms requires many hard choices like these. How should you balance encouraging growth today and building towards the ideal long term vision? To what degree should platforms influence which plugins get built or even which they should build themselves in the early days? How should you decide which features actually should be part of the platform itself vs. standalone plugins? How wide is the scope for what plugins can build? These are only a few of the core questions.

Perhaps Figma’s most interesting choice is the heavy focus on ease of plugin creation. Figma’s plugin system is explicitly designed to turn designers into developers by enabling them to create plugins for their own workflows. In most platforms and marketplaces, the ecosystem tends to split and professionalize over time. This is the natural gravitational pull of ecosystems*. To bet that a significant amount of the platform’s leverage will come from individuals improving their own workflows is a bold one. It’s a bet on induced demand, which is always the most interesting type of bet.

Figma’s plugin ecosystem is very nascent. From their list of supported features and what’s to come, it’s clear that there is still a long way to go to open up their platform to more advanced plugins. And choosing the right abstraction layers for the plugin ecosystem is crucial. So far they have adopted a very strong stance on what the core technical decisions and promises around safety, performance, and stability need to be, but have been very hands-off on what plugins are built. This is to be expected early on. When it’s unclear what should be built, it’s not a bad policy to see where the creativity of the community leads. It often brings really amazing stuff, like this demo of a plugin. Over time, however, we should expect to see more focus. Right now their plugin page is unsorted other than popularity and some that are featured. This works when the number of plugins is low enough, but eventually they will have to decide how to categorize plugins and what they want discovery to look like.

As plugin categories begin to crystallize, Figma will need to form crisp views on which areas should be absorbed into their core product, what they want each category to look like as it matures, what essential plugins don’t yet exist that they must help catalyze, and what new APIs they should allow plugins to address. The choice of how much to encourage monetization of the plugin ecosystem, as discussed above, is a perfect example of the kind of key decisions Figma will need to make (repeatedly) as they build out their plugin platform. Perhaps most importantly, Figma must decide the meta-framework by which to make these decisions intentionally rather than capriciously.

Pushing Progress

Has design been improving? Are we getting better at designing, not as an art, but as a functional practice?

The answer is certainly yes. We have tools that would have been unfathomable a decade ago, much less pre-computer. It is easier to design. It is easier to begin designing. Design is more scalable.

But how does design’s rate of improvement compare to the rate at which engineering has been improving as a process? Design as a meta-process is less impressive by this benchmark.

Engineering is almost unparalleled in the rate at which it commoditizes itself and pushes the frontier of progress out. The best practices in frameworks, languages, and infrastructure are always rapidly—and sometimes tumultuously—evolving. What used to take entire teams to build before, requires fewer and fewer people every year.

this is the true up and to the right curve. and the one that needs to be figured out for every discipline

As disciplines evolve, they figure out the social norms needed to operate better, build tools that can be shared across the industry, and invent abstractions that allow offloading more and more of the workload. They learn how to collaborate better, not just with each other but with all the other functions as well. Disciplines are not an end to themselves; the degree to which they contribute to the larger organizations and ecosystems they are part of is the final measure of their progress.

Design appears to be inflecting in the direction of engineering. Figma is in pole position to drive this evolution. As a tool, it makes designers both more efficient and more collaborative by breaking down the walls between design and the other teams they work with.

But Figma’s true potential is if it can make the transition to becoming a platform. If Figma can, they’ll push progress in design as a discipline.

Which companies are successful in a field is decided by many factors, not the least of which is a good measure of luck. But when disciplines undergo tectonic shifts, the companies that thrive have outsized influence. The choices they make in abstraction layers, social norms, architecture, and more have large ripples for a generation. This is even more true for platforms, whose loops become core to their ecosystems. Like wet clay, the choices they make eventually set and become the underlying substrate that defines how the entire ecosystem grows. That is both a tremendous opportunity and responsibility for the companies, like Figma, that take on this mantle.

Acknowledgements

Many thanks to Keila Fong, for the many discussions about this topic and help with this piece. As well as unceasing pressure to publish it.

Additionally, thanks to Max Bulger, Michael Dempsey, Kane Hsieh, Boris Jabes, Dave Petersen, Ryan Petersen, Kevin Simler, and Eugene Wei for their discussions, edits, and help with this piece. John Lilly, who led Greylock’s investment in Figma, deserves most of the credit for seeding all my views on productivity and collaboration. His investment memo from 2014 is still prescient in ways that took me years to fully appreciate.

Thanks also to Casey Winters and Brian Balfour. Building the Advanced Growth Strategy course was the origin of many conversations about Figma’s loops. And I still teach the Figma case study every semester.

All graphics in this piece were created with Procreate and Figma. Procreate is a fantastic drawing app for iPad. If you have made it all the way through this essay and don’t know what Figma is then I don’t know what to tell you. An integration between these two might have a target audience of only me. But I would love it.

* Further pieces to be written on these subjects

Notes on Superhuman’s Acquisition Loops

Recently sent some notes on aspects of Superhuman’s acquisition loops and business model that interested me to some friends. Since I often ask people to write and send me more memos, thought I’d clean up and share this example.

This essay is heavily focused on growth loops, and assumes familiarity with them. If you are not familiar with them recommend reading “Growth Loops are the New Funnels” on the Reforge blog.

Companies in the productivity and collaboration space have been raising at high revenue multiples. Examples include Superhuman, Figma, Airtable, Notion, Slack, Zoom, and others. While valuation multiples don’t necessarily mean these companies will be successful–it is a sign of both excitement about their characteristics as well as the demand pull seen by the companies.

And these companies have overall had impressive traction that looks to compound. There is a longer post to write about them, but that’s not the focus of this essay.

Superhuman is an outlier among these, in that its users do not require or benefit from others also being Superhuman customers. Email clients are interoperable with any other email clients.

A large component of what’s driven the belief in these other companies is the belief that they will compound due to the network effects of collaboration. These companies have a mix of inter and intra-company network effects that will drive increasingly cheap and compounding acquisition as they scale. Users can only use the product together if others also use it. This makes starting the flywheel and hitting minimum viable scope of the network effect hard, but it makes it more scalable and defensible once it’s established.

Superhuman is not like this. It does not have network effects. Users can email with others regardless of what email client they use. However, its distribution *is* still spread by users vs by the company doing enterprise sales. It’s not personal utility that drives new adoption, but word of mouth. Social capital–not personal utility–is what drives Superhuman’s acquisition loop. Users don’t share Superhuman because they need others to use it for it to work; they share it because they want to. This change has many downstream impacts on Superhuman.

Business in the back. Party in the front.

Overview of Superhuman acquisition loop

Superhuman’s CEO has a great essay on finding product market fit in the First Round Review. It’s about focusing on what percentage of your users would be very disappointed to no longer be able to use your product as a core metric.

But part of what makes the path work so well for Superhuman is that the company is structured around a very unique loop.

Most users find Superhuman via word of mouth, social referral, or from it being shared and discussed on platforms like Twitter. They come in to the sales process already primed to want to join–instead of requiring a lengthy sales process. After a pre-qualification process, they’re onboarded to Superhuman.

They pay for Superhuman and use it. But perhaps most importantly, they invite their friends and talk about it on Twitter, thus closing the loop and continuing the cycle.

A simplified example of Superhuman’s acquisition loop is shown below. There are many additions that can and should be added to this, and in later sections we’ll dive into some of them. But this is the essence of Superhuman’s acquisition loop.

Superhuman doesn’t have the traditional sales process of an enterprise company, but many productivity startups with bottoms up adoption don’t. More atypical, is that Superhuman’s acquisition loop is that of a consumer social product.

As long as Superhuman can sustain these channels, it has no marketing expenses and instead of traditional sales can hire people focused on the onboarding and customer service experience. Letting the product and community drive customer education and sales lead to much better unit economics. More importantly, it shifts the center of gravity of the company.

When acquisition is mainly via referral or social, growth is driven by users who are delighted and proselytize the product. All companies want to delight the users who would be most disappointed to lose the product, but this often comes at tradeoffs with other priorities. Superhuman is very good at focusing on delighting its most fervent users, because these users drive new user acquisition for the product.

Social Capital Driven Acquisition: Aligning small details with big picture

Social referral

Social referral is not an unusual channel for a productivity app. The perceived status of being accepted as an early user of Superhuman has helped Superhuman’s acquisition and conversion, though it’s unclear how long that will persist as it scales its number of customers.

Referring a friend to Superhuman or posting about it on Twitter has real friction. There is logistical friction that Superhuman has focused on minimizing. There’s no separate flow for referrals. Instead it’s as easy as introing your friend via email. And for added simplicity there’s a CMD-K shortcut for it. Similarly, when emailing a friend, the sidebar will have a refer button if they aren’t a Superhuman user. Building the referral mechanism seamlessly into the app increases their referral rate, which is core to their growth.

But logistics aside, there is a very real cognitive friction to social referral. It’s not top of mind or high priority for most people. Social capital driven sharing doesn’t *need* to happen, so it’s often the hardest to predict and increase.

If logistical friction is why most potential proselytizers give up on referring friends, delightful moments are what reminds them how much they want to share your company.

Delight Driven Development

Delightful moments are what increase the rate at which users remember and want to share Superhuman. Delightful moments are those moments where reality exceeds your expectations.

Superhuman has many small details that delight users. CMD-Shift-I automatically constructs intros. For most actions that could have been done with a keyboard shortcut, Superhuman will show you the shortcut for next time. Their copy function will make footnotes of links if you paste to plain text. Of course, there are also bigger ones as well like their onboarding flow (discussed below). For most companies, it’d be nice but of indeterminate value to prioritize these small details; for Superhuman they are crucial for driving acquisition.

Brand as Social Capital

Social capital acquisition loops are not just about getting users to invite others more often. They are also about getting those invited to want to join.

The importance of invitees wanting to join is obvious at a surface level, the conversion rate is a function of how many are interested. But even among those who sign up, their level of enthusiasm matters. The cost of onboarding, the level of churn, and even their level of engagement will be a function of how excited users are to use Superhuman.

The social capital that Superhuman has with a potential user is incredibly important in a social capital driven loop. Your friend inviting you matters, but just as important is how primed you are to want to use Superhuman when you’re invited. If you’ve heard many good things about it, it feels like many friends of yours use and enjoy it, and you admire Rahul and the team’s product sensibilities, then you are more likely to be a good customer, both in using Superhuman as the team intended it to be used and in willingness to pay $30/month for it.

This is why it’s important for Superhuman to be consistently discussed, and in social capital positive ways. This aligns Superhuman with opening up more about their internal processes, whether how they built their dark theme or celebrating the importance of onboardings and those who do them. It’s also why I’m bemused about the debates around whether or not Rahul should have a small venture fund. My personal views aside (and to be clear I’m strongly pro-experimentation in the form of venture and especially in founder led venture) anything that builds Rahul’s social capital is *definitely* in the interest of Superhuman’s acquisition loop.

Onboarding

Superhuman’s onboarding flow is also notable.

Superhuman has an aggressive onboarding flow compared to other productivity tools. Everyone who joins is onboarded by someone on their team. This can range from a video call to an in person meeting with the CEO. While common for enterprise sales, it’s rare for consumer apps. The frontier of the hybridization of enterprise and consumer continues to expand. Or more precisely, companies increasingly realize it’s not a stark divide, but a gradient. Superhuman’s onboarding flow drives increased new organic distribution, decreased churn, and a tighter feedback loop.

Superhuman’s high touch onboarding may not be right for every company. However, there are likely effective variants that can be implemented cheaply enough and targeted at the right customer segments to be very ROI positive. Even without human driven approaches, there are product-supported white glove experiences without the expected costs that are likely to work.

Here are some notes on some of the advantages:

General productivity tips. They manually observe your workflow and give general productivity pointers (even if not in the Superhuman app). This is useful and establishes credibility with customers.

KK note: That some of you were functional humans without knowing about command-tab is mind blowing to me. I’m barely a functional human*with* command tab letting me instantly and repeatedly switch between all my appli—oh no

Setting up and tailoring Superhuman. They have you go through setting up Superhuman with them on hand. Many companies actually have pretty significant churn between potential customers signaling they’re interested–and actually ever getting set up. By having onboarding in person, Superhuman removes this churn.

Managing the set up also lets them customize the setup to what they think would be ideal for you. For example, looking at your inbox they may suggest certain split inboxes that’d be ideal and set that up on the spot–vs hoping you discover it on your own. The more they help ease you into a new workflow, the less chance you churn.

Strongly prescriptive on workflow. Most apps are happy for customers to use them however they please. In contrast, the Superhuman team has strongly prescriptive views on what your workflow should be. In their early days, they wouldn’t even allow users who didn’t subscribe to the same email ideology. There are questions about how well this scales and its efficacy in getting new more mainstream customers to adopt the workflows. But the benefit is that it helps shift users towards ways of using Superhuman that are more likely to be successful.

The Instant Inbox Zero. They’ll push you to get to inbox zero in the onboarding session. If you don’t have many emails they’ll sit there as you clear them out. If you have many they’ll offer to nuke your inbox and put them all into email bankruptcy. Starting at inbox zero makes adherence to their view of inbox management more likely. And feeling like you left session and cleared out entire inbox is a magical moment for new users.

KK note: I’ve never felt so motivated to process my email efficiently, then with the CEO of Superhuman sitting beside me patiently burning what could have been productive time. And I’m sure immensely judging my email workflow.

Tight Feedback Loops. Having every customer manually onboarded creates a very tight feedback loop on how people use email, what resonates about Superhuman, and where in onboarding or using the product users struggle. This continuous user research allows the team to quickly improve the product, and just as importantly–rapidly refine how they pitch Superhuman’s value proposition.

Segmented Onboarding. Most companies have the same onboarding flow for all their customers. This is often because they think there is little variance in the value of each customer, and even if there was they wouldn’t know ahead of time. Because they benefit from social referral, WOM, and discussion on social platforms like Twitter, there can be people who can drive significantly outlier new user distribution. Similarly, customers who can convert their entire company or may be future investors also drive more value. Superhuman can decide who onboards a new customer based off of their view of the non-immediately financial return on retaining them.

Human Connection. Every onboarding at Superhuman is done by someone on their team. As importantly, because new users are already high intent, it feels far less transactional and sales oriented. And more aligned and focused on setting up and learning the product. Knowing someone at the company I suspect lowers churn. When the CEO onboards you personally, it becomes harder and more personal to unsubscribe.

I also think that associating a human face with the product (and one that isn’t trying to get you to buy more) also changes the dynamic. It makes the product feel more personal. Beyond churn, I think this translates into things like how you feel when emailing them with feedback or complaints, makes you more likely to read their emails, etc.

Baseline Onboarding. All the early onboardings were done by Rahul, the CEO. I highly recommend this, even beyond the benefits of the tight feedback loop. Nobody is going to be able to pitch the product better than the CEO. Not only does he intimately understand the entire product. It’s frankly just more effective when the CEO is walking you through the product. You’re less likely to churn, etc. This alone wouldn’t be that useful because the CEO’s time is the most valuable and not scalable.

However, by having early onboardings done by Rahul, it sets a baseline. As the company progressively scales out its onboarding flow, they have a baseline of what the highest touch, least scalable process looks like to compare against. This makes it easier to figure out when a new lower-touch onboarding process is giving up too much efficacy in return for scale.

Delight Driven Distribution. If Superhuman’s distribution is driven by outlier moments, there’s no better time to drive that then the onboarding process. I’d guess most tweets about Superhuman come from people who’ve just gone through their onboarding.

Good Friction

Superhuman’s onboarding process introduces significant friction. I know multiple people who’ve avoided signing up for Superhuman because they don’t want to go through onerous process. It’s odd in today’s world of self-service to see a product that doesn’t allow it.

For this stage of Superhuman’s growth, this self-qualification of leads is probably net positive. This process is more Good Friction than bad. Good friction looks like it hurts its step of the loop, but it net improves the entire loop. For Superhuman the onboarding process does likely ding the number of people willing to sign up. But as long as they are not demand constrained yet, this is a positive–it helps pre-filter for customers who are more committed.

And there are other significant benefits. As discussed above, the onboarding process improves retention, helps educate customers on how to use the product, and improves referrals. Of course, this would change if and when they do become demand constrained.

Feedback loops

Many companies no longer talk to their customers. It sounds crazy, but it’s true. Enterprise companies have to because talking to their customers *is* their sales motion. But for consumer companies and non-enterprise ones typically very few people have actually talked to a customer. There’s real value in this. And despite everyone nodding along it’s *underweighted*.

A company is just a process that hopefully compounds as it scales and improves in its ability to serve its customers. Closing and making faster feedback loops are how it compounds.

As discussed above, Superhuman’s onboarding flow shortens the feedback loop. They can see immediately hear what makes sense to people and what is confusing. It allows them to immediately test out new changes and ways of framing the product. And as our industry shifts increasing focus to retention, customer service moves from being a support function to a key retention lever.

Superhuman also does this by decreasing the friction (and response time) of feedback when using the app. Besides a top level button for feedback, there’s easy CMD-K shortcut for giving feedback.

It’s no surprise that the two top level commands bundled together are for 1. Giving feedback and 2. Referring new users. These are their core loops: strengthening the product and increasing its reach.

Do Social Loops Scale?

Superhuman’s social capital acquisition loop, onboarding flow, and feedback loops have been great for the company’s growth. Can these same loops scale with Superhuman, or are they strong initial loops that will have to be transitioned out as the company matures.

Manual user onboarding and talking to all customers typically *is* done by companies below a certain size, before being dropped as they become prohibitively costly with scale. Superhuman has been able to keep doing these even as they’ve grown. The real test for Superhuman is how effectively they can maintain it while scaling.

Historically, few onboarding process this high-touch and driven by social capital have scaled. There is typically a tradeoff between scalability and quality. Quality typically gets worse with scale. Some of the best companies are able to minimize this decline even as they scale out. Or in even rarer cases, build compounding loops that actually improve with scale.

Superhuman has already taken steps to make their onboarding more scalable. They know can onboard most customers remotely. Whereas they previously did every onboarding in person, and before that Rahul did most onboardings.

It’s likely that Superhuman will add self-service as they scale further. And sequencing their loops is typically how most companies mature. Or as Eugene Wei would call it moving past their invisible asymptote. However, if their LTV is strong enough, it’s also possible their current approach *is* scalable, which would be even more interesting.

Sequencing Loops

Social capital acquisition loops traditionally don’t scale. The social dynamics they rely on tend to change with scale and they become weaker. Personal capital driven loops, like network effects, typically scale far more effectively.

It’s easy to get someone to use Superhuman, because they can use it even if everyone they talk to uses another email app. But this very same reason that helps Superhuman in its early days hurts it at scale, because there is no need for collaborators to eventually switch on to Superhuman. By contrast, an app like Zoom, Slack, or Figma struggles in its early days, but actually becomes more and more compelling to use as they get liquidity. When everyone you work with uses Zoom, you *have* to use Zoom to video chat with them.

Social capital has historically been fast to rise but cap out sooner

These kinds of network effects have a high minimum scope, and *very* high maximum scope. Take Slack as an example. It is hard to get people to use Slack when no one is on Slack, but very easy when their entire company uses it. When no one uses Slack at an office, it’s hard to convince the first few to join. Why add *another* app that nobody is even using. Slack isn’t useful until at least my team is on it, it has a high bar before its network effects start kicking in. In fact, compared to alternatives it almost has a negative network effect below a certain amount of active users at a company. After all, why send a slack message to a coworker who doesn’t even use it, when they’ll definitely see an email sent. However, Slack also benefits from a high maximum scope. As more people at the company use slack it becomes increasingly essential for everyone else to use Slack. If all the discussions are happening on Slack and you’re the only person not using it, you’ll be missing out. And there’s no way to be part of that conversation without using the app.

KK Note: Astute observers will note that this is a high maximum scope *within* companies. But that may not naturally spread across companies. Some classify this as local vs global network effects, which is a specific framing of the general elasticity of sequencing loops. And a topic that deserves its own post.

Superhuman’s current product lacks these kinds of network effects, making them distinct from many of their peer companies, and possibly without a scaling compounding loop currently.

Sequencing from social capital loops to network effects is #goals

The normal path is to sequence to a better loop. In Superhuman’s case there are many options. It’s likely we’ll see them release collaborative tools for teams using Superhuman or features like shared editing or enterprise management of inboxes. These features would add intra-company network effects. There are also many features that should be uniquely possible when both parties are using Superhuman.

Scaling Things that don’t Scale

But the really intriguing possibility is that Superhuman believes they can scale their existing loops.

While still small in scale, Superhuman has managed to grow while keeping a remarkably high touch onboarding and feedback loops even as they grow.

Without internal data, we don’t know if these are unit economic positive (and their high touch approach is worth doing currently from a product feedback perspective even if they aren’t). But if they *are* profitable, then they are a datapoint that the frontier of high-touch, economic, and scalable can be pushed out further than anticipated. And perhaps they plan to scale a primarily social capital loop.

Presumably Superhuman’s social capital loops and delight driven development have led to high virality, lower churn, and low cost of acquisition. If this persists, it’s very possible this system is stable.

Will it be able to persist? One large factor is top of funnel demand. Currently they are not demand-constrained. Already having too many people who want the product is what allows all of their novel loops to be possible.

Their waitlist has ~200k people on it. Of course, this is not quite right metric since there is high variability in price elasticity among that list. But this is also the point. Currently they have no shortage of potential customers who are willing to pay full freight. This is part of what allows their unit economics to be very strong: they don’t need to pay for customer acquisition, or traditional inside sales reps. If this can’t be maintained then they will need to start building a traditional sales org which will change their economics. But if social referral and WOM can be a growing and stable source of new customers than that would be opening up new approaches for many companies in the future.

Appendix

Appendix A: Extrapolating from the acquisition loop

With this understanding of Superhuman’s acquisition loop, we can look at specific theoretical or real examples to see how it shapes Superhuman’s decisions.

Free

Since customer referrals and word of mouth are Superhuman’s main acquisition channel, Superhuman’s users are the core driver of their new acquisition. So a user is both a customer that pays Superhuman in money, and potentially a distribution channel to new customers.

While customers may pay the same amount, they are not of equal value as distribution. Some categories of customers, like founders or high profile users, are likely larger drivers of new customer referral or increasing brand awareness for Superhuman than others.

Let’s say one of these customers churns due to price. This disproportionately hurts the acquisition loop–since it’s driven by user distributed channels.

I suspect there are categories of users, especially founders, who if they churn Superhuman will offer the product to them for free. Perhaps Superhuman already does this.

Freemium is a far more complex tool with more levers than is appreciated in tech. It’s not a boolean distinction but rather a gradient that we’ll get better at understanding as an industry.

This goes to our recurring conversations about how freemium isn’t a boolean distinction, but a gradient we’ll get better at understanding as an industry.

The deciding factor for freemium should be where the company gets more value from a user than the financial capital of their payment.

Harming the Loop / Social Regulation

Recently Superhuman became embroiled in twitter controversy after Mike Davidson wrote an essay about its pixel tracking. Writing on the debate itself and my view is out of scope for this piece and would need to be its own essay (which I’m unlikely to write). But I want to talk about why it mattered.

If you look at Superhuman’s acquisition loop, Twitter is a real channel for them. And social referrals and WOM are the other big ones. Just as Superhuman being viewed as a cool and enviable product lowers the friction to it being shared and the likelihood of a potential customer signing up. Superhuman being viewed as a creepy or malicious app increases the friction to it being shared. This is even worse on platforms like Twitter where anyone sharing Superhuman may have these accusations posted in reply to their tweet. If it continued unresolved, many would likely not even share on twitter because of wanting to avoid the pushback.

What is your strength is always your weakness too. With twitter as a main channel, these kinds of posts become existential. Which is why they have to be taken very seriously. Which is what we saw.

When companies sell directly to people they become very sensitive to the will of the people. Superhuman *has* to take these claims seriously, because it *can* hurt them if users don’t view them as protecting their privacy. This is how things should work.

Credits

Many thanks to Keila Fong, Dave Petersen, Max Bulger, Boris Jabes, Ryan Petersen, Michael Dempsey, Allen Yang, and Kane Hsieh for the many discussions on Superhuman and their unceasing pressure to publish this. And to Eugene Wei for our many discussions on social capital and how to best understand and model it.

Finally, much thanks to Casey Winters who has spent far too many hours in a room with me formalizing our views on loops and how to model them as we built Reforge’s Advanced Growth Strategy course. Perhaps one day we’ll have written an essay on every variant of loop, not just [social capital, user generated, user distributed].