Weekend Reading: Readwise's Next Chapter, Reviewing Revolt of the Public, and the Helicopter State

September 17, 2021 • #

📚 The Next Chapter of Readwise: Our Own Reading App

Great to see this evolution of Readwise to enter the “read-later” app space. None of the options out there seem to be thriving anymore (Pocket, Instapaper, etc.), but some of us still rely on them as essential parts of our reading experience.

The Readwise team has been moving fast the last couple years with excellent additions to the product, and I can’t believe they were also working on this for most of 2021 along with the other regular updates. Impressive.

🪧 Book Review: The Revolt of the Public

Scott Alexander reviews Martin Gurri:

People could have lowered their expectations, but in the real world that wasn’t how things went. Instead of losing faith in the power of government to work miracles, people believed that government could and should be working miracles, but that the specific people in power at the time were too corrupt and stupid to press the “CAUSE MIRACLE” button which they definitely had and which definitely would have worked. And so the outrage, the protests - kick these losers out of power, and replace them with anybody who had the common decency to press the miracle button!

Revolt of the Public was published in 2014, a time when most of his diagnosis of political discontent was prescient. But as SA points out, most of the subject matter is received wisdom in 2021.

I still highly recommend Gurri as a writer, and RotP for its analysis of root causes more than its predictions of things to come. More on Gurri here and here, and give a watch to his Revolt of the Public in 10 Minutes talk to get the precis on his work if you’re unfamiliar.

🏛 The Helicopter State

Jonah’s G-File is one of the rare read-every-issue newsletters, and this one is one of my recent favorites:

The government can’t love you, and when it works from the premise that it can, folly or tyranny follow. We need people in our lives, not programs. Because people give us the very real sense that we are part of something, that we’re needed and valued. Programs treat us like we’re metrics in some PowerPoint slide.

Helicopter parenting has a negative perception, as it should, but it’s still done all the time. Helicopter governing should be treated the same, but is also promoted and defended far too often.

Kindle Cloud Reader

September 16, 2021 • #

I use the Kindle desktop app a fair amount, usually for going back to books I’ve already read for reference, or to review highlights and make notes. It’s always been a pretty bad application, with a strangely dated interface and extremely rare updates, but lately it’s gotten unusable. Maybe it’s unstable on the M1 Mac mini. It now crashes constantly and corrupts the local data, requiring purge and reinstall to fix it.

Instead of fighting with it, I went back to their Kindle Cloud Reader, a web-based version of the same Kindle client that Amazon’s kept around for a decade. Like the desktop app, it gets almost no attention that I can tell. But since it runs in the browser, it doesn’t have the same stability problems as the desktop app, and seems to support all of the same basic reading and annotation features as the other clients.

Until Amazon decides to care about Kindle’s software products, I’d recommend using the Cloud Reader for desktop reading. It’s sad to see them flounder around with their massive advantage in the e-reading space. They can get away with this, of course, as the de facto default platform for e-books still, but it seems inevitable that someone will come along and disrupt this position.

Exapting Technologies

September 9, 2021 • #

New forms of technology tend not to materialize from thin air. The nature of innovation takes existing known technologies and remixes, extends, and co-opts them to create novelty.

Gordon Brander refers to it in this piece as “exapting infrastructure.” As in the case of the internet, it wasn’t nonexistent one day then suddenly connecting all of our computers the next. It wasn’t purposely designed from the beginning as a way for us to connect our millions of computers, phones, and smart TVs. In fact, many types of computers and the things we do with them evolved as a consequence of the expansion of the internet, enabled by interconnection to do new things we didn’t predict.

Former railroad corridors are regularly reused as cycling trails Former railroad corridors are regularly reused as cycling trails

Exaptation” is a term of art in evolutionary biology, the phenomenon of an organism using a biological feature for a function other than it was adapted for through natural selection. Dinosaurs evolved feathers for insulation and display, which were eventually exapted for flight. Sea creatures developed air bladders for buoyancy regulation, later exapted into lungs for respiration on land.

