▲ 258 points
back
79 comments
This may be a bit of an old allusion, but Lotus Notes is a great example of this. Notes is fundamentally a programmable, non-relational, client/server replicated database with a UI on top of it. It's a workflow engine for accomplishing whatever business processes a company might have that can be made to keep working pretty well when the client computer is offline. It can be anything.
But it is remembered first and foremost as an email system, a feature that's fairly trivial to implement once you have a replicated database and a UI on top of it that can display lists and text. But it had to be an email system first because you can't sell something that can do anything if it doesn't do anything.
I remember a long long time ago people used Filemaker Pro for all sorts of small data driven applications. I used to think stuff like that would be the future of computing, but instead Filemaker Pro faded into obscurity and most people just use Excel for those kinds of problems now. Or worse, the problem is solved in a clunky and fragile way with outrageously expensive Peoplesoft/Workday/Salesforce type solutions.
That is kind of how it went, but there was more than email in its early days. Email existed, but Lotus also sold a separate email product. The rumors at the time ('94) were that Lotus was going to remove email from Notes and focus on apps. But instead IBM bought both and merged them. It got kinda lost from there, while also getting way bigger, but that is a different story.
Even so, it did have some app templates that came with it back in those early days - a helpdesk ticketing system, a sales CRM, discussions. I forget what they all were, but there was definitely a base of examples aside from email for people to start with.
I spent about two years in early development of a "Zombocom" product and one question on my mind was "Whatever happened to Lotus Notes?" Superficially it seems the time is right for a rapid development platform for web apps based on an object database with synchronization support. I was sharply divided about the role of email in such a product:
I became a qmail fanatic around 1999 and enjoyed running a smart mail server but as we got into the early 2000's I experienced a series of crises involving worms, viruses, malware, spam, deliverability and such. Today I want nothing to do with running a mail server! It's not a problem where you can just invest once and it is done but instead it is like one of those service games.
I like the idea of email as a paradigm for asynchronous workflows, and if you're doing business by email (as in CRM) it is useful. On the other hand today the email market is pretty tied up with the likes of Gmail and Outlook
I worked at Seagate in the early 2010s, and they made pretty intensive use of Lotus Notes across the company—-it was pretty dang cool to see how sophisticated/useful the internal applications were that non-“developers” created!
That's HCL Notes, now... https://en.wikipedia.org/wiki/HCL_Notes
Probably because they already had to support it. HCL won IT support contracts in many banks across Europe and probably elsewhere. I reckon many of those banks still use old IBM tech like mainframes and Notes (for email and internal apps). It's hard to support something when it's EOL and you don't have the source code.
I have the vague memory that it was a distributed reimplementation of PLATO Notes, which had otherwise similar capabilities but was born as a bug tracking system?
It was more of a message board. I mean, I guess you could use a message board as a bug tracking system, but most of the uses I saw were more groups of people planning things... graduation parties, keggers, jam sessions, etc.
Obligatory: https://www.dreamingincode.com/
I remember, when I was just starting, the founder of the company saying that if you tell him you're offering an 'engine' that's mostly saying you don't have an app. Of course, some successfully sell 'engines', but I think there's a basic truth that you need users to make your business work and make what you're building better and battle-hardened, and to get those users you usually have to be providing just what someone's looking for, and that often means making an app.
Some 'frameworks' or 'engines' budded off from work on a concrete problem, e.g. Django first for a specific CMS, Rails from Basecamp, Unreal Engine from Unreal the game. Work's not as much of an 'engine' as those are, but it's definitely turned out a big focus is on how customers can build their own stuff (both in the frontend and the data side) and integration. But for anyone to care about all that it has to be an app first!
Having a real product is a costly signal (i.e. a genuine one) that the developers are doing enough dogfooding.
I've also noticed this. Seems rare to find successful frameworks that were actually built out as a framework from the start.
See also the rule of three (repetitions before you extract a function, and clients before you extract a library)
This was previously phrased in startup advice as "start with a single vertical and generalize afterwards", "don't try to boil the ocean", etc. A lot of less-experienced entrepreneurs start with wanting to conquer all markets with their new paradigm, but the truth is you first need to capture specific segments/verticals or you'll be spread too thin.
Similarly, with a software solution, you need to make it integrate into an existing stack used in the market, or else build the layers to make it something that can fit neatly into a business's processes. E.g. if there's already an established market for engines or frameworks, then a business can use your conforming engine almost plug-and-play. Otherwise you have to build the app and UI layers on top to make it end-user-facing.
Once you've achieved some success in a vertical or layer (e.g. appointment bookings for salons), you can abstract the core solution/framework and start applying it to other verticals or build adapter layers to start attacking other layers (e.g. appointment bookings for everything).
I'd add my own piece of advice: try to avoid violent growth. Slapping an adapter on something is usually a kind of violent growth. An adapter might 100x your pool of potential users overnight, but it can also easily lead to situations where people depend on your product but have expectations that you are completely unaware of, thus blocking you off from the next tier of growth.
While I’m not quite sure what we’re talking about here in terms of platforms, I’ll mention a couple of personal and team server platforms that are subject to the Zombocom Problem and a couple that aren’t. WordPress, NextCloud, and OwnCloud try to be all you need and even though they have plugins they seem subject to the Zombocom problem, because stuff gets shoehorned into a particular app. On the other hand there is https://sandstorm.org/ and Dokku, which let you run an app and just give resources to them, so if you want to run a Trello clone you can just run the Trello clone.
Sandstorm had a clear goal of getting critical mass and changing personal servers forever and I think in many ways it was close.
WordPress is the exact example of the opposite of your point. WP started as the edge of a wedge. But contrary to the examples in TLA, it didn't become an everything platform deliberate and predetermined, but organical and messy.
It started as a "blogging tool" and only that - it still is to some extent in 2024: it still has traces of "blogs" in its DBA, code, templating and so on.
It was successfull exactly because of that focus. As opposed to Joomla! and Drupal and many others that never even made it. WordPress gained a "plugin system" but later than most others and far more limited. In the beginning plugins were really to customize your blog - but it was still very much a blog.
When blogging wasn't that popular anymore - relatively, it pivoted into more of a brochureware CMS by leveraging the plugin system, but core was very much still a blog. I can't recall how many requests I had from customers to "remove this confusing blog-thing, we don't use that don't we". It could not be removed.
Then, after a while, it became the everything CMS. Slowly and rediculously clumsy. It still is. It's far worse at "being a webshop" than almost all dedicated webshop software one can choose instead. It's rediculously inadequate for anything close to "social media" - or user-generated content (due to its depenance on- and design of- the caching, mostly).
So, WP may be some "everything platform" by popularity and common use. But it's both bad at this and never predetermined to be that.
I don't think WordPress is a good example at all. All sorts of weird stuff gets shoehorned into Excel (see the horrors of any prop trading firm). The point is: Excel is wildly successful, because before it was a platform, it was a solution to an important specific problem. Same with WordPress.
You're falling into the Zombocom trap when your initial value proposition is the same as Zombocom's.
Sandstorm's architecture is incredible, and I love it a lot.
In my opinion though, it did kinda fall into this. It was an extremely secure and well thought out way to run concurrent user web apps. But none of the apps there were better than the proprietary Google suite or equivalent, and for self hosters, the need to explicitly port the app vs the simpler but less secure and less integrated 'just run a docker container' meant it lost there too.
There's also some limitations on what the apps can do, for example, I don't think Sandstorm has a good story for searching and indexing the contents of grains, the way other services could.
I think the killer app idea at the time was hospitals or governments with strict regulations and it didn't land well enough.
I think NextCloud and OwnCloud are also bad examples, as in the beginning they started with the clear goal to replace Dropbox with a selfhosted alternative. Only later in live they become what they are now, so the original point still stands.
> Platforms have to start here too. Otherwise, they’re DOA.
Completely agree with this. The person who starts building the ultimate meta-framework or meta-API as step 1 is almost inevitably doomed to failure if they can't articulate a specific problem they solve better for their users.
I have taken this approach with personal projects as well. In the past, I divided up the functionality into a bunch of neatly-organized classes at the beginning and then implemented each one in separate files. Big mistake. Much better is to put it all into one, ugly file until the kinks are worked out and then organize it later, at least in my opinion. It’s also much better for working in a flow state so that I don’t have to switch between 8 different tabs.
So even for personal projects, what’s most important is the ugly MVP that does the thing. It’s only after that works that I clean it up.
> Much better is to put it all into one, ugly file until the kinks are worked out and then organize it later
IMO this defer-until-needed approach depends a bit on having better tooling to use whenever the rework happens. Stuff like languages with statically-checkable types, good "Find Usages" IDEs, tests that exercise the overall architecture, etc.
When you can't count on those things, a constant gradual approach is needed to compensate.
From the technical perspective, I see Amazon as a platform first design. They're not shy about it, they embraced it ("we so totally overengineered our infra we now can rent it!"). It's so zombocomey that you can use it to zombocomify your own shit.
We should still call it "overengineering" and not "insight". It was a risk and a compromise.
First they were a bookstore. The infrastructure came later.
I agree, but I also think "how people fail at X" is a biased frame, when X is a risky, high value, naivety prone goal.
"Building a platform" is such an X. A high risk/reward goal where lots of failure is expected.
Programming languages, operating systems, hypertext, www. The earliest versions may have been small and made for a specific need... but the generalization attempts came soon and excitable zombocon words came out of mouth.
So sure... targeting your new programming language to a specific use case is a strong starting strategy. But.. it's a programming language. A platform.
The whole information superhighway was a big zombocon in the 90s. That's why the parody resonated in the first place.
I'm not entirely convinced that general platformish ideas cannot succeed. They're just hard and tend to attract the naive because if the massive potential.
This is dead on.
I think most of us have had the issue with being told to "Write me a Facebook."
I've done exactly what the article talks about, except not for something that makes money. It's a free platform that Serves a fairly neglected demographic.
Starting small is key.
I always say "Success breeds success." I set humble goals, succeed, then raise the bar on the next one.
This is really good for mentoring folks, as well. Get them used to succeeding. It may start with stupidly simple stuff, but, before you know it, they are doing really complex stuff.
For those few who might don’t get the reference, is about the (legendary) site zombo.com
The very first element in TFA is a link to zombo.com.
I hadn't heard that term before. When I was in technical sales, we called it the "Tampon Sale" technique, based on an old joke:
Two little boys found a five dollar bill on the street and went to the store to spend it. The first little boy came up to his friend with his arms full of candy. His friend just had a box of tampons. "Why do you want that, instead of candy?" asked the first boy. "Look here" said the second boy. "If we buy this we can go swimming and hiking and horseback riding...."
We were trying to sell an engine and quickly learned that the Tampon Sale fails spectacularly. We had to pivot to vertical solutions.
So but how do we build software that can be anything without falling into the Zombocom trap? I believe that Bezos interview shows us exactly how.
[insert list here]
No offense, I'm from GenX, we were doing those things before Bezos came along in fact that was the norm. See VisiCalc one paragraph up for an example. Attempting to create markets for your product like with the Metaverse or blockchain solutions versus just creating products for an actual market that already exists is a relatively new phenomena in the industry. I don't know why we started doing this to begin with.
> I don't know why we started doing this to begin with.
Because Steve Jobs said:
> People don't know what they want until you show it to them.
and too many people wrongly believe that they are as smart as Steve Jobs.
The article doesn't claim Bezos originated the idea. It just uses his quote to explain his logic. In fact, the article goes on to mention VisiCalc immediately after.
To extrapolate further: trying to be all things to all people didn't originate with any particular generation, or even in the software business. Companies have been trying to please too many customers forever, only to either finally settle on the right demographic or fail.
Everyone thinks they’re a genius that can solve every problem and no one wants to sell books better.
More realistically, everyone knows the best you can get with your own little thing is bought out. That is not enough for many smart people’s ego.
>From the inside, it may feel like you’re spending a lot of time on theory. Product thinkers don’t like that. They want to think about the customer.
Oh, finally somebody said it, thanks to heaven! Template "product mindset" with only data-driven way and unshakeable faith in the sacred custdev turn as a curse for interesting products and caused a problem of mass creation stereotypical products an gray, dull, soulless startups with only marketing packaging. But this inside-way is a really like some lost components of the product magic.
This seems very similar to concept of Architecture Astronauts [0].
I am glad author is realizing this is bad! They state their goal is to build a system that is "pliable, re-shapable, open-ended, true to its materials as a universal machine" which is as close to zombocom as it gets.
[0] https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
It also describes the blockchain / Web3 / decentralization crowd. Sure, the technology is great, but if all you've built is a Twitter clone, why would anyone care to use it?
This is more or less how I was taught to approach VC investment when I switched from being an operator to an investor.
Understand the environment (market conditions, constraints, fundamental enabling technology, economics, the macro) both now and in the future. The undeniable deep currents.
Look for companies solving a relatively specific, significant, painful problem, particularly one that is a barrier to future success/riches from the developing market it enables/supports. E.g. DWDM telecoms hardware supported the explosion of the Internet. Something you can do some diligence on to figure out the real questions around it.
Once you have a list of companies/founders, look to see if a sub-group is emerging from the gaggle. Focus on those 2-3.
Finally, ask yourself "what is the google on the moon" [1] whiteboard for this company. Meaning, how big can this be, where can this go, what (in those days) could be their 2nd, 3rd, 4th product.
[1] https://www.theregister.com/2006/03/08/you_only_search_twice...
> It can be anything, but first it has to be something specific.
Spreadsheets definitely feel more like a platform. They aren't specific to what they started out on - they're very general purpose. The metaphor of "grid of numbers you can do stuff with" is extremely not-product-specific.
Spreadsheets were originally designed to mimic the paper spreadsheets accountants used.
Only with the addition of macro languages did they become do-everything platforms.
Classic hindsight/survivorship bias for me.
Bezo’s approach is sublime. It holds two seemingly irreconcilable insights in tension and transcends either lesser alternative:
Come on.
How dare they sully the Zombo.com name. Stop trying to make the phrase 'Zombocom problem' happen.
Unfortunately, the rarity of the super product means this tactic is useless.
Step 1. Be born with silver spoon in mouth
I don't know. The reality is just that most business ideas don't pan out. There were hundreds of well-funded efforts to build online retailers before Amazon happened. If you're well-off, it's obviously easier to try and try again, but you're still likely to fail.
I think the article is right in that if you don't have a clear business idea ("we're building a platform"), the odds are even worse. Except when they aren't, because in some niches, you actually have customers who want a platform. Cloud computing is an obvious example. It's just not the general case for consumer stuff.
Just because success is unlikely, we shouldn't try for it?
There are a lot of ideas that sound good. Far fewer that are good. Being able to tell the difference makes it much more likely that you're on a plausible path to success.
Another way to see the point is to remember that it is better to make something that a few people really want than that a lot of people would like a little bit. An app is more likely to fit that bill than a platform.