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 think like a great product leader.
This is the Product Thinking Podcast.
Here's your host, Melissa Perry.
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 dearmelissa.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.
I love these questions.
So let's dive in.
I'm excited to share that I'll be joining Product Weekend in New York City on November 14th, an incredible event powered by Localize.
In the last edition of May I had the chance to meet a few people from the Localize team and some of their clients, and it completely changed how I think about localization.
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.
Localize 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.
Head over to localizecom to learn more and check out their localization revenue report to understand more about how localization can help scale your business.
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?
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.
Now, if you didn't do that though, and 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 discrete features that you're talking about as an experiment and then plan to do a bigger solution later on.
So if we can achieve the goal and achieve value for the user through doing smaller, discrete features that launch value faster, That's good.
But you're going to want to 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 are we whack-a-moling some smaller problems that it's not going to solve it fully?
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?
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.
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?
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.
Multi-month projects with a big bang release, to me, need to be de-risked.
So you can do something where you're going to release a really big 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.
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.
It took a long time to build it, but we had de-rusted along the way.
We had already experimented with all of 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?
So again, when I look at this dilemma, you're gonna have to evaluate it on a couple of 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?
So think about that in the terms of goals.
And that's going to tell you whether or not that bigger solution piece is where you want to go after.
Or if you want to do more of these piecemeal features, always make sure you're keeping the customer goal there.
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-month thing with a third party.
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.
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 the Prada Kata.
Think through those steps there.
And that's going to tell you which one you should choose.
So I hope that helps.
Again, let me know what happens.
I'm curious.
I wanna know which one you choose and what's the right path for you.
And if you're listening to this and say hey, I think I have a question for Melissa, go to dearmelissacom.
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.
