To launch or not to launch?

Pre-internet, you had to build physical products and find the right gatekeepers. If you’re an upstart, you typically had one chance to shoot your shot.

Now, you can develop digital products, learn from feedback, and make it better everyday. In an environment where you have has many shots as capital affords, the skill of designing a minimum viable product (MVP) for fast feedback loops is a real competitive advantage.

It’s also created a tension between wanting to be proud of what you release into the world vs. learning quickly. A modern dilemma in building products is the perennial question: is this ready to launch, or not?

Here are some lessons on striking the delicate balance that I wish I learned earlier.
‍

Real meaning of “minimum” and “viable”

The first two letters of MVP is commonly interpreted as fewer jobs done well. But a job goes beyond just functionality. A product is a muti-layered cake that starts with users and leads into functionality, reliability, usability and delight.

When you carve out an MVP, you deliberately choose to focus on a subset of users, which in turn enables you to cut a smaller slice of the layers above. By anchoring on someone else’s problem, you get two important things in return:

1. A focused feature set that still has the power to build trust and be delightful
2. A path to shedding your own pride and biases

Everything that’s become big started small. Amazon started with book buyers and sellers before it became the everything store. Facebook started with college students at Harvard before it became the town square of the world. Apple started with rebels and hackers before it became the ultimate luxury tech brand.
‍

Line of expectations

Where do you draw the line on expectations? This is a two-sided equation. First, you talk to customers to identify what they care about most. Second, you figure out what you need to prove to make a go/no-go decision on investing beyond the MVP.

When we launched a mobile app to supplement our web experience, we only focused on building the core flows that our most loyal users needed.

We axed sign-up, onboarding, and even checking orders and invoices because the most pressing opportunity was allowing users to easily browse and buy on-the-go. The go/no-go decision was based on whether we could beat mobile web conversion through a slicker app experience.

We doubled it upon launch. By constraining the two-sided expectations, we were able to get a better product in the hands of users a month earlier.
‍

When to overbuild

The MVP philosophy errs on the side of underbuilding, but there are exceptions to the rule. When we explored the value of showing our users an insights dashboard about their businesses, we faced two challenges:

1. The industry is known for being more intuition-driven than data-informed, so we were looking to reverse a longtime default
2. We were novices to the industry and weren’t certain about the most important insights to expose, even though we had strong conviction in the overall value

Rather than artificially limit the possibilities, we included more insights than would normally pass the bar. To do this, our engineer found a clever way to embed the SQL dashboard into our core product, saving weeks of development time. By demoing the full feature set with retailers, we were able to quickly learn what was a hit vs. a miss, calibrating our own instincts along the way.

There are moments, albeit rare, to overbuild, but I only recommend doing it if you can find a cheap route. You will end up making a lot of changes, and you don’t want to fall prey to the IKEA effect.
‍

Overcoming the last mile

The devil is always in the details, and there’s never a shortage of details that can trip up a product launch. It’s easy to fall into the perfectionist trap and refuse to ship until every last pixel is built to spec. Steve Jobs was notorious for this. But the beauty of software products is that you can always touch up a blemish, often before people even notice.

Although it’s important culturally to uphold a high bar for quality, at the last mile, you should ask: will this change the outcome of what we want to learn? If it doesn’t, the fixes are better made as fast-follows. This keeps your velocity high, and also ensures you don’t create a product marred with papercuts.
‍

Trap of the big release

Shipping regular updates is boring. Every so often, we get swept up by the allure of a big release for a fancy new product. This is a trap.

By keeping everything you’re building hidden behind a big launch date, you run into three issues:

1. Loss of time to validate and learn
2. Undue pressure for demand on launch day
3. Belief that users who don’t know what you’re making will bestow significance on launch day

Big releases are designed for hardware products, not software. This was a lesson that Quibi should’ve understood before taking 2 years to build an MVP after raising nearly $2B. Had they released earlier even to a smaller group of users, they would’ve had a chance to correct for their many missteps outside of the unforgiving spotlight.

One of the great gifts of the internet is the opportunity to test & learn anything. It’s massively compressed our learning cycle and accelerated progress on all fronts, both positive and negative. Crafting and distributing something addictive for the masses is easier than ever. At the same time, access to knowledge has never been more democratic.

The internet is an amoral tool— what we create with it is up to us. Learning how to build things is this era’s new literacy, the prerequisite to contributing to the future. Making the right call on what to launch is Day 1 of what will be a wild ride.