Regulating Big Tech is a Product Problem
In late March, the European Parliament reached a new agreement on rules that will govern large tech platforms. A key element of this is the requirement that large "gatekeepers" be interoperable, and avoid using their dominance to favor their own products. One instance of this could be that Google can't promote its own maps service over, say, Apple Maps or MapQuest. But the most controversial is the idea that messaging apps should be interoperable. Specifically (from this draft):
The lack of interconnection features among the gatekeeper services may substantially affect users choice and ability to switch due to the incapacity for end user to reconstruct social connections and networks provided by the gatekeeper even if multi-homing is possible. Therefore, it should be allowed for any providers of equivalent core platform services to interconnect with the gatekeepers number independent interpersonal communication services or social network services upon their request and free of charge. Interconnection should be provided under the conditions and quality that are available or used by the gatekeeper, while ensuring a high level of security and personal data protection. In the particular case of number-dependant intercommunication services, interconnection requirements should mean giving the possibility for third-party providers to request access and interconnection for features such as text, video, voice and picture, while it should provide access and interconnection on basic features such as posts, likes and comments for social networking services. Interconnection measures of number-independent interpersonal communication services should be imposed in accordance with the provisions of the Electronic Communications Code and particularly the conditions and procedures laid down in Article 61 thereof. It should nevertheless presume that the providers of number-independent interpersonal communications services that has been designated as a gatekeeper, reaches the conditions required to trigger the procedures, namely they reach a significant level of coverage and user uptake, and should therefore provide for minimum applicable interoperability requirements.
The first big objection to this is privacy: either every app needs every other app's keys, in which case security runs into a lowest-common-denominator problem, or messages can no longer be encrypted end-to-end. If that sounds like a big deal to you already, you can see this proposal as a nonstarter. If it doesn't, consider a case where a dissident in an authoritarian country is using an app that, because it's also available in the EU, is complying with these rules, and that, because it’s offered by a small company, can’t afford to build different versions for different markets. There are plenty of governments that are ineffective at useful and prosocial functions but quite good at digging up information about their citizens and exploiting it to maximum effect. (And to take it a step further, what if bad actors start creating apps specifically because they need to be interoperable, and then deliberately break their security?)
But the problem goes even deeper than these security risks. The real question is: how would any of this work? It's meant to benefit "independent interpersonal communication services," and there's no stated limitation on their size. So, as written, we have the possibility that anyone who codes up a chat app can knock on the door of the EU and demand that users of their service are able to message arbitrary users of WhatsApp, iMessage, etc. If you have a free afternoon and would like to launch a chat app that will have permission to message hundreds of millions of people, there are plenty of online tutorials for whipping up such a product quickly.
Of course, it may not work that way. We don't want to spam people, or have their phones hang as it tries to populate a list of millions of tiny chat apps that all get equal billing with WhatsApp. So we have to have some cutoff. Maybe an app needs a million active users to deserve interoperability, and otherwise it's on its own.
Now we have two more problems:
- This cutoff introduces a discontinuity in growth paths. Small, obscure apps stay small and obscure, but if they can somehow bootstrap to a certain size, their growth explodes because they're so much more useful, since they can free-ride on other apps' networks. This continues until they hit another threshold, when they're big enough that they have to interoperate, at which point they're suddenly less useful after all.
- Usage-based cutoffs are incredibly gameable. Music service Tidal allegedly faked streams to make the app appear more popular than it was, and writing chatbots is even easier than writing a chat app. Popularity criteria can be gamed, whether they're installs, users, or even revenue. Of course, this could be audited, but that introduces its own vast overhead.
Implementing interoperability becomes a question of distinguishing legitimate chat and social apps from illegitimate ones, and that turns out to be hard. Looking at Google Play's list of highlighted communications apps shows several chat apps that I'd never heard of with hundreds of thousands to millions of installs. Is it intuitively obvious that "Guilded," "Threema," "ZipMsg," and "Marco Polo" are all, apparently, frequently-used chat programs? (If it was easy, keep in mind that I made one of those up.)
And, assuming we accomplish this, we have another problem-spawning-problem: a good communications tool offers a little bit of being able to contact people and a lot of being able to avoid being contacted by people. Spam is 85% of emails, because it scales faster than regular communications. And within opted-in emails, it's unclear how many the recipient wants to receive. Gmail, Messenger, and even LinkedIn put a lower priority on some kinds of messages that users don't want, and have various ways of rate-limiting aggressive senders.
This is not without controversy. For example, it seems that one of the signals Facebook uses for blocking and downranking content is sudden spikes in popularity. There have been a few small companies that grew fast through Facebook users sending one another messages until this tripped a signal that blocked the messages as spam. This specific kind of false positive hasn't shown up much in recent years, perhaps because Facebook isn't where viral growth happens any more, but similar false positives still happen when growth coupled with content and context triggers a rule. If major services are required to let users receive inbound messages from outside apps, then either a lot of those messages will go to the spam folder—which will make it look like the big platforms aren't cooperating—or they won't go to spam and users will have a degraded experience.
Even if this isn't done in a malicious way, it can be a pain when it happens because of different use cases for different apps, and different users' use cases for them. For some people, email is for serious work and Facebook is for goofing off. For a small business owner who fields customer requests through Messenger, it can be the other way around. Discord is play rather than work for a gamer, but it's a key element of the enterprise communications stack for many people in crypto. Since social networks message over particular protocols, the app sending an alert is a valuable signal, but a different one for every user, and interoperability weakens this. The optimistic case is that messaging platforms will get better at filtering, and make it easier to customize notifications based on sender and context rather than the app itself. But this will end up making the dominant apps more popular, since they're the ones that will be able to afford to do this right and since users won't want to spend the same fifteen minutes learning and implementing customizations in a dozen different apps.
These problems aren't necessarily impossible to solve, or may end up creating tradeoffs that are ultimately worthwhile. But the real upshot is that, increasingly, regulating tech platforms is not just about economics and legal standards but a question of product.
It's very common to use an app for a while, like it, and notice that it either has some behavior that's constantly annoying or that it lacks some obvious feature that would really enhance the user experience. A very valuable meditative exercise is to start with the assumption that the company building the app probably has lots of highly-paid employees whose entire job is to figure out what features the app should and shouldn't have. Any change to the app has been, at a minimum, debated to death, and probably tested, too. It's easy to come up with obvious complaints—Amazon's product pages are cluttered and it's hard to find anything useful on them; Twitter won't let me fix typos in viral tweets; Snapchat's designers have contempt for your primitive earthling notions of discoverability, etc. But the market's pretty efficient over time, especially for apps that are big because they're popular! So it's useful to imagine the debate over this feature, and try to come up with the strongest arguments for it or against it, to see what tradeoffs the company in question is making.
An iPhone is six inches by three. There's not enough room to display every feature. Navigating deeply through menus is a pain, and searching for features only works if the user knows exactly what to look for or the company enumerates every possible synonym for what they have to offer. So hypothetical features are engaged in a never-ending bidding war for your hypothetical attention, and promoting one usually means implicitly demoting another. Even very effective product teams have to make difficult calls—Facebook's Reels might be a company priority, but it's costing engagement on photos and regular videos, at least in the short term, and the company has to navigate that tradeoff.
There are some angles where more direct and heavy-handed regulation can meaningfully alter companies' behaviors. Blocking large acquisitions, whether those are based on user counts or revenue, will accomplish roughly what it's intended to. (Though it will also encourage companies to be more forward-looking and Straussian in their M&A ($).) But changing how the product works will only have its intended effect if the same amount thought goes into that as went into the question of how those products work in the first place. Expect regulation of tech products, versus tech M&A, to miss the mark. It may create customer annoyances, the way the EU's cookie rules do. It might have a minimal effect, like Google's agreement to let companies bid for the top search spot. It could make big companies even more powerful, as restrictions on sharing third-party data do since they increase the relative value of first-party data. Until regulators can compete with consumer Internet companies on product, creating broad mandates that compile down to product decisions will be wildly ineffective.
Further reading: some great pieces on this include Platformer's look at how hard this will be to implement, this Stratechery piece arguing that it's a protocol-level question ($), and this one from the lead of the team that implemented end-to-end encryption in Facebook Messenger about the dangers of interoperability and some potential partial workarounds.
- A startup tackling big problems in wealth management is looking for founding engineers with a focus on the backend. (US, Remote)
- A company is solving a pain point for developers in a really interesting way is looking for engineers. (Washington D.C. area)
- A company which is building a marketplace for private equity secondaries transaction is looking for a co-founder to lead their deal sourcing and pitching efforts. (US, remote)
- A company with a novel systematic strategy is looking for engineers to help build out their crypto platform. (NYC)
- A company in the edtech space is looking for Senior Product Managers to help them build out the next generation of their service. (US, remote)
Gergely Orosz of The Pragmatic Engineer has a great look at what happened at one-click payments company Fast from the perspective of people who interviewed with or went to work for the company. The upshot is that Fast was scaling, but in the wrong areas: it hired a sales team large enough that they could close deals with numerous small companies, but those deals involved a big engineering lift. As the net dollar retention numbers of SaaS companies targeting different-sized customers may indicate, the economics of selling to big businesses are usually better; a small customer can be closed faster, but there's a lot more work involved, and growing the customer count before the unit cost of doing so has been nailed down is a bad plan.
The Fast story illustrates that hypergrowth is a momentum strategy: if a company is well-hyped, it can raise enough money to potentially hire the team needed to live up to that hype. And with Fast's unit economics—The Information says Fast was getting 2.9% of transactions but paying 2.7% to Stripe ($)—fixed costs for each deal would be fatal for smaller deals. Once the company started getting negative press, it wasn't able to raise its next round. Given that Fast was hiring the entire time, it's possible that they planned some kind of pivot once they'd raised more money, but growing in advance of such a pivot means betting the entire business on getting the next venture check.
What this story also illustrates is the growing value of topic-specific newsletters. The Pragmatic Engineer has a lot of data on when Fast was hiring and what they were saying to potential employees. A story written by a more generalist publication might have been able to pick up some of this information over time, and could produce a well-written post-mortem weeks or months after the fact. But when there are writers spending all of their time on just one area, they tend to have the facts at hand necessary to produce a well-researched piece within days of a big event.
More Signs of Slower Inflation
While the CPI will still be experiencing the lagged effects of rent increases for a while, some other drivers of high inflation are slowing down: the Manheim used car price index was up 25% Y/Y in March, compared to +37% in February and +45% in January. That's still a lot of growth, and there are early signs that summer will be incredibly busy for travel which can affect rental car companies' fleet decisions and thus constrain supply. But the index reached its highest value in December and has been declining since then. The view last year that inflation would be transitory turned out to be wrong (I leaned towards a transitory view then, too ($)). But even if overall inflation is elevated for durable reasons, there are specific categories where prices went up for idiosyncratic reasons and are coming down.
One area where price increases don't appear to be moderating is wages. For instance, Walmart is offering new truckers $110k plus bonuses, after a twelve-week training program ($, WSJ). Retailers have a slightly different attitude towards compensation than pure trucking companies do. For Walmart, part of the point of controlling its logistics network is reducing the variance: their model assumes high inventory turnover, and the only way to get that is to be precise about which goods arrive when. So Walmart can pay a premium for some workers and make the money back through lower capital costs. As more companies fit the model of always having goods in stock and managing their inventory tightly, we might start to see wider dispersion in compensation for the roles tied to this. It's possible to hire truckers, forklift operators, warehouse workers, etc. for relatively low wages, but the cost-effective strategy might involve some pickiness in hiring and commensurately higher pay.
The NYT has told reporters they don't necessarily need to be on Twitter, and should be more careful about how they use it ($, Business Insider). Part of this is because Twitter is like a comments section except that people don't need to register with the Times to comment on their articles and a block doesn't feel as good as a ban. But part of it has an economic motivation: a frequent pattern in online media is that a low-friction, low-monetization site is the top of the funnel for a higher-friction but higher-monetization one. When a business is growing its subscriber count, it makes sense to focus on the free complement in order to draw in new users. But as it matures, churn starts to matter more than gross subscriber growth, at which point the focus turns to keeping existing users happy. In other words, the Times is gently suggesting that writers cater more to the interests of existing readers, and not to the wilder whims of the broader Twitter audience.
A fun corner of the global financial system used to be Macau's junket operators. These were individuals and companies who specialized in a) getting high-rolling customers from Mainland China to Macau's casinos, and b) in moving money between these two places, or perhaps out of Macau entirely. Casinos always have a tricky relationship with monetary authorities, because wins are a convenient excuse for making money that's otherwise hard to explain, and losses are a good cover story for money that's moved somewhere it shouldn't. The junket system has been shutting down for years, which accelerated late last year. Some operators responded to this by finding new lines of work, but others responded by working with casinos in other countries, like the Philippines and Russia ($, Nikkei). In many cases, this has ended with arrests. Gambling in Macau was a revenue source for a while, but was also a cash leak, and, from the CCP's perspective, a control leak. Domestic money could be transmuted into offshore money that was harder to measure and harder to confiscate. Macau served its purpose for a while, but wound up being more trouble than it was worth.