In the same way, technologies beget new technologies, even seemingly-unrelated ones. In the case of the internet, early modems literally broadcast information as audio signals over phone lines intended for voice. Computers talked to each other this way for a couple decades before we went digital native. We didn’t build a web of copper and voice communication devices to make computers communicate, but it could be made to work for that purpose. Repurposing the existing already-useful network allowed the internet to gain a foothold without much new capital infrastructure:

The internet didn’t have to deploy expensive new hardware, or lay down new cables to get off the ground. It was conformable to existing infrastructure. It worked with the way the world was already, exapting whatever was available, like dinosaurs exapting feathers for flight.

Just like biological adaptations, technologies also evolve slowly. When we’re developing new technologies, protocols, and standards, we’d benefit from less greenfield thinking and should explore what can be exapted to get new tech off the ground. Enormous energy is spent trying to brute force new standards ground-up when we often would be better off bootstrapping on existing infrastructure.

Biology has a lot to teach us about the evolution of technology, if we look in the right places.

Image credits: Florida ECRRT

Product-led Growth Isn't Incompatible with Sales

September 1, 2021 • #

Product-led growth has been booming in the B2B software universe, becoming the fashionable way to approach go-to-market in SaaS. I’m a believer in the philosophy, as we’ve seen companies grow to immense scales and valuations off of the economic efficiencies of this approach powered by better and better technology. People point to companies like Atlassian, Slack, or Figma as examples that grew enormously through pure self-service, freemium models. You hear a lot of “they got to $NN million in revenue with no salespeople.”

This binary mental model of either product-led or sales-led leads to a false dichotomy, imagining that these are mutually exclusive models — to grow, you can do it through self-service or you can hire a huge sales team, pick one. Even if it’s not described in such stark terms, claims like “they did it without sales” position sales as a sort of necessary evil we once had to contend with against our wills as technology builders.

Product-sales compatibility

But all of the great product-led success stories (including those mentioned above) include sales as a component of the go-to-market approach. Whether they refer to the function being performed by that name or they prefer any number of other modern euphemisms (customer happiness advocate, growth advisor, account manager), at scale customers end up demanding an engagement style most of us would call “sales.”

Product-led, self-service models and sales are not incompatible with one another. In fact, if structured well, they snap together into a synergistic flywheel where each feeds off of the other.

Early-stage customers

Product-led tactics have the most benefit in the early stage of a customer’s lifecycle, when your product is unproven. Free trials and freemium options lower the bar to getting started down to the floor, self-service tools allow early users to learn and deploy a tool in hours on their own timeline, and self-directed purchasing lets the buyer buy rather than be sold to. In 2021, flexibility is table stakes for entry-level software adoption. There are so many options now, the buying process is in the customer’s control.

With the right product design, pricing, and packaging structure, customers can grow on their own with little or no interaction through the early days of their expansion. For small to mid-size users, they may expand to maximum size with no direct engagement. Wins all around.

For larger customers (the ones all of us are really after in SaaS), this process gets them pretty far along, but at some stage other frictions enter the picture that have nothing to do with your product’s value or the customer’s knowledge of it. Financial, political, and organizational dynamics start to rear their heads, and these sorts of human factors are highly unlikely to get resolved on their own.

The Sales Transition

Once the bureaucratic dynamics are too great, for expansion to continue we need to intervene to help customers navigate their growing usage. As I wrote about in Enterprises Don’t Self-Serve, several categories of friction appear that create growth headwinds:

  • Too many cats need to be herded to get a deal done — corralling the bureaucracy is a whole separate project unrelated to the effectiveness or utility of the product; no individual decision maker
  • The buyer isn’t the user — user can’t purchase product, purchaser has never used product; competing incentives 
  • If you have an advocate, they have a day job — And that job isn’t playing politics with accounting, legal, execs, IT, and others

