Instagram launched with three things: a photo filter, a share button, and a feed. No direct messages. No Stories. No Reels. No shopping. Just those three functions, wrapped in an interface that took under a minute to understand. Eighteen months later, Facebook bought it for one billion dollars with thirteen employees on staff. The product had barely grown. The user base had.
This pattern repeats so consistently across successful technology companies that it stops looking like coincidence. Uber launched with a single button that sent a black car to your location. Slack launched as a messaging tool with channels and file sharing, nothing more. Twitter launched without direct messages, lists, or trending topics. Airbnb launched with no payments, no reviews, and no host verification. You emailed the host yourself. The constraint, in each case, was not a limitation. It was the product.
Understanding why this works requires thinking carefully about what problems apps actually need to solve at the moment they enter the world, versus the problems they imagine they will need to solve eventually. Those are very different problems, and confusing them is one of the most expensive mistakes a product team can make. As we’ve covered previously, digital transformation projects fail 84% of the time because companies are solving the wrong problem, and the same logic applies at the product level from day one.
The Cognitive Load Problem Nobody Talks About
Here is what happens when a user opens an app for the first time. They are performing a rapid unconscious cost-benefit calculation. The question is not “can this app do what I need?” The question is “can I figure out what this app does before my patience runs out?” That window is brutally short. Research from Google’s UX team suggests users form a usability impression within 50 milliseconds of seeing an interface. The decision to stay or leave is mostly made before a single feature has been evaluated.
A three-function app answers that question immediately. The user understands the product because there is almost nothing to misunderstand. A twelve-function app forces the user to build a mental model of the system before they can use it, and most users will not do that work for an unproven product. Feature richness, at launch, is a tax on first impressions.
This is also why elite software teams use cognitive science principles to ship faster. Reducing cognitive surface area is not just good UX. It is a development velocity strategy. Every feature you do not build is a feature you do not have to test, document, maintain, or explain.
What “Core” Actually Means
The word “core” is doing a lot of work here and it is worth being precise about it. A core function is not just a feature the team finds important. It is a function that, if removed, would cause users to stop using the product entirely. That is a high bar, and most features do not clear it.
For Instagram, the filter was core because it solved the specific anxiety that kept people from sharing phone photos publicly (they looked bad). The share button was core because sharing was the entire point. The feed was core because it created a reason to return. Remove any one of those three and the product collapses. Everything else Instagram has built since, including stories, reels, shopping, and ads, is built on top of those three load-bearing functions.
The exercise of identifying your actual core functions is harder than it sounds. Teams consistently overestimate how many features are truly load-bearing versus nice-to-have. One useful test: if you removed this function, would users cancel or would they just be mildly annoyed? Mild annoyance is not load-bearing.
Why Teams Build Too Many Features Anyway
If the three-function strategy is this clearly effective, why do so many product teams ignore it? The answer has less to do with technical judgment and more to do with organizational psychology.
Features are easy to count. A roadmap with forty items looks more serious than one with three. Stakeholders feel reassured by scope. Investors ask about differentiation. Competitors announce features and teams feel pressure to respond. The result is what product managers privately call “feature soup,” a product where everything was added for a reason but the reasons have accumulated until the product no longer has a clear identity.
There is also a survivorship problem in how teams think about successful apps. When we look at Instagram or Slack today, we see feature-rich platforms. We are tempted to reverse-engineer their success onto their current state rather than their initial state. This is a significant analytical error. The billion-dollar exit or the hypergrowth inflection point almost always happened when these products were still simple.
This connects to a broader pattern in how successful startups think about scope and market. The willingness to deliberately choose markets that look too small is the same muscle as the willingness to deliberately ship products that look too simple. Constraint is the strategy, not the compromise.
The Expansion Model That Actually Works
Starting with three core functions does not mean staying at three. The point is to establish a stable foundation before building upward, and to add features only after you have real behavioral data about how users interact with what exists.
WhatsApp is a clean example of this discipline. For years, it refused to add features that every competitor was shipping. No stickers (then), no status updates (then), no payments (then). The product stayed close to its core: reliable messaging that worked on slow connections with low data usage. That focus built the trust and the install base that eventually made every subsequent feature addition land with hundreds of millions of already-engaged users rather than a still-skeptical audience.
The expansion sequence matters too. The best teams add features that deepen engagement with the core functions rather than adding parallel capabilities that pull user attention in new directions. Spotify added collaborative playlists before it added podcasts. The collaborative playlist deepened the social behavior already embedded in listening. Podcasts were a much larger category expansion, and Spotify waited until it had genuine leverage before making that move.
The Three-Function Audit
If you are working on a product right now, there is a practical exercise worth doing. List every feature your product has or every feature on your current roadmap. Then ask, for each one: if we removed this tomorrow, would users cancel their accounts within thirty days? Be honest. The features that survive that question are your actual core. Everything else is either enhancement or debt.
Most teams that do this exercise discover they have one or two genuine core functions, not three. Which means they are probably already shipping something that is more complex than it needs to be. Simplifying an existing product is harder than simplifying a new one, but the logic is the same. Users do not reward you for everything you built. They reward you for how quickly they could understand why it matters.
The billion-dollar apps did not succeed in spite of starting small. They succeeded because starting small forced them to get the one important thing exactly right before they complicated it.
