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?

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! 

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 

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.

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.

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.

#1: Trust. You have to earn it. It's all fun and games when there is "nothing to lose" and you're a small scrappy startup. But once you have paying customers, usage targets to hit, churn numbers to report on, and revenue numbers to hit, it starts to feel harder to launch. I've been through this transition as a startup turns into a real company and have found having the following things in place really helps:

1. Trust from the rest of the org that you are THE expert on your customers. I was fortunate to attend a workshop with Marty Cagan (SVPG), whose content - blogs and books- I can't recommend highly enough, and he said "Until you convince the company that you know more about the customers than anyone else, you won’t be taken seriously. And you will have no credibility with executives." This trust is the baseline for you to be able to take risks and for leadership to be willing to "trust the process".

2. Culture of experimentation: next up, frame your "embarrassing" launches as "experiments" (which, I would argue, every launch is an experiment) and report out on them as experiments. Make failure a thing: not a good thing, not a bad thing, but just a thing that you learn from. Have specific outcome targets and metrics and don't stop until you hit them. If you don't hit them with that first, embarrassing launch, then you iterate.

3. Process supporting iteration: this is related to the first two bullets because you can't truly experiment without being able to iterate, and you won't gain the trust of the company without them seeing you quickly iterate. I've done this well, and I've done this poorly.

   1. When I did it poorly: I was doing "feature based" roadmaps and work back in the day. This meant you "finished" a feature and moved onto the next. It was almost impossible to iterate on learnings from the feature because the team had moved on, AND they weren't measuring the success of the feature in terms of outcomes, but rather general performance. Don't do this! Marty Cagan has a fantastic article on this.

   2. When I've done it better: align your teams (and PMs) around outcomes. Tell them, very clearly, "launching this isn't a success, getting to the desired outcome is a success, and that may take a few iterations". Get your team really comfortable with creating MVPs that you can learn from, and then quickly iterate. And talk about it! Post in Slack: "we launched this, no one liked it, we changed it and now people like it", "we got feedback this wasn't working, we just shipped a change", "we watched user sessions and looked at the data and made this tweak", etc.

TL;DR; gain trust from the company leadership by demonstrating your deep customer knowledge and your ability to quickly respond to feedback and iterate on MVPs. Frame success around outcomes, not features.

I am a fan of this viewpoint too. Here are some ways you can implement this internally, even in a large organization.

Here are some ways I have gone about implementing these:

• We have developed a culture of experimentation. This helps us test ideas (small or large) quickly and easily. The idea is not to be perfect, but to test them early on and see if there is impact on core metrics.

• Set clear success metrics and OKR's; this will allow you to show progress towards the larger goal via small steps, making the journey measurable and impactful.

• Ongoing customer feedback and usability testing to measure early impact will help you sell the long term vision

• Develop a vision, but break it into phases. A phased approach helps you slowly guide your initiatives to the broader vision without building the whole thing upfront.

• Having Beta releases help test ideas in the market directly without having to wait for all features to be ready. This approach provides real-world insights without the prerequisite of every feature being fully developed, thereby facilitating a feedback loop that informs and improves subsequent iterations.