As you start encountering these, you need to proactively intervene through sales. The role of sales is to connect with and navigate the players in the organization, then negotiate the give and take arrangements that create better deals for both parties: e.g. customer commits to X years, customer gets Y discount. Without a sales-driven approach here, every customer is treated as one-size-fits-all. Not the best deal for the vendor or customer. When you insert sales at the right stage, you increase the prospect of revenue growth, and the customer’s ability to sensibly scale into that growth with proper integration throughout their organization.

In SaaS literature you’ll read about the notion of “champions”, internal advocates for your product within your customer that are instrumental in growing usage. Champions serve a function in both methodologies — with product-led, they’re pivotal for adoption to perpetuate itself without your involvement, and when engaging with sales, we need those champions to be intermediaries between vendor and buyer. They act like fixers or translators, helping to mediate the communication between the sides.

A well-built, product-led product mints these champions through empowerment. We give users all the tools they need — documentation, guides, forums, SDKs — to build and roll out their own solution. After a couple phases of expansion, users evolve from beginners to experts to champions. If we’re doing it right and time sales correctly, champions are a key ingredient to maximizing relationships for customers and product-makers. Product-led approach early creates inertia to keep growing, a back pressure that sales can harness to our advantage.

AppCues publishes their product-led growth flywheel, which describes this cycle succinctly:

Product-led flywheel

As they demonstrate, a user becoming a champion isn’t the end state; champions beget future brand new users through advocacy, word-of-mouth, and promotion within their own networks.

It’s dangerously short-sighted to look down the nose at sales as a bad word. Sales isn’t just something you resort to when you “can’t do PLG”, it’s a positive-sum addition to your go-to-market when you execute this flywheel properly.

Weekend Reading: Robotic Bricklaying, Medici and Thiel, and Airtable, Roblox of the Enterprise

August 13, 2021 • #

🧱 Where Are the Robotic Bricklayers?

Brian Potter wonders why work as taxing and seemingly-mechanically simple as brick masonry is difficult to automate:

Masonry seemed like the perfect candidate for mechanization, but a hundred years of limited success suggests there’s some aspect to it that prevents a machine from easily doing it. This makes it an interesting case study, as it helps define exactly where mechanization becomes difficult - what makes laying a brick so different than, say, hammering a nail, such that the latter is almost completely mechanized and the former is almost completely manual?

Even with the number of problems we’ve solved with machines and AI, something as basic as handling mortar still requires the finesse of human hands, a task which, while actually very hard to learn (it’s why masons are still skilled artisans millennia after its invention), can be taught and repeated on autopilot by masons. It turns out non-Newtonian materials are hard for machines:

There seems to be a few factors at work. One is the fact that a brick or block isn’t simply set down on a solid surface, but is set on top of a thin layer of mortar, which is a mixture of water, sand, and cementitious material. Mortar has sort of complex physical properties - it’s a non-newtonian fluid, and it’s viscosity increases when it’s moved or shaken. This makes it difficult to apply in a purely mechanical, deterministic way (and also probably makes it difficult for masons to explain what they’re doing - watching them place it you can see lots of complex little motions, and the mortar behaving in sort of strange not-quite-liquid but not-quite-solid ways). And since mortar is a jobsite-mixed material, there will be variation in it’s properties from batch to batch.

💶 On Medici and Thiel

Rohit Krishnan makes the case for more Genius Grant-style programs.

📊 Airtable: The $7.7B Roblox of the Enterprise

Will Airtable become the “Metaverse for the Enterprise”? In this detailed analysis, Jan-Erik Asplund dives into the bear and bull cases for what could become of the unicorn spreadsheet successor.

The world Airtable is imagining is a world where knowledge workers no longer have to assess different vendors’ offerings when they want to build a new functionality or experiment with some new type of workflow. Instead, Airtable argues, workers should be able to spin up their own tools using building blocks as simple, but capable of as much complexity, as a set of legos.

Summer Trip

August 10, 2021 • #

