I subscribe to the Ried Hoffman quote - “If You're Not Embarrassed By The First Version Of Your Product, You’ve Launched Too Late.” How do you actually live this out in a larger company where there is internal anxiety?

Great question!

My response to "At what point is a solution ready to be shipped?" applies here. 

The aspect of launching a true MVP is harder in a large organization, when the expectations from the customers are high and I think rightly so as the stakes are maybe much higher. 

In my experience, what helps calm the nerves is to play out the outcomes with the team:

• What is the worst case scenario? 
• Asking why is this not acceptable and thinking through ROI, opportunity or sunk cost on doing more, waiting further out, could help build a case. 
• Experiementation path and mitigation plan 

Great question! I do agree with Reid's quote, that said I do think your first version should still be "valuable" so then you know whether it will really solve the problem. Regarding how to get buy-in from stakeholders in large companies, think about what they care about and frame what you are doing accordingly. Bring customer quotes and audio/video clips on why you are trying this out and propose this as an experiment you are trying to run. Start small so that you are not impacting every customer and once you have build conviction, go solve for more. Be creative about how you get those customers, sometimes it could be that you don't target the same customers but run it in a more controlled environment. Sometimes we get too worried about what our stakeholders will say and hence we never try it. I am a big believer in asking for forgiveness instead of permission. 

Ask your leadership/marketing team what gives them anxiety and then attack those points as part of your 1st launch. For e.g. if they are worried about bad PR then ask them how small a group are they comfortable launching to and then stick to a rollout number below that. Over time you will build the muscle.

Reed Hoffman's quote is a reminder that it's important to get a product to market quickly, even if it's not perfect, in order to gather feedback and iterate based on that feedback. Mark Zuckerberg championed "Move fast and break things" at Facebook which is similar philosophy as well. However, in a larger company, there can be internal anxiety and pressure to release a polished product, which can make it difficult to live out this quote.

Here are some ways to navigate this tension and live out this philosophy in a larger company:

1. Set expectations: Make it clear to stakeholders that the initial release of the product will not be perfect, but that it's important to get it to market quickly in order to gather feedback and iterate. Set clear expectations around the level of polish and functionality that will be included in the initial release. You can strike a balance by releasing the product as a tech preview/beta.

2. Start small: Instead of trying to release a fully-featured product all at once, consider starting with a minimal viable product (MVP) that addresses the core problem and can be released quickly. This can help mitigate anxiety and pressure around releasing a polished product.

3. Test and iterate: Make sure there are processes in place to gather feedback from users and to iterate on the product based on that feedback. This can help demonstrate that the initial release is just the beginning of the product development process and that there will be ongoing improvements and iterations based on user feedback.

4. Emphasize speed to market: Highlight the benefits of getting the product to market quickly, such as gaining a competitive advantage or capturing market share. This can help shift the focus away from internal anxiety around releasing a polished product and towards the benefits of speed to market.

Ultimately, living out Reed Hoffman's quote in a larger company requires a balance between the need to release a polished product and the need to get the product to market quickly in order to gather feedback and iterate. By setting expectations, starting small, testing and iterating, and emphasizing speed to market, it's possible to navigate this tension and release an initial version of the product that can be improved upon based on user feedback.

I think the quote has validity in some contexts and less in others. If you are building a 0-to-1 product in a company where the culture is anxious about, say, the brand impression your "embarrassing MVP" may invoke, that may be a fear you need to help alleviate as a PM. However, there are other contexts (eg. in financial products, healthcare tech, fortune-100 enterprise products) where an "embarrassing" MVP may actually compromise your ability to successfully validate the hypothesis of your MVP; for example, if the end-user highly values security, polish or simply need to trust the product to meet the unmet need, you may need to go a bit beyond "embarrassing" in your minimally-viable solution.

So much about product management is about stakeholder management — getting everyone from engineers to exec team aligned on 1) what you are building and 2) what the goal is. With goals, we're very good at getting folks excited about the metrics-based goals ("we'll move conversion rate by 2 percent" or "sessions per month will increase by 10%") but I've found that it can be super helpful to align on what the goal is of launching something as well. 

At Quizlet, we've been very deliberate about defining (before we launch!) if the goal of our launch is to get signal on a problem space, optmize a product to move metrics, or if it's a longer term investment. Making those distinctions up front and getting everyone aligned on them is super helpful. 

For example, you may have high conviction on the problem, but you aren't quite sure if your solution is the right one. Launching a test of your product to get signal can give you confidence that you're on the right track, or give you enough data to go back to the drawing board and ID where your hypothesis wasn't quite right. Often those signal tests might be a little more on the Reed Hoffman embarassing side, and that's ok! If your stakeholders are anxious, getting them aligned that the launch is about getting learnings and de-risking the project should help! 

First, while I understand the sentiment, I never want to be embarresed by any version of the product my teams launch. I prefer to subscribe to the saying "perfect is the enemy of good enough". The point really is, you need to get early versions of your product that are usable in the hands of users quickly, so you can get real world user feedback in order to know what needs to be fixed/enhanced/perfected to gain user adoption and growth.

If you spend too long iterating internally on the product or feature without real user feedback, chances are high that you and your team are wasting time iterating on the wrong things from your buyer's and user's perspective, which is dangerous when bringing new products to market.

However, as a PM, it is important for you to understand the incentives of the company/business within which you are running your product. For large companies, the main focus is on reducing business and user risk, so the idea of releasing products that may not meet the highest QA standards is met with resistance, as expected. 

In that case, I recommend using version labels such as "EAP", "Alpha", "Beta", "GA" etc. to set expectations both internally and externally that this is an early verion of the product, *and* that the product will be refined based on user feedback. I've found success with this approach when launching early versions of products and features in larger companies.