Episode 256: De-Risking Product Launches Effectively
In this episode, Melissa Perri discusses the common dilemma faced by product managers: whether to prioritize large, high-risk features or focus on delivering smaller, incremental updates. She delves into the considerations that should guide this decision, including the value to users, stakeholder goals, and the need for experimentation and risk management. Melissa shares insights on how to approach these decisions strategically to ensure both customer satisfaction and business success.
Are you grappling with how to balance big projects against smaller, faster releases in your product strategy? Tune in to this episode to gain valuable insights from Melissa on making the right choices for your product and organization.
You’ll hear us talk about:
02:29 - The Value of Incremental Releases
Melissa discusses the benefits of releasing smaller features incrementally, highlighting how they can provide immediate user value and inform future development decisions through feedback.
04:13 - Managing Risk in Long-Term Projects
Here, Melissa emphasizes the importance of de-risking multi-month projects with phased releases and feature flags, ensuring that stakeholders and users are aligned and informed throughout the process.
05:01 - Balancing Stakeholder and User Needs
Melissa explores the tension between meeting stakeholder goals and delivering user value, offering strategies for product managers to align these often competing priorities effectively.
Other Resources:
Follow/Subscribe Now:
Facebook | Instagram | LinkedIn
Episode Transcript:
[00:00:00] **PreRoll:** Creating great products isn't just about product managers and their day to day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you find your way.
[00:00:28] Think like a great product leader. This is the product thinking podcast. Here's your host, Melissa Perri.
[00:00:37] Melissa Perri: Hello and welcome to another episode of the Product Thinking Podcast. It is time for our dear Melissa this week, and that's the part of the show where you can ask me any of your product management questions, any of your leadership questions, anything. Whatever you think I can answer, go to dear melissa.com, let me know what's on your mind. We break it down into these bite-sized chunks where hopefully they help you and they can help others learn from your dilemmas. And today's dilemma is a little bit about how do we think about building the whole thing versus chunking it into smaller releases?
[00:01:09] I love these questions. So let's dive in.
[00:01:11] I'm excited to share that I'll be joining Product Weekend in New York City on November 14th, an incredible event powered by Lokalise. In the last edition in May, I had the chance to meet a few people from the Lokalise team and some of their clients, and it completely changed how I think about localization.
[00:01:26] It's not just about translation. It can be a real growth driver. In fact, some companies attribute up to half of their revenue growth to localization. Lokalise helps teams do this at scale with over 3000 companies using their AI powered localization platform to speed up translation, ensure quality, and deliver better experiences worldwide.
[00:01:46] Head over to Lokalise.com to learn more and check out their localization revenue report to understand more about how localization can help scale your business.
[00:01:55] Dear Melissa, I have an interesting dilemma I hope you can help with. The business I work for has a wide and diverse product roadmap, with the standard desire to go faster. We currently have the choice to either build a large high risk feature with third party dependencies and a multi-month cadence or a series of smaller discrete features which build momentum and success in the eyes of stakeholders. There is merit in both, and my team is divided as to which path to choose. What would be your take on this dilemma?
[00:02:24] I love these questions, so I'm usually always an advocate for getting value out faster in smaller chunks, but I will say, because you're saying there's merit in both, it's making me think about a conundrum that I do see a lot when it comes to these smaller experimental practices. And that always gets back into "where's the value for the user"? What are you trying to learn? So is the value for the user in the complete package? Let's say we already ran a bunch of experiments. We did a ton of research, we put some stuff out in smaller chunks already, and we proved that the users like it, it's awesome. They're, they're like totally gung-ho for this, but we need to wrap it around a consistent experience, right? We need the whole thing out there, and we can make a launch, we can train everybody on it. It might be high risk. Um, this situation there is telling me that you want to lend towards a complete solution.
[00:03:24] Now, if you didn't do that, though. You didn't do any experimentation yet. Let's say we didn't do a lot of research. Maybe we did some research, but we haven't really proven that these little pieces of value are the things that are gonna make a whole piece of value. That's where we might wanna treat those discreet features that you're talking about as an experiment and then plan to do a bigger solution later on.
[00:03:47] So if we can achieve the goal and achieve value for the user through doing smaller, discreet features that launch value faster, that's good. But you're gonna wanna think about: when does that break? Does it break? Does it actually deliver the full value for the user? Can they do the thing that they're trying to do with these smaller features? Or we whack-a-mole some smaller problems that is not gonna solve it fully?
[00:04:13] So think about that in retention and in acquisition and how we're thinking about that in the long term. Is it really going to solve that problem? Or do we need to solve that problem through a bigger release or a bigger solution plan.
[00:04:25] Now, if you can solve it through those smaller, discrete features, I would usually start with that. And then as it emerges, as you get more data, as you see people go through it and give you feedback, then think about how do we go back to the drawing board and turn this into a complete solution if we even need to.
[00:04:42] Maybe that works. Maybe all those discrete features works. Now, you said also that we're trying to get buy-in and get momentum from stakeholders, and I'm wondering if that's an internal stakeholder where you're trying to prove to them that we can actually release, or is it the customer? Who are you trying to achieve value for?
[00:05:01] Are we trying to use this project as a way to demonstrate to the company and to stakeholders that we can release things in small iterative chunks? If so, that's a different goal, but we can't lose sight of the goal of what is the value for the customer at the end of the day, because if that's what you're trying to show, that we can release things in small, measurable chunks and we can get things out that are valuable, you still need to achieve the value at the end of the day.
[00:05:27] Multi-month projects with a big bang release to me need to be de-risked. So you can do something where you are going to release a really big, um, product over a couple months, let's say. Let's say it takes a quarter to build, two quarters to build, and then we do a big splashy release. But what most companies are doing inside there is testing that and releasing behind, let's say feature flags, smaller discrete chunks before making a big splash with the whole product. So we used to do this in healthcare a lot. Imagine releasing a ton of features to doctors in the middle of them working with patients, right? Or having to train them on all these different features all the time.
[00:06:06] They get really mad. Nurses too, everybody, right? So what we would do is instead spend the couple months that we would do, building it, testing it, releasing it to a subset of users, getting them to opt into the experimentation, making sure that all that works, and then crafting a full solution there so that when the multi-month process was over, it was a big release.
[00:06:28] It took a long time to build it, but we had de-risked it along the way. We had already experimented with all those things. We had beta testers on it. We knew it was gonna work, so we weren't just flying blind doing this big waterfall release. We were actually testing it along the way. So are you thinking of it in that term, or are you just thinking about, can I solve things in piecemeal ways?
[00:06:50] So again, when I look at this dilemma, you're gonna have to evaluate it on a couple factors. What is the value you're trying to achieve for the customer? What are you trying to learn? What have you learned already? Is this the right next step to take? How much risk is there in releasing these things? Will you have to go back and actually do it again? Doing a full solution? What does it take to actually achieve the value?
[00:07:18] So think about that in the terms of goals, and that's gonna tell you whether or not that bigger solution piece is where you wanna go after, or if you wanna do more of these piecemeal features, always make sure you're keeping the customer goal there.
[00:07:30] It's okay to also approve to stakeholders. You can release, that's fine. Sometimes we have to do that. But maybe it's about scoping down the bigger multi, multi-month thing with a third party, and I don't know what that third party is. I don't know if they're building it for you or not. That would make me a little bit worried, but can we de-scope that, de-risk that in different ways? And are we using these discrete features as a way to de-risk that? So change the context maybe about what you're exploring. It's maybe not this versus that. It might be both, and you might go back and do that bigger solution later on, and that's totally fine.
[00:08:07] So what are we trying to learn? What do we already know? And what's the right next step to take? Go back to what I teach at Prada. Think through those steps there, and that's gonna tell you which one you should choose. So I hope that helps. Again, let me know what, what happens. I'm curious. I wanna know which one you choose and, and what's the right path for you.
[00:08:28] And if you're listening to this and say, Hey, I think I have a question from Melissa! Go to dear melissa.com, let me know what's on your mind, I answer them every single week. Make sure you like and subscribe to this podcast so that you never miss an episode, and we'll see you next time.
Should you ship the big comprehensive feature or release smaller pieces first?
I got this question recently from a PM facing a common dilemma: build a large, risky feature with third-party dependencies, or ship smaller discrete features to build momentum with stakeholders.
Here's what I told them: it's not about choosing sides. It's about understanding what creates value for your customers and what you need to learn.
The real question isn't "big vs. small." It's "what do we already know, and what's the right next step?"
If you've already validated that users want the complete solution through research and experimentation, then investing in the comprehensive approach makes sense. But if you haven't proven those individual pieces deliver value, treat the smaller features as experiments first.
Sometimes the discrete features can solve the customer problem entirely. Sometimes they can't, and you'll need the full solution later. The key is being honest about which scenario you're in.
I break down this framework in detail in this week's Dear Melissa episode. Check it out above or on your favorite podcast platform.
What's your approach when facing this choice? I'd love to hear how you think through these decisions.