Last week we did a fun end-of-summer trip across Florida. We procrastinated figuring out a plan for doing something with the kids before school starts back this month.

The kids have never been to any of the famous Central Florida theme parks, so we decided on LEGOLAND in Winter Haven, since it was a bit short notice to do anything at Disney. Everett has been obsessed with the LEGO Mario sets and they both love ‘em, so they had a great time on the rides. The park is great since it’s a combination typical theme park with an attached water park in the back. So we got to do both.

LEGOLAND

After a couple days at an Airbnb in Orlando (which also had its own mini water park), we drove up to St. Augustine for a couple days on the Atlantic beaches. It may seem weird to vacation at the beach when we live 10 minutes from one, but the beaches on Florida’s east coast are pretty different from the west side. The beaches are mostly hard-packed sand, much wider, with more consistent waves than our West Florida variety. I briefly attempted surfing on Elyse’s board, but didn’t come close to standing up.

Then on the last day we circulated through the Castillo de San Marcos fort near downtown, and took a quick walk through the old city before heading back across the state.

Weekend Reading: Koestler on Awareness, 21st Century Alchemy, and the Gini Coefficient

July 30, 2021 • #

🔮 The Nightmare That Is a Reality

In early 1944, journalist Arthur Koestler was onto the horrors of the Holocaust taking place in Europe. He wrote this essay, originally published in the New York Times, calling attention to the atrocities in a climate where most in media were denying or claiming conspiracy.

At present we have the mania of trying to tell you about the killing, by hot steam, mass-electrocution and live burial of the total Jewish population of Europe. So far three million have died. It is the greatest mass-killing in recorded history; and it goes on daily, hourly, as regularly as the ticking of your watch.

We say, “I believe this,” or, “I don’t believe that,” “I know it,” or “I don’t know it”; and regard these as black-and-white alternatives. Now in reality both “knowing” and “believing” have varying degrees of intensity. I know that there was a man called Spartacus who led the Roman slaves into revolt; but my belief in his one-time existence is much paler than that of, say, Lenin. I believe in spiral nebulae, can see them in a telescope and express their distance in figures; but they have a lower degree of reality for me than the inkpot on my table.

Even during the war, the levels of denial were palpable. People didn’t believe the available evidence of what the Nazi regime was doing. He closes out the essay with a remarkably prescient observation of what happens when communications are pervasive: we have more evidence than ever before, and yet still have trouble separating fact and fantasy:

Our awareness seems to shrink in direct ratio as communications expand; the world is open to us as never before, and we walk about as prisoners, each in his private portable cage. And meanwhile the watch goes on ticking. What can the screamers do but go on screaming, until they get blue in the face?

See also episode #40 of The Portal, where Eric Weinstein discusses the essay.

⚗️ 21st Century Alchemy

Alex Crompton responds to the supply problem in investing in companies:

There are way more investors than there are companies that make investors money. By some estimates, less than 1% of the companies investors fund generate over 75% of the profits across the entire industry.

Since investors are always seeking the opportunities from the same supply of founders and companies, there are only a few tactics that can work to differentiate yourself and find the truly great returns — primarily access, exposure, and quality selecting (picking the winners from the group).

But at his firm EF, a unique sort of incubator, they focus on generating supply. If you can generate founders no one else is finding (because they’re otherwise never founding companies), you create a type of alchemy that spawns ideas that’d never get off the ground otherwise.

This is what we’re doing at EF. We are taking in raw materials — hundreds of extraordinary people from across the world every year — and putting them through an iterative, data driven methodology. We are experimenting all the time: collecting information about the founders we support; understanding their qualitative experience; and learning what works and doesn’t work. From the moment we first make contact, we are building a methodology to get them from Day minus 100 to Day 1 of something valuable.

📊 Against Overuse of the Gini Coefficient

Vitalik Buterin on the Gini coefficient’s problems when measuring distributions in crypto:

