We Don’t Sell Group Chats Here

The memo below is a near-identical rip of Stewart Butterfield’s iconic memo in homage of Slack’s recent successful public listing, but with the Slack narrative replaced with the narrative of our own early-stage company, Abridged. We’re currently in a very similar situation to where Slack was all those years ago before its viral success, and forking Stewart’s memo was a helpful exercise for us to articulate exactly what we are selling so that we too might have the opportunity to make as big of a transformational impact for the Web 3 industry.

TLDR about Abridged: SDK that enables ANY developer to incorporate Web 3 components (i.e. user onboarding, scalability, crypto on-ramps, etc) into their app in minutes with just a few lines of code.

Build Something People Want

We know that we have built something which is genuinely useful: almost any team which adopts Abridged as their go-to tool for Ethereum app development would be significantly better off than they were before. That means we have something people want.

However, almost all of them have no idea that they want Abridged. How could they? They’ve never heard of it. And only a vanishingly small number will have imagined it on their own. They think they want something different (if they think they want anything at all). They definitely are not looking for Abridged. (But then no-one was looking for Post-it notes or Slack either.)

Just as much our job is to build something genuinely useful, something which really does make people’s development lives simpler, more pleasant and more productive, our job is also to understand what people think they want and then translate the value of Abridged into their terms.

A good part of that is “just marketing”, but even the best slogans, ads, landing pages, PR campaigns, etc. will fall down if they are not supported by the experience people have when they hit our site, when they sign up for an account, when they first begin using the product and when they start using it day in, day out.

Therefore, “understanding what people think they want and then translating the value of Abridged into their terms” is something we all work on. It is the sum of the exercise of all our crafts. We do it with documentation accompanying our SDK, with fast responses to support tickets, with good Medium posts explaining our product in simple sentences, with comprehensive and robust integrations, with purposeful method names, and with thoughtfully implemented and well-functioning features of all kinds.

“Marketing from Both Ends”

Much has been written about “product-market fit” in the last few years, probably as a result of the popularity of the lean startup movement (though the idea has been around much longer). The term refers to the degree to which a product could be successful, given sufficient promotion, appropriate pricing, adequate customer support and so on (before you find that fit, all the pushing in the world won’t get you up the hill).

In the classic post on Marc Andreessen’s old blog, he calls getting to product-market fit the “only thing that matters” for startups and offers a way of thinking about the life of the startup that divides it into two distinct phases: before product-market fit and after. Once the product fits the market, a company is able to step on the gas, spending to promote a product that will actually sell. The things you need to do before are very different from the things you need to do after (generally test & iterate vs scale & optimize).

We are right in the middle of that first phase. It seems we are doing well and there are many encouraging signs, but we’re definitely still in the first phase and it is very, very hard to tell how far we have to go to cross over into the promised land (the last 10% is 90% of the work, etc.) So, we should be working carefully from both the product end and the market end:

• Doing a better job of providing what people want (whether they know it or not)
• Communicating the above more and more effectively (so that they know they want it)

In the best case, there is a dialectic at play here: the product itself and the way people use it should suggest new ways of articulating the value — and refinements to how we communicate the value should lead to principles which clarify decision-making around product features and design.

Our position is different than the one many new companies find themselves in: we are not battling it out in a large, well-defined market with clear incumbents (which is why we can’t get away with “Other developer tooling products are poisonous. Abridged is toasted.”). Despite the fact that there are a handful of direct competitors and a muddled history of superficially similar tools, we are setting out to define a new market. And that means that we can’t limit ourselves to tweaking the product; we need to tweak the market too.

Sell the Innovation, Not the Product

The best — maybe the only? — real, direct measure of “innovation” is change in human behavior. In fact, it is useful to take this way of thinking as definitional: innovation is the sum of change across the whole system, not a thing which causes a change in how people behave. No small innovation ever caused a large shift in how people spend their time and now large one has ever failed to do so.

By that measure, Abridged is a real and large innovation. It is not as eye-catching as self-driving cars or implantable chips — it is not basic research-y kind of stuff. But, for organizations that adopt it, there will be a dramatic shift in how time is spent, how development happens, and how the team’s resources are utilized. There will be changes in how team members creatively think through their product’s UX, and hopefully, significant changes in its usage and traction.

