Discover more from Business Brainstorms
The Algorithm, rebuilding GA3, a new drink for the productivity-chasing professional managerial class, R.I.P. Indie hacking
this is Jakob Greenfeld, author of the Business Brainstorms newsletter - every week I write this email to share the most interesting trends, frameworks, opportunities, and ideas with you.
Let's dive in!
“Huge startup opportunity to just literally rebuild GA3. Don't get creative, just 1:1 clone it.” - Danny Postma
“Someone should build an Airbnb for people who like to party.” - Andrew Ruiz
“Red Bull is worth 20B, Monster is worth 50B. Someone should build an energy drink brand for the productivity-chasing professional managerial class” - Will Robbins
“Someone should build the definitive content site for ConverKit
training and tutorials. Thinking about what @syedbalkhi did with WP Beginner there's a huge opportunity to catch the wave early. 50,000 customers, 500,000+ users. It's a big target market.” - Nathan Barry
🛠 Things Worth Checking Out
Senja makes it easy to increase conversion with social proof. In a nutshell: collect more video and text testimonials, share them to get visitors, sign ups and sales, more ways to share than anywhere else, free forever. Start collecting proof free.
Durable is the AI-powered website builder and platform that makes running a business easier than having a job. Create a fully functioning website in 30 seconds with AI. Then, use powerful AI tools to start marketing, book jobs, and get paid. Try it free for 90 days.
(all things above written in bold are sponsored ads, get yours here)
🪦 R.I.P. Indie hacking
For a few years, the indie hacker playbook worked wonderfully: “no customer interviews, just go straight to lean prototyping, launch fast, throw stuff at the wall and see what sticks, nuke it if it doesn't work and go on to the next project while broadcasting your journey publicly as marketing.”
Now, it has reached its expiration date.
Part of what made the indie hacker playbook effective is that only few people were doing it. There was a sense of community with people supporting each other and you could get attention simply by building in public and sharing revenue screenshots.
But as more people started doing the same things, the tactics became less and less effective. If you’re just starting out it’s nowadays 10x harder to drive meaningful traffic to a project from a ProductHunt launch, a personal blog, or “build in public” tweets.
It’s now quasi-impossible to validate new projects using these free traffic sources unless you already have an established audience.
To make matters worse, competition is tougher than ever. Without a sense of community, people are shamelessly copying each other. It’s not unusual now that multiple copycat projects start popping up just days after the initial launch. If you can launch fast, so can anyone else.
Where does this leave us?
Founders are back to building in private. Most indie projects have no meaningful moat, at least in the early days. It’s not smart to generate too much unwanted attention from other founders looking for business ideas and shamelessly copying projects.
Founders spend money to drive traffic and have to get more creative as simply casually posting updates on what you’re building is no longer sufficient.
Founders prioritize aggressive growth instead of growing slowly and steadily. If you know that your project inevitably will get copied, you have to make sure you’re growing faster than the others. You have to leverage your first-mover advantage and reinvest your profits into growth. And since there is constant fear that others will overtake you, founders try to get as much as they can out of their projects, as long as they last.
I love the excerpt below from the new Elon Musk biography by Walter Isaacson (h/t David Heinemeier Hansson, emphasize mine,).
A lot of it is 100% in line with the things I learned since I started my entrepreneurial journey.
For example, one of the most dangerous time wasters is building processes around and automating things that shouldn’t be done in the first place. It always makes sense to take a few steps first and ask: what are we really trying to achieve here? Is this necessary?
I also agree that one of the dumbest things companies do is have people manage other people who do not 100% understand what’s going on. At our agency, we’re trying to build a company where basically anyone can jump in for anyone else since they truly understand the processes and systems.
And another useful lesson is that finding people with the exact skills you’re looking for is borderline impossible. But finding people with the right attitude is not. And it’s much smarter to focus on that and then teach the skills required.
1. Question every requirement. Each should come with the name of the person who made it. You should never accept that a requirement came from a department, such as from "the legal department" or "the safety department." You need to know the name of the real person who made that requirement. Then you should question it, no matter how smart that person is. Requirements from smart people are the most dangerous, because people are less likely to question them. Always do so, even if the requirement came from me. Then make the requirements less dumb.
Delete any part or process you can. You may have to add them back later. In fact, if you do not end up adding back at least 10% of them, then you didn't delete enough.
Simplify and optimize. This should come after step two. A common mistake is to simplify and optimize a part or a process that should not exist.
Accelerate cycle time. Every process can be speeded up. But only do this after you have followed the first three steps. In the Tesla factory, I mistakenly spent a lot of time accelerating processes that I later realized should have been deleted.
Automate. That comes last. The big mistake in Nevada and at Fremont was that I began by trying to automate every step. We should have waited until all the requirements had been questioned, parts and processes deleted, and the bugs were shaken out.
The algorithm was sometimes accompanied by a few corollaries,
among them: All technical managers must have hands-on experience. For ex- ample, managers of software teams must spend at least 20% of their time coding. Solar roof managers must spend time on the roofs doing installations. Otherwise, they are like a cavalry leader who can't ride a horse or a general who can't use a sword. Comradery is dangerous. It makes it hard for people to challenge each other's work. There is a tendency to not want to throw a colleague under the bus. That needs to be avoided.
It's OK to be wrong. Just don't be confident and wrong.
Never ask your troops to do something you're not willing to do. Whenever there are problems to solve, don't just meet with your managers. Do a skip level, where you meet with the level right below your managers.
When hiring, look for people with the right attitude. Skills can be taught. Attitude changes require a brain transplant.
A maniacal sense of urgency is our operating principle.
The only rules are the ones dictated by the laws of physics. Every thing else is a recommendation.
As always, if you’re enjoying this report, I’d love it if you shared it with a friend or two. You can send them here to sign up.
Have a great week,