Axiom.org MVP Review: Blockchain? More like Bloatchain

Consider the category of Blockchain Applications. It seems to me like 99.9% of them have zero serious users. This is so widespread and obvious that I haven’t even been interested to document them on this blog. It would be like blogging about how a jogger in full “chain”mail armor isn’t going to win a footrace.

But there’s also a category of Blockchain Application Platforms: platforms that help developers build and operate blockchain applications. If I’m right that pretty much all Blockchain Applications are bloated MVPs, then anyone who launches a Blockchain Application Platform is at best launching a lean MVP for bloated MVPs, and at worst launching a bloated MVP for bloated MVPs: a bloated MVP squared.

This brings me to Axiom, a blockchain designed to let you “Build, distribute, and run JavaScript-based applications, uncensored by any central authority.”

Axiom is founded by Kevin Lacker. Kevin previously cofounded Parse, a once-popular Platform-As-A-Service backend for mobile applications which was acquired by Facebook in 2013 and shut down a few years later.

Axiom’s execution looks good to me, like what you’d expect when a strong engineer who knows all about Application Platforms and Blockchain embarks to build a Blockchain Application Platform.

When an MVP is well-executed, it adds urgency to the question of whether it’s a bloated MVP. Because counterintuitively, the more well-executed a bloated MVP is, the more bloated it is… because it pays a higher opportunity cost. A genius-year of effort is a more precious thing to waste on a bloated MVP than a year of average-IQ effort, wouldn’t you agree?

Vacillating between two distinct value props

I see two distinct alleged value props in Axiom:

1. Censorship resistance
2. Sharing data across applications

These are orthogonal value props, because in theory it’s totally possible to build a platform whose only differentiator is #1, or whose only differentiator is #2.

Excerpt from axiom.org home page

Personally, for what it’s worth, I think censorship resistance (#1) is a meatier problem than data-sharing (#2) to solve at a structural level. I can imagine that bringing in all the complexity of a blockchain is maybe necessary for censorship resistance, but I’m skeptical that a blockchain is needed merely for sharing data across applications.

Regardless, it’s a red flag that the MVP advertises two orthogonal value props. Two value props means there are two orthogonal hypotheses about market demand, both of which are currently unvalidated from my perspective.

If you pick one value prop hypothesis and launch the minimal thing you need to validate demand for that hypothesis, that’s a lean MVP. If you pick two orthogonal ones and stick them together, that’s usually a bloated MVP.

Value prop story isn’t fleshed out

Here’s my Twitter back & forth with Kevin. My biggest takeaway here is that no one has told a sufficiently specific value prop story yet about Axiom. I keep asking followup questions to try to get incremental bits of specificity, because no one has envisioned or prototyped an end-to-end example of a specific person giving specific value to another specific person via the Axiom platform.

Also note that when Kevin mentions the “sharing data across applications” value prop in one of his tweets, specifically saying “multiple applications could connect to the data and let you use it”, I chose to keep the conversation focused only on the “censorship resistance” value prop because I believe it has the higher chance of having a plausible value prop story.

The opposite of launching with a killer app

There are basically four degrees between “launching a new platform with a killer app ready on day 1” and “launching a new platform with no examples of usefulness whatsoever”:

1. Launch platform together with a specific “killer app”: Think Nintendo launching their next console where on day 1 you can play Super Mario on it.
2. Launch platform with a handful of third-party applications as beta partners: Think Apple launching a new release of iOS or one of its dev-kits.
3. Launch platform with a few simple demo applications
4. Launch without any end-to-end demonstrations of what the value is

This looks like #4 at this stage. It could pretty easily be remedied, I’m not writing that off. But when you’re going to spend so much effort building an elegant platform, you really owe it to yourself to think through its use cases in more detail.

Conclusion

Most startup observers aren’t yet able to analyze product launches using a Bloated-MVP filter. My goal on this blog is to catalog launches that meet the criterion of Bloated MVP, in order to raise awareness of the concept and its usefulness.

I actually think Axiom is a cool idea with some nonzero chance at success. I think it may have a plausible value prop story to be told in the area of censorship resistance. I just want to point out that its MVP is breaking a lot of the rules explained in this blog, and add it to the pile of test cases for my thesis that launching a bloated MVP is inversely correlated with getting traction.

My falsifiable empirical prediction is that Axiom will not be used by any app that gets any serious users. I may be wrong, especially given the strength of the founder and execution.

It’s just that… If you think your product has “countless” uses, but you haven’t thought through one specific one in detail, then your product most likely has zero actual uses.

Update Jun 2021: Kevin graciously replied.