We are unlikely to be able to sell “account contracts and state channels” very well: there are just not enough people shopping for account contracts and state channels (and, as pointed out elsewhere, Metamask works fine).

That’s why what we’re selling is the ability for teams to impress on their customers their own unique transformational innovation.

What we are selling is not the software product — the set of all the features, in their specific implementations — because there are just not many buyers for this software product. (People buy “software” to address a need they already know they have or perform some specific task they need to perform, whether that is tracking sales contacts or editing video.)

However, if we are selling “a reduction in the cost of development” or “zero effort integration management” or “making better product experiences, faster” or “all your Ethereum app components, instantly analyzable, available wherever you go” or “75% faster product development cycles” or some other valuable result of adopting Abridged, we will find many more buyers.

That’s why what we’re selling is the ability for teams to impress on their customers their own unique transformational innovation. The software just happens to be the part we’re able to build & ship (and the means for us to get our cut).

We’re selling a reduction in development overhead, relief from UX constraints, and a new ability to build an Ethereum app that can get real fucking usage. We’re selling better revenue generating businesses, better product experiences. That’s a good thing for people to buy and it is a much better thing for us to sell in the long run. We will be successful to the extent that we create better product experiences.

To see why, consider the venerable Slack, Inc. They could just sell group chats, and if so, they’d probably be selling on the basis of things like the variety of emojis they have or their playful logo design; they could be selling on the infinite number of channels that could be created, or on their native mobile app, or on price.

Or, they could sell organizational transformation. Being successful at selling organizational transformation means they grow the market for their product while giving the perfect context for talking about their group chat app. It lets them position themselves as the leader and affords them different kinds of marketing and promotion opportunities (e.g., sponsoring workshops on agile decision making for executives, working on standards for corporate archive management). It lets them think big and potentially be big.

Because the best possible way to find product-market fit is to define your own market.

This isn’t a new idea. There are many brands whose marketing activities or positioning has them selling something other than (and usually larger than) their product: Harley Davidson sells motorcycle riding, but it especially sells freedom and independence. Most luxury brands sell something that comes down to “being better than you are” (richer, better looking, more attractive to those you find desirable, etc.)

My favorite recent example is Lululemon: when they started, there was not a large market for yoga-specific athletic wear and accessories. They sold yoga like crazy: helping people find yoga studios near their homes, hosting free classes, sponsorships and scholarships, local ambassadors and training, etc. And as a result, they sold just over $3.4 billion worth of yoga-specific athletic wear and accessories in their most recent fiscal year.

But going back to Slack, Inc., the better analogy to what we are doing now is to imagine them selling organizational transformation… about 4,000 years ago. It is almost inevitable that blockchain-based coordination and incentive systems will gradually replace predatory vendor lock-in for most organizations over the next 10–20 years and we should do what we can to accelerate the trend and “own it”. We are at the beginning of a transition. We have an opportunity to both define the category and push hard for the whole market’s growth. We’d be crazy not to take it, because the best possible way to find product-market fit is to define your own market.

Who Do We Want Our Customers to Become?

Not too long ago, I heard of a fairly mediocre ebook called “Who Do You Want Your Customers to Become?” It was mediocre because it was nearly 70 pages when it could have been 20, not because the ideas were bad: in fact, the core ideas of the piece are fascinating and, I think, very useful to use as we think about the next year or so of Abridged.

A central thesis is that all products are asking things of their customers: to do things in a certain way, to think of themselves in a certain way — and usually that means changing what one does or how one does it; it often means changing how one thinks of oneself.

We are asking a lot from our customers. We are asking them to spend hours a day thinking about new and unfamiliar product value props, to give up on years or even decades of experience building business models for centralized systems (and abandon all kinds of ad hoc workflows that have developed around their business models). We are asking them to switch to a model of coordination and incentive alignment which defaults to public; it is an almost impossibly large ask. Almost.

To get people to say yes to a request that large, we need to (1) offer them a reward big enough to justify their effort and (2) do an exceptional, near-perfect job of execution.

The best way to imagine the reward is thinking about who we want our customers to become:

