In this Dear Melissa segment, Melissa answers subscribers’ questions about what domain experts can do to learn more about product, how high of a level product people can achieve in organizations outside of SaaS or software companies, and what the right process is for rebuilding a product. Her answers have a core theme in common: as a product person, thinking outside the box and looking for opportunities for disruption is always a good idea.
Show Notes
Q: Do you have any advice on how I can overcome some of the common pitfalls that arise as a result of being a domain expert and product manager? Where should I focus my career development to become an amazing product manager that can tackle any problem?
Q: What's the highest product role you typically see outside of SaaS or software companies? Do you see a trend of more CPO roles in more traditional companies like banks or insurance? Do you think they should have that role or does a VP or SVP of products suffice when the core product is in software?
Q: What’s the best way to approach rebuilding a product?
Resources Melissa Perri on LinkedIn | Twitter MelissaPerri.com
Episode Transcript
Think outside the box, study products, study what makes them successful, study what delivers value to your users. That's what's gonna level you up because you're already an expert in your domain. You don't need any more of that. You need to look at how do I flip my domain on its head and disrupt it in ways that I even thought was not possible before.
That's the stuff that I really think you could do. And when you understand these product patterns, right? Like how products are built, how they're scaled, why they work, you start to see these across industries. I've worked with almost every single industry now at this point and everybody's like, well, are you a domain expert in this?
I don't know if I could hire you for that. I have never had to be a domain expert in anything I've helped with. And it's because I can see the patterns emerging from the different types of products that come out there. I can learn the domain expertise and I partner with domain experts because I think they're phenomenally smart and there's stuff that I'm not gonna know, but my job there is to figure out the product.
Hello, and welcome to an episode of Dear Melissa from the Product Thinking Podcast. The lines are now open and we're ready to answer your most pressing product questions. Which prioritization framework would you recommend and why? Hi, Melissa, do you have any suggestions on developing a product strategy?
I'm struggling to walk this way to the bathroom. I'm a little shy. I'm a little shy. Whoa, whoa, whoa, whoa, whoa. That's a lot of questions. All right, let's dive in. Let's dive in. Hello, and welcome to another episode of Dear Melissa. Today, I've got three great questions from you to answer. One is about subject matter experts and what they can do to learn more about product.
Another one is about how high of a level do we get to in organizations that might not be typical SaaS and software companies when it comes to product. And then the last one is gonna be about building roadmaps and how do we re-architect things over time? What's the right process for that? All really good questions.
And I just wanna remind you too that if you have a question for me, you can leave it at dearmelissa.com. So the first question. Dear Melissa, I listened to your episode with Marty Kagan and took special interest in the section about domain experts as product managers.
My company took the path of creating product managers out of domain experts, and I am one of them. Do you have any advice on how I can overcome some of the common pitfalls that arise as a result of being a domain expert and product manager? Where should I focus my career development to become an amazing product manager that can tackle any problem? That's a fantastic question. And we're gonna get to it right after this. All right, and we're back and we're talking about what you can do to become a great product manager when you're a subject matter expert. What do you do? How do you actually learn?
I think a lot of subject matter experts can become great product managers. So let me just throw that out there. But it's a whole different thing about getting out of your own way. So one of the most dangerous things for a subject matter expert who's going in to build software is really this mentality and this thinking about, that's not the way that it works here.
You need to have a really open mind as a product manager and realize that the beauty of product is that you can apply different software solutions to your context to deliver value. So what does that mean? That means you gotta get inspiration from everything that's around you. So study all different types of products.
Like for example, if you're an insurance, don't discount the interfaces that are used on things like Amazon or Slack, or the fun, new, cool consumer softwares that are out there, because maybe you can use that for your checkout flows. Maybe you use that in your application so that it's easier to actually manage your insurance policies. Maybe you come up with a whole way of attracting new customers and millennials because, hey, they saw an interface that looked a little bit more like Instagram or a little bit more like, you know, whatever.
And it resonated with them.
No, I'm not saying like, it's gonna be a one-to-one parody here. Of course not. But that doesn't mean that you can't borrow ideas. You can't look at it for inspiration. I see so many subject matter experts, especially in really, really complex industries like banking, insurance, healthcare, all of this stuff, just look at their products and go, oh, well, you know, it's so much easier to build B2C over there.
Like look at Tinder. It's so much easier to build Tinder because they can have fun. But like, we're complex. Like we do healthcare or we're complex. Like we do insurances, all the stuff that I'm actually mentioning. But you know what? Let's actually look at the Tinder interface for a second. You're swiping on choices, right?
Can you apply that user experience to something else? Can you apply the matching that they do to something else, right? Like there's matching in a lot of things. I've seen very similar situations if you're gonna build an enterprise product to match consultants with like companies that need them.
Matching is matching, but the way you display it comes down to borrowing good UX patterns, borrowing good product patterns. I've told the story before of when I worked with a bank and they couldn't see themselves as a platform, right? And it's because they're so stuck in the ways of looking at their legacy products and looking at what they've always done in the industry that they couldn't imagine a different way.
And that's the biggest hurdle. Get out of your own way and look at it from different perspectives and look at things and be like, can I borrow that idea? Can I apply that idea over here? And oh, that's interesting. Patterns, those are interesting ways to structure products. Like people are doing this too with new technologies these days, like blockchain, right?
Like every bank in the world all of a sudden loves blockchain. It's like a new way to do things. It's new technology. Product is the same way. So study new technology, figure out what is important to you, figure out if you can borrow things from other industries, and then figure out like how that value is gonna manifest for people.
That's where I would really study. So good example, Capital IQ adopted like their automated chat assistant way before other banks. You know, they didn't look at it and be like, oh, Amazon Echo, we can never do that. They went, oh, we could actually do voice-related technology. We can pair with Echo.
We can put a chat bot interface into our product and allow people to get what they need from it. Like, oh, look at all these other different technologies we can use to make ourselves a more modern bank. That's the key. That is what the mentality is that you need as a product manager. So moral of the story is think outside the box, study products, study what makes them successful, study what delivers value to your users.
That's what's gonna level you up because you're already an expert in your domain. You don't need any more of that. You need to look at how do I flip my domain on its head and disrupt it in ways that I even thought was not possible before. That's the stuff that I really think you could do. And when you understand these product patterns, right?
Like how products are built, how they're scaled, why they work, you start to see these across industries. Like I've worked with almost every single industry now at this point, and everybody's like, well, are you a domain expert in this? I don't know if I could hire you for that. I have never had to be a domain expert in anything I've helped with.
And it's because I can see the patterns emerging from the different types of products that come out there. I can learn the domain expertise and I partner with domain experts because I think they're phenomenally smart and there's stuff that I'm not gonna know, but my job there is to figure out the product. So we work together on that.
So if you've got those domain expertise, you can recognize those product patterns. You bring that together, you're gonna be a great product manager there. And then you'll start to see that emerge across industries as well. And maybe one day you wanna step outside your industry, or maybe that's not your career path.
And that's totally cool. I know experts who just go deep in their industry or their domain and they become product managers in that. And they're highly valuable to those industries. But then there's also people like me who cut across a bunch of industries.
I have ones I prefer because I've seen a lot of them now, but you will see different patterns. And that is the mark of being an amazing product manager, recognizing the patterns, recognizing the problem, and then coming up with creative ways to actually solve it. All right, next question. Dear Melissa, thanks for creating the podcast.
I listen every week. Well, thank you very much. My question is around senior level org design. What's the highest product role you typically see outside of SaaS or software companies? Do you see a trend of more CPO roles and more traditional companies like banks or insurance? Do you think they should have that role or does an VP or SVP of products suffice when the core product is in software?
So what do I see versus what do I think actually needs to happen? I see usually not a lot of chief product officers at banks. Or if there is a chief product officer, they're like several levels below the actual executive team. And they just give people like a title called chief product officer, but they don't actually do the strategy planning at the top of the organization.
I see that quite a bit. I don't think that's right. What typically happens is you've got a CIO or a CTO who's the top technology honcho in these companies. And then we have general managers over each of the business lines. They're usually domain experts very deep in insurance or banks. They run the profit and loss of each one of those businesses.
And then we'll have a VP of product or an SVP of product that report into that general manager. And then there's kind of like a dotted line out to that CIO or CTO. Why doesn't that work? One, if you're a CIO or CTO isn't really a product person, and many of them are like more infrastructure type people, more about scaling systems and databases, having the right tools to actually do your work across the organization, making sure that your databases don't fall over.
It's a very, very important thing when you're a bank. Super important role, not a product role. Now, product roles are about like understanding the business at that high level.
And then thinking about how do I disrupt ourselves through software? And also I think a lot of insurance companies, typically older banks, stuff like that, are worried about disrupting themselves. But here's the thing, if you don't disrupt yourself, somebody else is going to. Look at Policy Genius and Lemonade.
They're out there disrupting the insurance business like crazy, making it so much easier to get insurance. Meanwhile, all the bigger companies are struggling. And it's because they don't really have top product people at the highest levels, thinking about how to change your strategy and build software products to deliver their value in better ways.
And that's the thing that we're missing when we just report into a CIO or a CTO. It's like, how do we harness disruptive technologies? How do we harness user experiences that are out there, kind of like what I was saying in the last question as well, to disrupt ourselves? And you need to get out of the way and do that before somebody else does.
So what would a chief product officer really look like at a bank?
They would be looking at all of the different product lines across many different of the business lines, right? So I'd look at every business line. There's probably going to be a VP of product there as well. I'm looking at what can we do as a portfolio across all of these different business lines that can harness the powers of each one, that can standardize our products across all of these things.
What can I do to build platform approaches? What can I do to create APIs that can actually talk to each other? What can I do to disrupt the experience that we have here? It's about holistically looking at everything together instead of in silos. And that's the problem when you just have a VP of product reporting into a GM on one business line.
You've got nobody holistically looking at the experience end-to-end across the entire bank. What if you have somebody who's a commercial? This happens to me. Like I have commercial accounts. I have personal accounts. I have credit cards across all of these banks. All different experiences when you log in.
Very hard to manage.
And I know they're different businesses. I know it's super complex across all of those, but the way that you experience the product doesn't have to be. Who's up there thinking across it? Now, some banks do do this and they do it pretty well. Other ones don't. Other insurance companies don't. There's always going to be an example of people who do this well, but the majority of people don't.
And I do believe it's because we don't have enough chief product officers at the highest level really thinking about productizing these different industries, disrupting them, turning them on their head, and just thinking outside the box, kind of like what I said with the subject matter experts in the last question too. So I think we need more chief product officers in these roles and they have to have the power, right? They have to have the power to be able to make these decisions, observe these portfolios, and work with those VPs of product to execute.
All right, last question. Dear Melissa, what's the best way to approach rebuilding a product? I've inherited a 10-year-old product which has a lot of usage. The technology and UX are very outdated and decision has been made to build the product from scratch with new technology.
The project will take multi-quarters to rebuild the same functionality and I want to mitigate the project risk. Ooh, we just literally had a whole case on this in my Harvard Business School class. So it is fresh and top of mind because this is what I taught on Monday. Okay, so there's many different approaches to actually doing this.
We have to think through what's going to de-risk the project, what types of risks are we actually talking about? And then we have to think through the scenarios about what's actually right for your company. Now, two different ways to do it. Keep the existing product running, re-architect or rebuild.
This is going to be a rebuild, it's not going to be a re-architect. Rebuild this new platform, migrate everybody over. So basically if you're doing that, you're almost like big banging the release of the new platform, you're migrating people over. There's a lot of risk about that. There is risk from a desirability standpoint.
Do the consumers actually like it? If they can't actually use it before it goes live, you can mitigate some of that risk by doing alpha and beta testers as you go, pulling them into the new platform, getting feedback, iterating, and letting them also go back into the other product.
But if you have data transfers and stuff that are not going to happen into this new product early enough to do that, you've got some risk there. Technological risk where it's just like, it's probably less in this case because you're starting fresh, you're starting to look at it. But it's a really long lead time to getting to a live product.
So what's usually the biggest risk in that case is sales risk and churn risk. So here's my first question for you. What's the churn like at your company? Are you going to have a bunch of people leaving because this product sucks? Do you have a lot of people who are just kind of locked in and they're going to stay for a while?
One of the approaches that we take in especially high growth companies, even lower growth companies, but ones where churn could be a problem and where new sales is slowing down like crazy is we start to take more of an incremental approach. And this is what I would recommend for actually anybody embarking on this. So what we look at is deeply understanding how people use the product.
We put together a new product vision for it. We solve the problems with it. You know, maybe it's a scalability issue, but at the same time, you can address a lot of the UX issues that are coming up from your customers or things like that. You can add some new value, maybe if you think about it in different ways.
So go out there, do your normal discovery process and don't just build the same exact functionality or same product from scratch. This is an opportunity to make it 10 times better. So go figure out how to make it 10 times better and then come back and start to break it down into phases. Can you release part of it?
Like maybe there is one product line or one workflow in there that you can build out completely in this new product. Maybe you integrate it into the old product if it's easy. If it's absolutely impossible from a technical standpoint, which sometimes it is, you put the alpha beta testers on there. You let them use it.
You say, do you like it? You get the feedback that way. But you take the step-by-step approach. And I think about it as slicing like down the value, right?
Don't just build it as like databases and then the APIs into the databases and then the front end on top of it, the last thing like all the way across. Think about it as value components in slices. How can you build those out to start working with that in a new way? Other ways we've done this as well.
I worked with a company where the backend was kind of a mess, but the front end was the bigger concern. The user experience was the thing that was causing everybody to churn. So we needed a new UX. We also needed a new backend, but what did we do? We found out that we could skin the user experience and keep the same wonky backend, redo a bunch of the user experience, highlight key workflows.
So not change everything, but just highlight key workflows, like, you know, two or three of them to change that to add enough value and to make it look fresher while plugging into the old background and doing the re-architecture there. Now that allowed us to continue sales, continue, reduce a bunch of the churn that was gonna come from a user experience standpoint.
And we knew it wasn't gonna scale perfectly forever, but it did buy us some time because we were able to keep up with our sales. So I would think about like, what's your sales risk going into this? What's your churn risk? Are there a bunch of people who are in danger of leaving because of X, Y, and Z?
Narrow down where the technical risks are, like, is it a, and the problems are for the user, like, is it a scaling risk on the backend? Is it a, you know, a front-end usability type thing? Try to do that, break down those pieces and try to figure out how you can do this in phases and keep incrementally releasing value until you get to the new platform so that it's not just like, hey, we went away for one year and then we came back and big bang platform release.
I've actually seen those big bang platform releases or huge redesigns fail so many times. There was actually one that I was a customer of, like FreshBooks went out and reconfigured, redesigned, redid everything on their platform. I was a huge user of FreshBooks back in the day for all my invoicing needs.
90% of the things that I needed to do, I couldn't do on this new platform. It's really complicated to use and I had to go back to the old platform that they were using and eventually they had to kick me off on it and I left and I went to QuickBooks. So that's a good example of they went away for a while.
I don't know what kind of testing they did, wasn't on me, but maybe I'll give the benefit of the doubt that they did testing, but they really didn't understand the user's needs and where they could add value. Instead, they took things away. So think about that as well. You don't wanna take too much away, but you also, if you have analytics and it has tons of issues, you can see what people are not using that much.
You can take some of that stuff away or put it out into a next release, but really make sure that you're honing in on the things that are absolutely important and critical for use for your users and then roll it out with a lot of testing, with a lot of feedback. Make sure people are actually using it before you do all that bells and whistles and flip the switch where everybody can get on it. That's my biggest piece of advice when you're embarking on something that big.
I try to do these kinds of vertical slices from a value perspective, figure out how I can tackle that once you have a good product vision, how I can change these things over time, how I can get feedback.
If you cannot integrate a new version or new slices into your existing platform, fine. It happens, it does happen. Let's put testers onto our platform as we build it out. Let's slowly migrate people over. If we can figure out how to make the two talk to each other, even better, but if you can't, oh well.
Other thing to think about is how many people you've got working on stuff. There's a morale issue when it comes to these things. Here's a really good example. If you have a whole team building the shiny new product and you've got three teams maintaining the old busted 10-year-old product, what do you think those teams that are working on the old stuff are gonna do?
A lot of times they leave. Usually when you do some kind of re-architecture like this or a rebuild, the teams that don't get to do the shiny new stuff, they leave. So really think about morale issues, really think about how you're distributing work, build the vision up front and make sure that everybody's bought into it and you really understand it and you can add value and you don't just rebuild what you have.
And then I would take it piece by piece and break it down. So that is it for the Dear Melissa this week. Thank you for listening. Again, if you have any questions for me, please submit them to dearmelissa.com. Next week we'll have another fabulous guest on our podcast. I cannot wait to chat with them. And if you are loving the podcast, please leave me a review at Apple Podcasts or Spotify or wherever you can leave reviews. It helps people find it and hit that subscribe button so you never miss out every Wednesday when we release a new podcast. Thanks very much and I'll see you next time.
