Any day now.
There’s a popular flavor of work software that falls under the category of Product-Led Growth, or PLG. The key value prop of PLG apps is you don’t need a sales team—the product sells itself. A user can sign up, stroll right in, and start poking around. If they’re tech-savvy, they might invest their time and attention. If things go really well, they’ll invite in their colleagues. Eventually, the meter kicks in and they start paying you.
If you use business apps on the internet, you’ve undoubtedly come across the PLG model. Notion, Dropbox, Airtable, Monday.com, and countless others focus on growing their engaged user base. They relentlessly A/B test and streamline the onboarding experience to chase the big goal: Making certain that the value proposition is immediate and obvious. And it works! There are plenty of examples of PLG companies that have found incredible success.
But that path to growth is incredibly expensive. You need waves of people to come into the product to try it. It requires enormous spend on user acquisition (i.e., marketing). Once users do come in, you need some percentage to not only commit to your product, but to evangelize it to others. Once they do commit, retaining them is also challenging. Easy payment usually means easy payment cancellation. Plenty of customers notice that monthly invoice and find themselves asking what they’re paying for.
Users walk a mile and software walks an inch
A key underlying characteristic of PLG products is they are deep, complex, and rigid. They require you to define and shape the product you need within their vast world of features and capabilities. It’s that investment that leads to most of the attrition early on. The majority of people don’t want to learn a new tool—they just want to get their work done.
Enter the product evangelists—the ambassadors, if you will. They learn the product and enthusiastically educate—and oftentimes promote—the product to others. Evangelists are key to a PLG app’s success.
Meanwhile, the internal product teams orient their roadmaps to make sure just about any use case can be serviced as long as you cobble together the right features. The result, over time, is a vast feature set that is utterly overwhelming to the typical user, and a big team of people telling you it can solve every problem. Of course, it never seems to fit quite right. There’s always a handful of dangling requirements that never quite get there.
The future of software is…customized?
The internet, coupled with flexible production processes, has opened up a world of bespoke customized products. You can fill out a form and get your own customized shampoo, vitamins, and sneakers. You can even buy custom songs for your child.
The world seems to be producing bespoke stuff everywhere these days—except software. PLG software is vast, with piles of features and endless templates, but, as I mentioned before, it’s quite rigid. We know that customization is expensive and time-consuming, often requiring consultants. So we fill in the gaps with spreadsheets and…more PLG tools.
Custom software in a snap! (sort of)
With the AI revolution upon us, a new kind of software promise is being made: Just type the software you want into a prompt and get back exactly the software you need!
Does it work? Not exactly. Then again, just about everything you ask of AI returns a “not exactly” result. But it can be an accelerant—it might crush the first 65-75%. It’s helping all manner of professionals skip ugly, boring, painful steps. Take a look at this Reddit thread on building software with AI—one key takeaway is that it’s still pretty rough, but the other key takeaway is that software got shipped.
Which leads me to the three predictions that are guiding a lot of my thinking as our team builds Aboard:
First, all the talk about AI replacing programmers is very premature. In order to achieve the benefits of AI-assisted programming, you need people with more knowledge about software development, not less, in order to ship working, secure software. But a single person should also be able to ship much more good software than they could in the past, at a much higher level of quality and a higher velocity.
Second, and simultaneously: Non-software development businesses will get increasingly excited about a technology that could cut their development costs and still meet their needs. They won’t care about AI. They will care about costs, and will do what they can.
Third, PLG products are in a weakened position and they have hard choices to make. They’re supposed to be the one-stop shop for your software needs. But they actually end up being quite expensive—we recently met with a relatively small business that was paying $70,000 a year for Notion and no one really knew why. SaaS tools breed like bunnies inside of enterprises. Users defend them, but eventually IT and the CFO make people choose which ones to keep.
Now we’re entering a world of very quick-to-develop custom software, where adding features will be a kind of prompt engineering. We’re not there yet, but in a few years, it’s hard to imagine that AI-assisted coding won’t be part of basically every developer’s toolkit. Software creation is going to speed up a lot—and to what end?
What I think PLG tools with enterprise ambitions should do, starting today, is reconfigure themselves as software toolkits—to commoditize themselves, and become specialized SDKs. They should then build tooling on top of that, to let organizations “customize at the prompt.”
Organizations like the stability of vetted, useful software that accomplishes a goal, but they also want to solve their own problems—and increasingly, you’ll be competing with one or two developers armed with a programming environment hacking stuff together in a weekend. It’s very hard to market your more rigid, structured tool against that level of flexibility, especially when that flexibility isn’t just an empty promise, but can actually turn into working software.
Which leaves, of course, the question of who’s going to maintain all that new, AI-generated code—but, like the rest of the software industry, we can save that problem for later.