• We want them to become relaxed, productive creators who have the confidence that comes from knowing that their product will be judged solely by its value prop, not by UX issues stemming from the low standards of currently mainstream Web 3 technology.
• We want them to become champions of the Incremental Decentralization narrative and not slaves to decentralization maximalism, overwhelmed by difficult commercialization opportunities.
• We want them to become proud of their efficient use of resources that go into product development, not debugging integration compatibility issues.
• We want them to become people who build products faster with a focus on real usage.

This is what we have to be able to offer them, and it is the aim and purpose of all the work we are doing. We need to make them understand what’s at the end of the rainbow if they go with Abridged, and then we have to work our asses off in order to ensure they get there.

How Do We Do It?

We do it really, really fucking good.

The reason for saying we need to do ‘an exceptional, near-perfect job of execution’ is this: When you want something really bad, you will put up with a lot of flaws. But if you do not yet know you want something, your tolerance will be much lower. That’s why it is especially important for us to build a beautiful, elegant and considerate piece of software. Every bit of grace, refinement, and thoughtfulness on our part will pull people along. Every petty irritation will stop them and give the impression that it is not worth it.

That means we have to find all those petty irritations, and quash them. We need to look at our own work from the perspective of a new potential customer and actually see what’s there. Does it make sense? Can you predict what’s going to happen when you call that method or inject that line of SDK code? Is there sufficient feedback to know if the function executed properly? Is it well-written and crisp enough? If I integrate the SDK and generate an account contract, is the address automatically stored locally so the application can access it?

None of the work we are doing to develop the product is an end in itself.

It is always harder to do this with one’s own product: we skip over the bad parts knowing that we plan to fix it later. We already know the model we’re using and the terms we use to describe it. It is very difficult to approach Abridged with beginner’s mind. But we have to, all of us, and we have to do it every day, over and over and polish every rough edge off until this product is as smooth as lacquered mahogany.

Each of you knows “really good”. Each of you is able to see when things are not done well. Certainly we all complain enough about other people’s software, and we all know how important first impressions are in our own judgments. That is exactly how others will evaluate us.

Putting yourself in the mind of someone who is coming to Abridged for the first time — especially a real someone, who is being made to try this thing by their boss, who is already a bit hangry because they didn’t have time for breakfast, and who is anxious about finishing off a project before they take off for the long weekend — putting yourself in their mind means looking at Abridged the way you look at some random piece of software in which you have no investment and no special interest. Look at it hard, and find the things that do not work. Be harsh, in the interest of being excellent.

Why?

There’s no point doing this to be small. We should go big, if only because there are a lot of people in the world who deserve Abridged. Going big also means that it will have to be really, really good. But that’s convenient, since there’s also no point doing it if it is not really, really good. Life is too short to do mediocre work and it is definitely too short to build shitty things.

To do this well, we need to take a holistic approach and not just think about a long list of individual tasks we are supposed to get through in a given week. We get 0 points for just getting a feature out the door if it is not actually contributing to making the experience better for users, or helping them to understand Abridged, or helping us understand them. None of the work we are doing to develop the product is an end in itself; it all must be squarely aimed at the larger purpose.

Consider the teams you see in action at great restaurants, and the totality of their effort: the room, the vibe, the timing, the presentation, the attention, the anticipation of your needs (and, of course, the food itself); nothing can be off. There is a great nobility in being of service to others, and well-run restaurants (or hotels, or software companies) serve with a quality that is measured by its attention to detail. This is a perfect model for us to emulate.

Ensuring that the pieces all come together is not someone else’s job. It is your job, no matter what your title is and no matter what role you play. The pursuit of that purpose should permeate everything we do.

But Abridged is a bit more complicated than a restaurant (at least in some ways). Since it is new and less familiar, we are less able to fall back on well-established best practices. That means we need to listen, watch & analyze carefully. We’ll need to build tools to capture users’ behaviour and reactions. And then we’ll need to take all that information and our best instincts and be continuously improving.

We are an exceptional product development team. But, we now also need to be an excellent customer development team. That’s why, in the first section of this doc, I said “build a customer base” rather than “gain market share”: the nature of the task is different, and we will work together to understand, anticipate and better serve the people who trust with their teams’ development flow, one customer at a time.

The answer to “Why?” is “because why the fuck else would you even want to be alive but to do things as well as you can?”. Now: let’s do this.

Huge shoutout to Stewart Butterfield and his team for creating one of the most successful products of the 21st century!