I subscribe to the Reed 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 

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.