Product Stacking: why you should build products, not features

Mainstream stories of startup success tend to be boring and inaccurate. Hiding beyond the "crossed arms with slight smile" magazine cover photo with the catchy headline about the founder's newfound prestige and wealth is a much better question to ask: is there much wisdom gained by reading their story of success? Surprisingly, most of the time, I think the answer is no.

The problem of survivorship bias is rampant – in retrospect founders romanticize their early mornings, late nights, and ..🤢.. that single magical moment when they realized they had changed the world. It's hard to place blame on them though: it's hard to reshape this dynamic when you're getting asked by a journalist "so tell me about that moment when you realized you had changed the world."

Instead, I think more wisdom can be found studying smaller successes and the "non-romanticized" actions founders took to get there, whether intentional or unintentional. I'll be diving into many of the lessons learned from these actions in the future, but first, I want to look at the most apparent unintentional pattern I've spotted: "stacking" products.

Looking at new product sites like Product Hunt and IndieHackers, it appears that successful founders are spending less time revamping their products, instead choosing to break them into separate sites with smaller launches. Why?

The classic MVP strategy of "have an idea, build a V1, launch it to an audience and get feedback" has a significant flaw: the "V1" mental model forces us into a corner, thinking of one product instead of many. And when we start thinking about building a company with a single product, some things don't evolve as well as others. For example, pricing. How are we going to charge for this product?

Too many founders stick to their first pricing plan, even if there's evidence it's not working. It's a hard thing to get right. "When you first start out, pricing is more of an art than a science. You don't have enough customers to run A/B tests, every attempt goes out to 100%," Sarah Hum, founder of Canny, said in an article walking through the difficulties of her company's four price changes.

It's easier to remove or add a feature than it is to dealing with grandfathering in users and announcing that you're raising prices. And product. What features do we leave out for V1? There's nothing easy about building a stripped down product only to feel guilty charging for it. If we cave and make the product free, it's tough to charge for it later.

But what if, instead of dealing with 4 versions of a product, those features and price points evolved as separate products?

The V1 to V2 problems don't happen for founders following what I call the "stacked product strategy" - they have a lot more flexibility. For example, the story of Carrd, the seemingly overnight success in the drag + drop website builder space, is an inspirational tale of solo-founder AJ and how he built that business with a thoughtful UX and by implementing early feedback. But not enough attention is paid to the product he launched before it, a site called HTML5UP, that offered a variety of HTML5 templates he designed free of charge.

That site didn't make money directly, but it gained him a small audience and more importantly, served a market that was struggling to build a beautiful website quickly. The same problem that Carrd would solve in a more valuable way later on. Instead of making a V1 HTML5 and eventually turning it into a paid template site, AJ started from scratch after learning how to deliver more value to his audience. That's stacking, and it only works if you're building on the previous momentum solving a similar problem for the same market.

A stacked approach means that the products you launch are smaller, leaner, and more clear to users. While it also means more codebases to maintain, the benefit of separate launches seems to be working out very well for founders that unintentionally use this strategy. Take the example above. Imagine selling an HTML template site that also has a drag + drop builder feature if you want to use it? Users coming for the templates may give it a shot, but both messages get muddled. With separate sites, it's hard to beat the clarity of Carrd's UX, from the first click to your previewed site.

Having trouble breaking out of the MVP V1 mindset? It helps to start at the beginning: What is a "do-it-in-a-weekend" product you could release that still has value? And then if that works, what could the next product be that delivers even more value?

When I was running Code-Free Startup, students often came to me with their product ready to go. I heard a lot of pitches like "I want to build an on-demand business that only delivers the best tacos in my city." Let's take that idea through the traditional MVP approach, and then the stacked product approach.

Traditional:

• Talk to potential users about what problems they have that the app could solve
• Build an app that addresses the most fundamental problem, in this case picking 5 of the best vendors to deliver tacos in limited neighborhoods
• After building and setting up infrastructure, launch, and test the idea. Validate, and evolve based on feedback

Stacked:

• Study the market and find the most simple but still valuable product that can address the problem
• Build a quick "Best Tacos in SF" website that lists taco shop reviews and lets visitors upvote them
• Two weeks later, launch to an audience, and find out what needs taco fanatics have that are going unmet. Ex. "Uber Eats just doesn't focus enough on specialty toppings" could change the idea of the final app entirely
• Begin working on the next product in the stack

In the stacked approach, you'll notice that we haven't started building a full-fledged app yet because this is only the first product in the stack. But it's only been a few weeks instead of a few months, and the upside is hopefully a much more engaged audience. The core reason this works comes back to value: once you've delivered something useful, people will be more receptive to your questions and discovery process as you dig into the problem. The traditional approach of approaching strangers at a taco shop with your app sketched on a napkin will always yield lower quality results.

So that's the basic concept, but how can you apply it? Here are some examples of products you can stack in front of your next app idea:

• a curated website/spreadsheet that helps organize information around the problem you're trying to solve
• a 5-day email course, hosted on a landing page that gives valuable insight into the industry or even just shares what you've learned from researching the market
• a community site that brings together passionate folks in the market that are currently conversing on Twitter or a loosely organized subreddit.
• If your idea is a marketplace, you can build smaller products that focus on each side separately. Ex. A site for restaurants with resources showing how to streamline delivery, and a site for delivery carriers with resources explaining how to maximize delivery revenue.

Remember, only half the battle is delivering something of value. The other half is making sure that your product is actually "stacked" - it shares the same core audience, and is solving a similar problem to the app/sass product you ultimately want to build. The stacked strategy isn't the only way to reach traction, but by turning features into separate products, you can gain an engaged audience and benefit from multiple launches, rather than trying to scramble for excuses to call your product "2.0".