Demo Iteration.

Today we’re talking about how to iterate on your MVP — Minimum Viable Product.

1. Don’t rush to build, or you will have to build twice. Use demo and no-code tools to test with customers before trying to deploy a full application.

2. Expect your early versions to break in unexpected ways. Often it’s even a struggle to get testers accessing basic functionality. Don’t get discouraged. This is part of the process. You need to keep testing with customers.

3. Don’t add more features. Bug fixes and a buttery smooth onboarding process are usually much more important than new features. This early, you really only need one feature.

Best of luck out there.

Today we’re talking about how to get feedback on your MVP without building very much at all.

1. Even if you are good at building apps, waiting until you have some idea of what customers want will prevent you having to rebuild the app multiple times.

2. Screenshots, animations, and no code tools are enough to get your first rounds of feedback. Oftentimes you can build complete applications in these environments. If you add in example data from the customer, it will be almost as convincing as a working app.

3. Once you have a workflow that customers like, something that they are asking to use for real, then you can build out a basic, working version. You can also ask the most excited customers if they want to pay upfront to be the first in line — generating sales before you build.

Best of luck out there.

Today we’re talking about how your MVP will break in expected ways.

1. Your MVP is not supposed to be a stable, final version; so don’t be surprised when it breaks in all sorts of different ways. From basic stuff like emails not being received to complex database issues — you’re going to see it all. And that’s exactly what we need.

2. Now, it’s often tough to receive this feedback from your first customers, who are usually having a pretty tough time with your bad attempt at a working version. But don’t get discouraged. You must stay committed to customer testing in order for things to improve.

3. I suggest setting a regular schedule for new versions to be deployed at least every few days, along with beta customer check-ins, to ensure you’re both iterating and receiving feedback regularly.

Best of luck out there.

Today we’re talking about why you shouldn’t add features to your MVP.

1. This early on, we need to focus on testing just one feature to understand if it’s enough for customers to choose you. One feature not many.

2. Although new features are tempting and exciting to build, bug fixes and a very smooth onboarding process are usually much more important for customer satisfaction.

3. If your current feature isn’t working out. It’s totally fine to shut down the test and try another different feature. But don’t try to test 2 or 3 core features at the same time.

Best of luck out there.