A typical resident of a geographic community spends most of their time and resources in that community, and so measured inequality in a geographic community reflects inequality in total resources available to people. But in an internet community, measured inequality can come from two sources: (i) inequality in total resources available to different participants, and (ii) inequality in level of interest in participating in the community.

Taking Back Our User Accounts

July 28, 2021 • #

Identity management on the internet has been broken for years. We all have 800 distinct logins to different services, registered to different emails with different passwords. Plus your personal data exists in a morass of data silos, each housing a different slice of your personal information, each under a different ToS, subject to differing privacy regulations, and ultimately not owned by you. You sign up for a user account on a service in order for it to identify you uniquely, providing functionality tailored to you. Service providers getting custody of your personal data is a side-effect that’s become an accepted social norm.

Ethereum chain

In this piece, Jon Stokes references core power indicators in public finance like capital ratios or assets under management that help tell us when an institution is getting too big:

As a society, we realized a long time ago that if we let banking go entirely unregulated, then we end up with these mammoth, rickety entities that lurch from crisis to crisis and drag us all down with them. So when we set about putting regulatory limits on banks, we used a few simple, difficult-to-game numbers that we could use as proxies for size and systemic risk.

The “users table” works as an analogous metric in tech: the larger the users table gets (the more users a product has), the more centralized and aggregated their control and influence. Network effects, user lock-in, and power over privacy policies expand quadratically with the scope of the user base.

As Stokes points out, web3 tech built on Ethereum will gradually wrest back control of the users table with a global, decentralized replacement controlled by no-one-in-particular, wherein users retain ownership of their own identity:

Here’s what’s coming: the public blockchain amounts to a single, massive users table for the entire Internet, and the next wave of distributed applications will be built on top of it.

Dapps on Ethereum are so satisfying to use. The flow to get started is so smooth — a couple of clicks and you’re in. There’s no sign up page, no way for services to contact you (presumably unless they build something to do so and you opt-in to giving your information). Most of my dapp usage has been in DeFi, where you visit a new site, connect your wallet, and seconds later you can make financial transactions. It’s wild.

The global users table decentralizes the authentication and identity layers. You control your identity and your credentials, and grant access to applications if you choose.

Take the example of a defi application like Convex. When I visit the app, I first grant the service access to interact with my wallet. Once I’m signed in, I can stake tokens I own, or claim rewards from staking pools I’ve participated in proportional to my share of the pool. All of the data that represents my balances, staking positions, and earned rewards lives in the smart contracts on the Ethereum blockchain, not in Convex’s own databases. Services like this will always need to maintain their own application databases for aspects of their products. But the critical change with the global users table is that the user interaction layer exists on-chain and not in a silo’d database, with custody completely in the hands of the person with the keys to the wallet.

If more services use the dapp model and build on the public, on-chain global users table, what will the norms become around extending that table with additional metadata? With some systems like ENS (the Ethereum Name Service, decentralized DNS), subdomains and other addresses associated with an ENS address are properties written on the blockchain directly. This makes sense for something like name services, where they’re public by design. But other use cases will still require app developers to keep their own attributes associated with your account that don’t make sense on the public, immutable blockchain. I may want GitHub to know my email address for receiving notifications from the app, but I may not want that address publicly attributed to my ETH address.

Web3 is so new that we haven’t figured out yet how all this shakes out. The most exciting aspect is how it overturns the custody dynamics of user data. Even though this new world moves the users table out of the hands of individual companies, everyone will benefit (users and companies) over the long-term. Here’s Stokes again:

If you want to build a set of network effects that benefit your company specifically, it won’t be enough to simply cultivate a large users table or email list — no, you’ll have to offer something on-chain that others are also incentivized to use, so that the thing you’re uniquely offering spreads and becomes a kind of currency.

Incentives for app developers will realign in a way that produces more compelling products and a better experience for users.

Subscribe here to receive my newsletter, Res Extensa, a digest of my latest posts, links, and updates. Currently bi-weekly.