From Jeff Bezos:

“I very frequently get the question: ‘What’s going to change in the next 10 years?’ And that is a very interesting question; it’s a very common one. I almost never get the question: ‘What’s not going to change in the next 10 years?’

And I submit to you that that second question is actually the more important of the two — because you can build a business strategy around the things that are stable in time … In our retail business, we know that customers want low prices, and I know that’s going to be true 10 years from now. They want fast delivery; they want vast selection.

It’s impossible to imagine a future 10 years from now where a customer comes up and says, ‘Jeff I love Amazon; I just wish the prices were a little higher,’ [or] ‘I love Amazon; I just wish you’d deliver a little more slowly.’ Impossible. […] When you have something that you know is true, even over the long term, you can afford to put a lot of energy into it.”

One of the mistakes we made early was building product aimed at a moving target. First we built what we thought they wanted. Then, we showed it to them. They weren’t as interested as we hoped, so we moved to another market segment that required more product changes. They needed more, so we build more product features.

We did not focus on what WILL NOT change.

Every great product needs a great foundation - code, infrastructure, institutional knowledge. Each of these things, if not set up properly at first, will require Herculean efforts to change down the road. What I failed to see is that there are components to every product that are needed - authentication, user registration, multi tenancy, background tasks, emails, notifications. They form the foundation for the home. Since we did a 30% effort on each of those things up front, now we have to revisit those pieces of the product after-the-fact.

We focused instead on the moving targets, front-end UX, back-end logic to drive the UX which ended up churning 4 or 5 times almost entirely. We scrapped Figma designs, we scrapped features, we scrapped entire 5+ page UI flows. Instead, we should have figured out exactly what people need while I was building out the rock solid foundation behind the scenes. We could put together decks, Figma mockups, and hardcoded UI’s to accomplish a lot of what was done with long engineering hours, all while I was building the unchanging components.

There is so much churn in the early phase of a product, that your $s are best spent in the areas that will not change - then use $ to provide thin UI shims to mock behavior to get feedback. The full implementation should be saved for when you have a trove of users waiting on your product. I mean, actually waiting, like unhappy it’s not in place. If they are passively waiting, they likely are more interested in the concept or in your sales pitch than the actual product.

Don’t forget - the most important thing you can do in the early phase of building is focus on what won’t change in your product, your business, or your project. You will find that you can defer many high effort tasks to a later date - don’t try to do the hardest work while the target is moving the fastest.