Creating and Redeveloping a Product
In this Dear Melissa segment, Melissa Perri answers subscribers’ questions about how to stay on top of what is going on in a scaling team when you are the product leader, how R&D differs from product management, as well as how you can transition from a consultancy into a product company.
Show Notes
In this Dear Melissa segment, Melissa Perri answers subscribers’ questions about developing the strategy for a new product, managing legacy products when you are a product owner, and redeveloping an existing product.
Episode Transcript
Melissa Perri: 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. Today on Dear Melissa, I have three questions for you. One about product-cada and how do we develop product strategy for a new product inside of a scale-up company.
Another one about managing legacy products when you're a product owner. And then lastly, we've got one about redeveloping an existing product and making it our own.
Melissa Perri: So I just want to remind you that if you have any questions for me, you can submit them to DearMelissa.com. I look at these questions every other week and then I answer them for you. So it's the best way to get in touch with me and ask me any of your burning questions. Also, I have some very exciting news.
We have a YouTube channel now. So we have started to put all of our podcasts and our videos with our guests and also for Dear Melissa up on YouTube. It's under the Product Institute channel. So if you go there, you will find all of our podcasts. We are starting to put more and more backlog up there.
But if YouTube is your thing, do not worry. We've got you covered now. All right. So let's dive in for this week. First question is coming straight from a voicemail. Hi, Madison. Here from Barcelona. My name is Pedro and I am the product manager of a scale up here in which we're going to be launching a new product in just a few weeks.
And I was wondering a lot on how to develop the framework of a good product strategy, which is going to be the target condition.
Melissa Perri: You do not have data because at the end we have done some discovery. We're using a solution that has been validated in the Swedish market. But any data I try to put in my product data, which is going to be the target condition or the key metric I need to move in order to reach the number of subscribers that would make my business profitable.
It's just a guess. I'm wondering if you have any recommendation for getting something rolling when you don't have clear data yet. All right. Great question. So you have an interesting situation because you're inside of an existing company, it says. So you're a scale up company and you're developing a new product and you can use the product for this.
But your goals are going to be a little bit different because it's true. You don't have any data. So what are you supposed to do when you don't have any data on a new product? This is true for all startups, all new products.
Melissa Perri: We don't have any quantitative data because we're not actually getting any usage data on there yet. So we can actually look at that. But we can still set goals. And for any new products or any new startup, the first goal is usually going to be adoption or acquisition. So adoption, if you are selling that product with other products, let's say it's part of a platform, or acquisition if you're trying to cross sell it or sell it for a different monetary value.
Let's say maybe they don't go perfectly together or you're acquiring people in a new market. You did mention something about already validating in Sweden. I don't know if that means that you're expanding to Spain. But in this case, maybe you want to look at acquisition. So adoption and acquisition are leading indicators that you're going to start making more money, which is that overall goal in our product strategy that we talk about.
So if you've heard me talk before, when I talk about product strategy, there are several layers that we actually look at. We look at the company vision and the company strategy set with strategic intents. So where does the company want to go?
Melissa Perri: And those strategic intents are usually around making more money, expanding geographically, going into new countries, right? How do we make more money? So how do we grow? Also, how do we cut costs would also be in there as well. But these are high level. And those goals are usually extremely business focused.
And they're not like, hey, build this new product. They're more like, let's expand geographically to expand our team or whatever it is. So you're really looking at those type of levels for your top company strategy. Now let's go a level deeper because that's where you're sitting now with your new product.
Now we look at our product strategy and we look at our product initiatives. And that might be about solving problems or bringing new problems into that space. So maybe you're developing this product to launch it in the new geography. Let's say you already validated in Sweden. You want to make sure it works in Spain, hopefully.
We've got a bunch of discovery work there. Now we want to launch. So this product initiative and the goals around this are really going to be about understanding those people's problems in Spain and seeing if they're applied to this product.
Melissa Perri: Do we have the same problems in Sweden as Spain? And then you also want to look at goals that are around adoption and acquisition. So adoption and acquisition leading indicators to you making more money. Yay. In that case, we need to start measuring now on a smaller level. Are people actually using the product?
And when you're going through a discovery phase, obviously we're not really looking for that. You can use the product Kata and set that target condition, which I do now call option goals. I just like it better than target condition. Target condition is a Kata word and people got really confused with that.
So I renamed it option goal. That's your solution, right? So now you want to make sure that people are actually using that when you're doing discovery on it, though. Your goals are going to be about proving hypotheses and getting more information. So it's do people like this? Do we understand their problems?
To be able to set a goal for usage, to be able to set the goal to get people on it. So when you're setting that goal, it's going to be like you want to calculate how many people over a certain amount of time you want to get on that new product.
Melissa Perri: That's a really good leading indicator to you reaching your revenue goals. So it needs to start at the top. So your company has to say something like, we believe that by launching this new product, we are going to get an additional 30 million dollars. We can capture an additional 30 million dollars in three years, something like that.
Whatever yours is, just translate it down. OK, how do we show that we're on the right track for that? At the beginning of launching a product, you're not going to make 30 million dollars immediately. It takes time to ramp that up. So now we want to break that down a little bit further and say, how many people do we have to adopt or acquire over the next certain amount of time?
To be on our way to reaching 30 million, right? What's something good that tells us we have a good leading indicator there? What's a good number? And I will say this is probably not hard and fast. There's no set rules about what that's going to look like. You're going to basically have to crunch a bunch of numbers in an Excel sheet and model out good growth numbers versus bad growth numbers and see where you fit.
And that's going to give you an amount of people that you want to see using your product over, let's say, the next six months.
Melissa Perri: But on day one, you're not going to be able to measure that. So what you want to do is get that qualitative information first to show you that you're well on your way to quantitative information. Your option goal will always be the usage. And you want to set that for I want to see X amount of people using this within, I don't know, let's say, three months or something like that.
But what you're going to be doing to make sure that you're on that route is by doing user research, by sitting with your customers closely, by getting feedback from them and watching them actually use the product. That's going to tell you, do they like it? Are they happy with it? Do they actually have problems with it?
Is it solving their problem? And that qualitative information is going to be a really good piece of feedback to show you that you're moving towards that quantitative piece of information. So you want to make sure you're instrumented well for usage. That's number one, so that you can actually track that over time.
But two, you got to go out there in the field. You got to sit with your customers. You got to watch them use it. You got to get their feedback. And this is going to be a lot of qualitative information. But you're going to be able to say pretty quickly by doing this, yes, we're on the right path or no, we're not on the right path.
Melissa Perri: And then you're going to want to see how that grows over time to see if you can get to those overall business goals and get to your profitability. It's not a super cut and dry, easy thing to do during product launch. I'm so sorry, but that's just how it is. But it's going to take a lot of qualitative information to make sure you get to that quantitative information one day.
Once you get people on it and you start tracking it, now we can start to set a more firm option goal about the percentage of people we want to bring on or we want to see usage increase, that type of thing. But all of these will track back up to help be leading indicators to your money. You will never know immediately on launch if this will work.
That's the nature of startups. That's the nature of new products, right? That's OK. But if you're getting feedback quickly and you're staying with that qualitative piece of information from your customers, like you're sitting with them, you're listening to them, you're hearing it, it's going to tell you if you're on the right path.
And you're going to hear that faster than from waiting for numbers to show up on a dashboard. So make sure you're always talking to your users.
Melissa Perri: And I hope that helps. Facilitation is a skill I see as a fundamental difference between good and great product managers. Yet, it's often overlooked. Great product managers focus on guiding clear conversations and steering stakeholders to the best outcomes. You can develop these facilitation superpowers in Voltage Control's Facilitation Certification Program.
Ready to unlock your greatness? Apply today at VoltageControl.com slash product. Did you know I have a course for product managers that you could take? It's called Product Institute. Over the past seven years, I've been working with individuals, teams, and companies to upscale their product chops through my fully online school.
We have an ever-growing list of courses to help you work through your current product dilemma. Visit productinstitute.com and learn to think like a great product manager. Use code THINKING to save $200 at checkout on our premier course, Product Management Foundations. All right, we're going to our second question.
Melissa Perri: Dear Melissa, I will be taking over a part of the product that has been existing for a long time but hasn't had dedicated focus in recent years. The code is super old, no one really knows much about the functionalities, and documentation is rare. At the same time, most of our customers use it, and all of a sudden, management has realized that it should be a top priority.
Any tips on how to tackle this? This is always fun. I've been in this situation, too, where you go and you have to pick up a whole legacy product that was built like 10, 15, 20 years ago. Sometimes not even the language that anybody codes in anymore, which is always great. So in this situation, one, you need a lead developer to sit with you and piece through this thing.
Two, you should start from the beginning and go back and try to diagnose this product and figure out, what did we build it for? So maybe beyond functionality, go talk to people who have been there for a long time and say, hey, what was this product used for? What was our hypothesis when we actually built it?
See what you can get. I know it might not be much because it sounds like nothing was documented, a lot of turnover, that always happens, but see what you can get.
Melissa Perri: Two, go to the customers and look at how they're actually using it. So this is the big piece, right? Do tons of usability testing, do tons of customer discovery interviews. Find out what they use it for, find out what's working, find out what's not working. In these instances, you actually might have a chance to revamp this product.
You might find that 15 years ago, you built something that worked for customers, but they have new problems now. And there's an opportunity for you to get creative with this and actually make it 10 times better because of new technology. Don't be afraid of that, right? Go out there, talk to the customers, watch what they do with it, ask them why they continue using it, how it works into the workflow, figure out what step of their workflow they actually use this in, and then incorporate that into what you decide to do with the product.
Then you're going to really paint this product vision and see, is it still adequate or is there stuff that we need to change for this product? So I'd start from that perspective. And then by watching people, you are also going to discover the functionality, right?
Melissa Perri: You're going to see what they actually use it for. Then dive into the code with the developers. Look at it yourself. Is there extra stuff in this legacy product that's making it bloated and unusable and nobody's actually using those pieces? If so, that's an opportunity for you to scope that back and really concentrate on the core.
There might be an opportunity for you to revamp the UX. There might be an opportunity for you to re-architect it or put it into more of a modern type code base where you can do something fun with it on top with the UX or revamp that and do a bigger launch. Say, hey, we made this better for you. But the biggest thing is really start with your customers and understand what they're using it for because that's going to give you a really good insight into what the functionality is, how people thought they were using it.
And then you got to go piece through the back end. And the back end might be crazy and it might be really big. I don't know if this is a core product. I don't know if it's really intertwined with this stuff. But that's where you really need to work with your developer and figure out is our technology up snuff on this?
Melissa Perri: Do we actually have to do something creative with this? How much tech do we have? But paint your vision from a perspective of what the users would like to do with it. And that's going to open you up a lot of opportunities. All right. Last question. Dear Melissa, as a product owner, how can I handle the redevelopment of an existing product?
The reason for doing the redevelopment is because the existing product has been developed by a third party who now is getting into our business and the process isn't fully known to anybody. So this sounds like you're rebuilding the wheel, which could be OK if this is a core piece of your business. I'm actually going through the same thing right now where we are rebuilding our learning management system ourselves to get off of a third party because it's not flexible and it's not doing what we would like it to do.
And in this case, there are parts where you strive for parity, but you also want to understand how people use your product or that piece of your product, let's say that's integrated into your system in a different way.
Melissa Perri: So first, I would start from your users. How are they using your product? What was that third party good at? What did they like about it? Then I would try to figure out and understand their workflow really well. I would try to make sure that you understand what pieces of those products really matter.
That's what you're going to start crafting your product idea for. A lot of people like to strive for a complete parity here, and sometimes you don't need complete parity because you don't use pieces of this existing product. You only really need what people use. And in this case, if people have been using this third party and you found out through this discovery work that I'm talking about that they liked it, it worked, things were really great.
You're going to scope out your new vision, your new idea for building this yourselves, and then you're going to build it. This is not super risky in this case. So you still want to test your usability. You want to see if you can make it a little bit better. But that doesn't mean that you have to go in this with saying, oh, we have to validate every single piece of that.
Do it through discovery quickly with interviews.
Melissa Perri: Watch how people are using it. Understand why they're using it. See if there's opportunities to make it better. But then take that information and scope out what this product would be. If you build it, you should probably have a ton of functionality that you're going to need to rebuild yourselves. That's OK.
So scope that out and look for those opportunities to actually do a wow factor. And also, you want to make sure that you're not doing this super big bang. So like for us, we're looking at what are the actual core parts that we have to build on this. And it actually is a lot that we need to rebuild to be able to just launch.
And that's OK. Sometimes I think people think that's anti-agile or we're not doing MVPs. Like we're still doing a V1, but we have a whole existing business using this functionality. So we need to make enough tools to have some kind of parity with it. But it doesn't mean that we're building absolutely everything that the other platform has.
We're not rebuilding it. We're rebuilding only the functionality that we used into our own. And then we're rebuilding the stuff that we want to make custom on top of it that the other platform didn't do. That's really what I would look at. You can still scope this down into a smaller first version that helps get it out into the world, get you off that third party, and then you can carve out more from there.
Melissa Perri: But make sure that you have the must-haves on your platform. So there's a great thing out there called the Kano model. That's probably a fantastic prioritization framework for you right now. And what that looks at is features that are must-haves. If people don't have this and they were using it in a workflow and we don't provide it, it's going to break their workflow and they're going to be very unhappy.
Build that thing. Put that in your first version. Then there's performance ones. So I think they call them reformers. But this is the middle diagonal line that goes up in the Kano model if you look at it. And what this is saying is that every time we put a new feature in that's like that, it makes things marginally better.
So maybe you make it faster. Maybe you make it better UX on top of things. But you can look at that and say, maybe there's a good rough and dirty first version we can put out that everybody will be satisfied with. But in V2, we can make this a lot better. And we're going to launch something that's a little bit better, more performance enhancing.
And then you have delighters. And for you to do a relaunch like this where you can actually take people off this third party and put this new one in, if it's just like a basic thing that works and nobody's really struggling with it and it looks great and it's not like a super high priority, you might not want to throw a delighter in there.
Melissa Perri: But if it's something that's critical, here's a big one. Let's say you have to actually move people or migrate them from the third party onto your platform and they have to do something. This is where delighters come in. So any time you have to ask a user to leave what they were doing now and migrate to a new system, you want to put in things in there that solve problems they've been asking for, like things that you have not solved yet, things that are painful, or you want to do it in a better way because that incentivizes them to move.
So think about that when you're rebuilding this if that's your case. If this is on the back end and nobody will see it, you don't have to worry about those things. But if this is on the front end and you have to ask users to do an action to migrate from the third party onto something else, this is where delighters become amazing.
Delayers really help people see the value in moving. So they're going to want to do it more. So definitely think about that. Think which ones you need. Do we just go for parity? Can we slim it down? But always try to slim it down and get it out as fast as possible so you can get off that third party.
Melissa Perri: You can test it. This is really good, too, where you want to break down and maybe do some beta testing on the back end, build your version, migrate some people, make sure it works first before you go big bang. That's how I would approach it. This is actually not a simple task. You might be looking at this going, oh, I just have redeveloping an existing product.
That's boring. This is actually a pretty hard thing, and we do it all the time. Product management does this all the time. So don't look at this and go, oh, I just have to recreate this. It's your opportunity to shine. You can do it better. You can do it seamless. And pulling this off is really important.
So that's it for Dear Melissa this week. Thank you so much for listening. And again, if you have any questions for me, please go to DearMelissa.com. You can also find all of our other podcasts on there. You can browse our history of podcasts. And if you like this, please subscribe on Apple or Spotify or wherever you're listening to this.
So that you never miss an episode. We'll be back next Wednesday with another guest.
Melissa Perri: See you then.
