The best way to validate a product without launching it is to try and simulate what the experience would be like when it's fully populated with content and users.
Virtually every product development cycle goes through this timeline:
Day 1: This is going to be huge
Day 30: This is terrible. What were we thinking?
Day 90: Oh wait, this adjacent idea is actually the good one.
The only times where I've accelerated this timeline is when I have clarity of what users should see when it's launched. Something you thought might be interesting may not actually be that great in practice.
I was building a map-based app called Ants that showed you in real-time where crowds were forming in your area—so you could see where the hottest things were happening.
After building it, I realized that people clustered in the same places almost every day and it didn't provide any new information on the 2nd session.
All along I didn't need to build the app to get this insight. I could've populated a map with the data right onto a Figma file and anticipated this outcome much sooner.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I’d like to introduce you to Death Clock—an AI-powered longevity app that I’ve been advising for the last 6 months.
Health apps are notoriously difficult to grow: they are single-player utilities that resonate most with older audiences.
However, I worked with the founder @brentfranson and we did some simple things that made the experience social and drove the cost of acquisition down to pennies...
First, we renamed the app from the sleepy name Most Days to Death Clock. This not only created a hook that drove word-of-mouth—but it also got picked by mainstream press and their story was told nationwide.
Second, we needed a shareable moment that made the value proposition tangible to users. So we did something audacious:
We added a survey that predicted your death date—and projected what you would look like as you age.
This viscerally showcased the impact of changing your habits—and provided personalized content to tell others about the app.
There is a tendency for app designers to create layers & subgroups to deal with complexity:
Mastodon attempts this with usernames—which have 2 parts.
For every part of your app that you fragment, expect to increase your app’s overall probability of failure by 50%.
Users don’t have the patience to learn about the subworlds of your community. They are more motivated to churn than to understand.
Early products already have a limited inventory of content. When you fragment things, average engagement per post takes a hit, which is the key metric to track the health of your app.
Ladies and gentlemen, I’d like to introduce Nikita’s Shitposting Club—a collection of 69 Nikitas. Owners will get access to “Nikita’s app” (there is no app).
After 10 years of building consumer social apps, I've decided to start exploring new areas. Building these products is an unforgiving grind—but I learned a lot along the way.
For those embarking on this path, here's everything you need to know:
TIME FOR A THREAD 👇
A reproducible testing process is more valuable than any one idea. Innovate here first.
All things equal, a team with more shots at bat will win against a team with an audacious vision.
Most product ideas are Dead On Arrival because the conditions to derive value are impossible to orchestrate. Getting 7 adult friends to install an app on a reproducible basis is non-trivial. If you can figure out how to do that, that's a bigger idea than your original concept.