Build pyramids, not rocketships

Hypergrowth is a thing we need to acknowledge. It’s been here for a while and it’s something that will not go away while there’s still billions of dollars being poured into the startup ecosystem. One thing I’ve started to experience is that as companies grow and scale their products, when successful, they can build a product that grows exponentially. As they start to rethink what that product can be, they need to rebuild what they’ve taken the time to put together and often it’s while the product is continuing to grow exponentially. It is assumed to be a part of the hypergrowth culture.

I am challenging that assumption.

In conversations with our design team, thinking about the future of our respective products and features we have on the platform, we have decided multiple times (!!) to rebuild something that already exists and is “working” but needs to be 1) tuned up 2) have a better UX or 3) make room for a new feature.

To me, this is the act of flying high on a rocket and choosing to get out while the ship is still propelling through the air and replace an engine or reapply the plating to the exterior. We’ve built this awesome thing (product and/or feature) that’s already flying with engagement/users/revenue and now we have to keep that going on its trajectory while we think about fundamentally altering the product at the same time.

This is not a wholly bad thing. Some products need to be torn down and rebuilt. Some products need to be fully redone for a variety of reasons, but I’ve been seeing this happen all too often at hypergrowth startups with the idea that “we are iterating on a feature.”

In product, iteration is great, it’s a necessity, if you’re not changing, you’re dying. If you’re not actively trying to not only beat the competition, but create a product no competition can match, your product becomes unkillable. But the above description is not iteration, it’s recreation.

Iteration should happen, in my view, more in the form of a pyramid. Starting with the base and working its way up from there. You could say skyscraper or other large object firmly planted to the ground, but building a pyramid also implies timelessness – building a pyramid is the act of building something that, when conceived, will stand the test of time. It it a principle part of the platform you are working in and it all starts at the base.

When thinking of an MVP or thinking of any feature or product, the core of it is what I would call its base. “What is the core problem we are trying to solve?” “What is fundamentally wrong with our users’ experience today?” These questions should shape how we begin to think about the product(s) we’re building and from there, we can start to decide what a product strategy for this pyramid might look like:

• Platform impact: How big is this pyramid going to be?
• Lifetime: Do we think it’ll need to be ripped out of the ground for any reason?
• Redundancy: Are we actively planning other pyramids to serve the same purpose?
• Core of the problem: Is this pyramid able to be built on solid ground or is there an even more fundamental problem with the foundation?
• Understanding the problem area: How do we know this pyramid is the right pyramid to build?
• MVP: What might the base of the pyramid look like?
• Final goal: What does it look like for the pyramid to have achieved its full height?
• Product roadmap: What could the steps to get to the final form of the pyramid look like?

Answering the above questions are how you achieve a product that may not need to be rebuilt when it’s in its final stage, but can instead account for what the final stage might look like and adjust because its base can support it.

What if I misjudge the base? What if I build the first few levels of the pyramid and realize it’s not going to go any higher? Even that should be fine – an unfinished pyramid would be built in such a way that there wouldn’t be a risk of destroying everything you’ve built, if you need to build another base somewhere else. Or if the base needs to be extended, you can start to think about where you might be able to further strengthen the base you’ve built and build on top of it.

I might’ve ventured too deep into analogy territory, so let me bring it back to reality:

Building a product requires a strong fundamental understanding of the core problem and problem area, what a minimum viable product could be, what the final form of this product could be, and how you might handle the changes in situation (lifetime expectancy, redundancy) all with the intent of achieving the goals set out by and for the company and the users.

We start with a strong base and build up from there, not from a rocket ship that has no base and no plan for changes besides rebuilding it midflight.

I know the format of this is a strawman and there are many holes to poke, but I’m of the mind that a strong base is the platform on which anyone or anything can grow. See building a base before training for a marathon, see the expansion of amazon from a high efficiency bookseller to a platform for everything.