When is the best time to launch your product?

Market readiness is only assessable in hindsight. It’s either ready because there is adoption of an incumbent, or you can’t know whether it’s too early until you don’t see retention. Focus on shipping faster, sooner, lighter so you can learn quickly if your approach to the problem is fit for the market, or iterations are required. Often on zero to one you’ll also need to educate your market into becoming ready.

Product managers should assess market readiness by conducting thorough market research, validating product-market fit, talking to existing customers for insights and often prototyping to gather feedback from beta testers or early adopters. They should also analyze competitive landscapes, ensure product compliance with regulations, and have a well-defined go-to-market strategy in place. This comprehensive approach ensures that the product launch is timed right and aligned with customer needs and market dynamics. And you have a plan to make it go beyond launch and drive its successful adoption.

Before committing to building any product understanding the needs, wants and the challenges the total addressable market is faced is crucial. The initial discovery allows us to create, and measure the success of, tests such as the concierge test that both allow us to a) gather additional learnings that help us shape the future product b) get customer buy-in, usually via payment, that secures them as an interested party. This part of the work is never done. It's a flywheel that secure future product development as well as adjacent product discovery.

Launching a new product is like planning a party. You need to know who's coming (your target audience) to make sure you have what they like. If you invite kids, you won't serve coffee, right? Similarly, for a product, we need to understand who will use it and what they need. This helps us make a Minimum Viable Product (MVP), which is like a basic party setup. We can then add more features (or party games) based on feedback. So, understanding our product readiness ensures our 'party' is a hit!

My recommendation is to reduce the psychological weight of Product readiness. Those who build it are too emotional attached, leading to over emphasizing the importance of launching. Being able to guarantee the value is delivered, the product is reliable, and you can track whether users are using, or not and why not are the basis for launching.

Clearly define successful launch metrics to define readiness for a product to go to market and to customers. It should not be subjective but objective where key stakeholders can take a data driven and objective decision collectively. Often doing a closed loop beta or pilot testing with select customers also helps before going generally available to all.

Team readiness is significantly more important than product readiness, both the product and engineering readiness as the GTM team readiness. The product launch tends to be meaningless, but what you do post launch can make or break your odds of success. A team that is ready to execute on go to market, aligned on the iteration phases, and with expectations managed on what is possible and what is still coming, is a team that wins.

Deciding the launch strategy is a two-way door decision, even though it seems a one-way door decision. Launching a product is often larger and more impactful for the team and company due to proximity. The market is focused on their worries and their own product launches. Nonetheless, designing a launch according to your goals matters: beta, soft launch, pilot or general acceptance are typical approaches. Understand if you’re testing the waters or going all-in for growth and choose your strategy.

This is great for new products or MVP experiments, but can be challenging to get rich data insights. Unless it's a situation where you're forcing people into the funnel or had a previous sign up list to test on, don't overestimate a user's enthusiasm to try your product. Be careful when defining your population for these. I have gone way too narrow with these audiences in the past and you can sit there for days waiting for people to use the product. What do you learn from fewer than 50 or so customers using something? You need to get into triple digits to gather data you can be confident in, even in pre-mvp tests. It's better to err on the side of including too many people than too few.

Sample selection for your beta tester cohort is key to ensuring a successful soft launch. Ask yourself - why will they invest their time to do beta for you ? What is in it for them ? How will you time box this phase and collect feedback objectively from beta users ?

I'm partial to this strategy especially for new category or new to market products. For 0-1 products ... test, test, test. This will mitigate market readiness, product readiness and team readiness in a major way.

All launches tend to use principles of phased launches, as you want to aim to constantly iterate on each new build. Incorporating the feedback, market needs, strategic requirements and fixes are critical to keep launching new phases of value. This last concept should be the basis of phasing: identify what are blocks of value can truly move forward your market deployment, and phase it accordingly. Customers want needle moving value to retain to products. Your GTM team needs significant evolution to improve their conversion rates. Phase these additions of value.

Consider using an agile launch process when: Rapid Iteration is Vital: If your customers benefits from frequent updates and improvements based on user feedback, an agile approach allows for quick adjustments. Uncertainty or Innovation: In cases of high uncertainty or innovative products, an agile approach lets you learn from real-world usage and adapt accordingly. Even change direction after few iterations based on feedback. Competitive Pressure: When you need to beat competitors to market or respond swiftly to changing market conditions, agile can be more agile. But don't choose agile because of resource constraints or insufficient product readiness

This approach works best with mature products and most likely will be successful be cause the team-readiness infrastructure already exists and is running well.

A great insight into launching is Brian Chesky explanation on how Airbnb launched three times before actually succeeding in launching. A common mistake product builders (and founders) do when dealing with launching is burning the teams to achieve an artificial milestone. It will lead to exhaustion to support the iteration, which is way more important than the launch itself. Focus on the medium term instead of the short term and build a continuous launch machine.