Episode 185: Moving to a Product Model and Embracing Digital Transformation with Melissa Douros
I recently had the opportunity to speak with Melissa Douros, Chief Product Officer at Green Dot, who is redefining how we approach product management in today’s dynamic market. Melissa, with her deep expertise in creating cohesive customer experiences and integrating strategic design practices, shared her invaluable insights on building robust product strategies and fostering innovation.
In our engaging conversation on the Product Thinking podcast, Melissa delved into the significance of understanding the customer journey as a continuous, non-linear experience and the impact of having a unified design system. Her approach to aligning product management with strategic design and her perspective on the role of a well-structured product council provided a fresh outlook on effective product development.
Join me as I explore Melissa's strategic wisdom and discover actionable advice on enhancing your product management practices while driving meaningful customer engagement.
You’ll hear us talk about:
02:53 - Green Dot’s Reusable Architecture for Banking as a Service
Melissa discusses Green Dot’s innovative approach to scaling its platform through reusable architecture. Traditionally, as fintech companies scale, they often build new systems or products from scratch each time they onboard a new partner or introduce a new service. Green Dot is shifting away from this model by adopting a "build once, use many" approach. This reusable architecture allows the company to streamline the integration process with new partners and products, making it simpler and more efficient to do business with Green Dot. This transformation aims to enhance the company's ability to deliver scalable and flexible solutions, reducing the incremental effort and complexity associated with each new product or partnership.
03:27 - Product Management in Banking as a Service vs. Traditional Banks
Melissa highlights the nuanced differences between product management in banking as a service (BaaS) and traditional banks. In traditional banks, product management often focuses on distinct financial products like credit cards or loans, each managed by specialized teams. However, in a BaaS model, product management needs to accommodate both direct customers and partner organizations, each with their distinct needs. This dual-customer approach requires a more complex product management strategy that addresses the needs of both internal partners and external end-users, making the process more intricate compared to traditional banking.
18:11 - Balancing Predictability with Innovation in Product Management
Melissa discusses the challenge of balancing predictability with innovation in product management. She emphasizes the importance of maintaining predictability and meeting deadlines while still allowing room for creativity and innovation. Melissa suggests that a well-defined process is essential, but it should be flexible enough to accommodate innovative thinking and iterative improvements. At Green Dot, this balance is achieved by setting up processes that ensure reliable delivery while also carving out time for teams to focus on innovation and creative problem-solving.
To foster this balance, Melissa advocates for creating structured time for teams to brainstorm and explore new ideas, separate from their regular project work. This approach ensures that innovation does not get stifled by rigid processes and that teams can continually evolve and improve their products.
Episode Resources:
Other Resources:
Follow/Subscribe Now:
Facebook | Instagram | Twitter | LinkedIn
Intro - 00:00:01: 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 Perri.
Melissa P. - 00:00:37: Hello, and welcome to another episode of the Product Thinking Podcast. Today, we're joined by another Melissa, Melissa Douros. She's a Chief Product Officer at Green Dot Corporation and a seasoned product leader. With over 20 years of experience, Melissa has shaped digital strategies across tech and finance, spearheading transformations in various companies, including Discover Financial and E*TRADE. Today, we're going to talk about what it means to transform to a product model, including how to structure teams around customer journeys, how to kickstart a transformation, and why you need to stop thinking of process as a dirty word. But before we start to talk to Melissa, it's time for Dear Melissa. So this is a segment of the show where you can ask me all of your burning product management questions. Go to dearmelissa.com and let me know what they are. And I also prioritize all the voicemails. So if you want your question answered fast, drop me a voicemail. Today, we're going to the phones. Let's listen to our caller.
Dear Melissa, I am a product manager at a big safe company. My program manager handles most of the product-related tasks, so I find out about the requirements very late in the game. I feel like a project manager and worry I am not practicing my skills or advancing in my career as I barely talk to stakeholders. I'm frustrated and considering other opportunities. What type of company should I look for to quickly learn and grow as a product manager? And is it safe to hunt in tech right now after all the layoffs? Thanks.
So it sounds like to me, your company is probably in the process of doing a transformation and is not purely software. Maybe you work for a bank. Maybe you work for a pharmaceutical company. It could be anything. Not sure what's going on here. It sounds like you feel like you're not learning and you're just kind of acting like a project manager instead of a product manager. So what I would think about for you is where can you go to learn? I always suggest for people to follow great product leaders rather than looking purely at the companies they want to work for. So can you, do you read blogs? Do you follow any chief product officers or product leaders anywhere that you really admire? Those are the types of people that I would go work for because they're going to teach you. And whether those people work in a bank or they work in a software company, it doesn't matter as long as they practice product management well, and as long as you can learn from them and feel like you're doing the job of a product manager. That's what's going to set you up for success. And that is going to allow you to actually succeed in this role and go to other places or move about into different types of organizations, whether they be software or something else. So that's what I would look at. Now, the software world is stabilizing. A lot of SaaS companies went through a big downturn in the last couple of years. They overhired. A lot of layoffs happened. We've got a lot of people out there searching for jobs still. But I do believe it's stabilizing. It's not that it's not safe in the tech world, but there are some things that you should look out for. You need to understand a company's runway. So if it's not a public company and they're not profitable, if you are going to work for a software company, I would try to figure out what the runway is.
Are they burning through cash like crazy? Do they have something to get them through the next five years? Ask these questions. You're allowed to ask these questions in interviews. It makes you look smart. It also means that you actually care about what the company is doing and you understand enough about financials and how these things work to care about that when you become a product manager. Because remember, product managers are not just about figuring out the solutions. It's about figuring out solutions that produce business and customer outcomes. So that business side is important to understand. So you should ask these questions. Now, if your company just raised money, usually that's a good sign. But if they haven't raised for like three to four or five years, they might be burning through that. So that's where you have to understand if they're profitable. If not, what's the path to profitability? If you find a profitable company where you find one that just raised or that has a clear path to profitability in the next one to two years, you should be okay. It should be very safe there. There are probably going to be a lot of companies, though, that are not safe, that are running out of money, they have to raise, and it's not a good environment to raise in right now. Those are the companies I would watch out for. So ask all of those questions when you go in for the interview. But it's not about software companies as a discipline being a bad place to work or a scary place to work right now. It's about finding the right companies. So no matter what, whether you work for a software company or something else, if you don't want to do a public company, try to figure out what that runway looks like. Public companies are easy. You can see their stock. You can see if it's going up or if it's going down.
If they've had a lot of stock going down, it's probably a turbulent place. They might be doing layoffs. But their stock is going up, again, this might be a good place to work. So I would really look at those things because that's going to secure your future. And again, find somewhere where you can learn from someone, follow people, follow leaders, and that's how you're going to hone your craft. I hope that helps. And again, if you have any questions for me, go to dearmelissa.com and let me know what they are. Now it's time to go talk to Melissa. Are you eager to dive into the world of angel investing? I was too, but I wasn't sure how to get started. I knew I could evaluate the early stage companies from a product standpoint, but I didn't know much about the financial side. This is why I joined Hustle Fund's Angel Squad. They don't just bring you opportunities to invest in early stage companies, they provide an entire education on how professional investors think about which companies to fund. Product leaders make fantastic angel investors. And if you're interested in joining me at Angel Squad, you can learn more at hustlefund.vc/mp. Find the link in our show notes. Welcome to the podcast, Melissa. I have to say you have a great name.
Melissa D. - 00:06:09: Thank you for having me. Excited to be here.
Melissa P. - 00:06:11: So can you tell us a little bit about your career journey and what was the challenge that made you excited to join Green Dot as their chief product officer?
Melissa D. - 00:06:20: Sure, absolutely. So just to level set, I'm not sure if everyone is super familiar with Green Dot. We are a modern fintech. I like to say we're one of the OG fintechs. And we are responsible for building best-in-class financial products, best-in-class customer experience for companies. We also have a consumer product, our go-to-bank, and it's very well-placed for people who are looking for a trustworthy, reliable, and best customer experience bank. And my role here, as you mentioned, is the Chief Product Officer at Green Dot. So I'm responsible for the delivery of our products, the product design, and the product strategy. So kind of a different career path. I went to college to be a teacher. And back then, this role just didn't exist, I would say. And I like to say that I didn't know exactly what I wanted to do because it had to evolve and sort of have me find my way into it. Went into operations and then project management. And as products started to take shape, I was a very natural sort of self-selection into leading the products and financial services. Been in financial services for about 20 years. It is definitely my passion. And so excited to talk more about it with you today.
Melissa P. - 00:07:24: I reached out to you too. This is interesting because I had never heard of Green Dot Bank, but then I have money in the savings account in Betterment. And I saw that Green Dot Bank was one of the holding companies for it. And I was like, what does this company do? And I started digging into it. And I was like, this is one of the OG fintechs. The way that you've structured your products, I think, are really interesting because it is different than a normal bank that you would think of. Can you tell us a little bit about how Green Dot does banking as a service and what the journey has been in your products lately?
Melissa D. - 00:07:56: So we are a little different from other fintechs. We are a bank, banking as a service, but we are also a platform company. So our big goal right now is to continue to build upon our reusable architecture. So I think as a lot of companies found themselves, as they scaled, they kind of built for one. And then each time they had onboard a new partner or wanted to onboard a new product, it was really a continuous build out for each one, sort of nuanced. And so what we are really looking to do, and we've been on this journey for a bit, is to convert into this build once you use many reusable architecture, which benefits our partner onboarding, obviously, because every time we have a new relationship with a partner or stand up a new product, we're building into that sort of turnkey moment where it's very simple to do business with us, which is what we always aim to do.
Melissa P. - 00:08:46: So I think a lot of banks, as we know it, are starting with product management just today. They've done the agile transformations. They're Melissa D.ducing product management. They're kind of just standing it up. Some places are a lot further than others from what I've seen. When you think about product management at Green Dot, when it comes to banking as a service and your platforms and also having the banking component versus a traditional bank with product management, are there any differences in there? Are there any nuances?
Melissa D. - 00:09:14: Yes, I would definitely say there is. So product management, I would say, is issuing bank. It's very centered around the customer as the end user. It's a very typical type of customer, and there's segments in there, obviously, from a segmenting perspective. But it's a little easier to stand up the product transformation because you have login, you have credit products, you have lending. And so you have sort of these menu products within, the larger sort of burky's P. But I can tell you it's a little bit less difficult to stand that up. With a BAS company, you really have to take into account that you have two types of customers. You have your customer and our consumer in direct business, but then we have our partners. And so they are our customers, and then we have our partners' customers. And so when you are thinking about stating a product model, I would say our journey is really thinking about how does the sales organization benefit from using this? We are on the journey. I would say we are not yet. My team has been doing a lot of work as I've been here the last three months to sort of define what do we feel is a product, because onboarding a customer into our go-to-bank experience is going to be a lot different than onboarding a partner onto a BAS platform. So we're kind of on that journey right now. But I would say that the manuals, they're the greats that preach about this is the product, this is not a product. But what you really have to do is massage every single methodology to make sure that it works for your company so that you're not transforming to try to fit into somebody else's.
Melissa P. - 00:10:44: When you think of what's a product versus not a product, there's a lot of debates too in banks about your loan as a product, let's say, right? Or your credit card as a product, which I'm sure you're familiar with at Discover. When you think of a product, how would you define it? How would you think of the different products?
Melissa D. - 00:11:00: So when I think of product, I think the biggest difference to look at is what is a project versus what is a product. So a product is a team that's going to be persistent. There's going to be an iterative process every single time they're building something. They're going to be diving into the data. They kind of stay together and they're really understanding they're building up their domain expertise. They're really understanding how is this benefiting or not benefiting a customer. And the best thing that they can do is be together and learn from each other and learn how to do that in a stronger and better quality way. Projects, which is, I think, probably more of the traditional model when people are thinking what's not a product, what is a product. A project is sort of a consist of many different products that go into it. In the same way that when we transform into agile, and we say, how can we break this down into a very minute sort of smaller piece and smaller chunk, that's the same way that you want to do it with products. And so I've seen the student loans, business, the deposits account, those are products with a big P, but they're not products with a little P where you would have an entire team dedicated to one of those. And that's where I really see the difference between what is a, where people are kind of struggling with what is a product versus what's not a product.
Melissa P. - 00:12:07: And when we talk about products, what always comes up too is the product operating model, right? Or moving to a product model in these organizations that are embracing digital transformation. You spearheaded a lot of that at Discover. Can you tell us a little bit about your journey there and what it means to move more into a product model?
Melissa D. - 00:12:25: We believe that we love change, but we don't, right? We want things to get better, but we want them to absolutely stay the same. And so there's a few different facets that you benefit from the product model. And one is the relationship between the product team and the technology team. And so in sort of an antiquated waterfall way of doing things, you have this very separate set of work that's being done. The product team or project manager back in the day, they write the requirements. They have this very large document. You have these very large natural workgroup meetings. People are all kind of coming together at different points in the process of what they need to do. You toss that over the fence to the technology team. They scope it. They have a couple of questions and you build something which is most likely very different than you thought it was going to be from the beginning. So really it's the refinement and understanding that coming together from the key stakeholders. Everybody has sort of this round table type moment in the beginning where they bring, here's everything that I need to make sure that this is going to be a quality delivery. The other thing I would mention is output versus outcome. In a traditional delivery model, people and teams are very measured on how many projects they can deliver in a given period of time. And you can imagine that when you're sort of, I need to deliver 10 things, the quality can suffer. You're not really as focused on if I'm going to carry this from the beginning to the end. And the end is sort of this very far off piece. You can cut corners.
You can do things that maybe aren't the best for the quality delivery just because it's not yours. You don't feel any sense of sort of ownership other than just delivering on the thing. When you move into the product model, it's very much based on outcomes. So I'll use a login as an example, because I think that's a good one for people to understand. So in a project pre-product model, you have an imperative usually from up above. They say, hey, we want to enter a passkey. No, we want people to be able to enter into our mobile app through a passkey instead of a password. And the project team build on the requirements. They deliver exactly what the team asked for. It is a passkey. That is the output. In an outcome, the imperative from up above says, we want to make it easier. We want to go to the product team. We want to make it easier for customers to have access to our digital channel. How would we do this? The product team gets together and that's risk and fraud and product and technology and analytics and everyone. And they build out what is the best way to give customers access. Passkey might be one of them. Passwordless might be one of them. Biometrics might be another one. But really what they're doing is saying, hey, what is the data in the current situation? Say, it's a 75% success rate. They've set a goal. We think we can up this by 10% by the end of the year. And here's the 12 things that we're going to do to get to. And they keep iterating. They keep learning. They pivot when it's necessary. But that's really, I would say, the benefits and more of the structure of that.
Melissa P. - 00:15:08: So when you're a large financial company that wants to embark on a product model, where do you start?
Melissa D. - 00:15:14: For those looking to transform, I would say, you know, into this model, read as much as you can about the people who have done it before. There are so many case studies out there. People are so willing to give information of, hey, I did this work, this didn't work. That's one of the biggest things. The second I would say is find some of the gurus who really do it well. Michael Kagan from Silicon Valley Bank. He is probably one of the best, written a few books on how to really move into the product model. And he has very different flavors. We talked about before what works for you may not always work for everybody else. And so he writes about a lot of different types of business models and that can help you. I would say that, you know, you want to find the strong advocates within your organization and not everybody's going to be there. You kind of got that belt curve of adoption, your early adopters, your middle layer, and then your ones that maybe never even buy into it, but they do it. And so you want to shop it around, don't get discouraged. You'll find the people that are going to help you. Not everyone will be on board in the beginning. You know, that's okay. But also who you want to get on board is your CEO. And that doesn't mean that your CEO has to be this product expert or truly understand what it means to go through the transformation, but they have to understand the benefit. And so they can be up there explaining it's you with their being their counsel of what are the benefits of moving and transforming into this model and helping you sell it. Because that's really going to be your strongest advocate and strongest voice.
Melissa P. - 00:16:36: When you were at Discover, how did you identify your advocates for moving into this model? And how did you get the C-suite to listen? Because I find that sometimes people's biggest hurdle is also not even just listen, but grok what we're trying to do here. Because I've heard from people when they write into the show or when I'm out there consulting, they'll say, we all know that we need to be outcome-oriented. And the C-suite will say, yes, we want to be outcome-oriented. But then putting that into practice is where it starts to all fall apart. So what did you do and how was that successful in getting that transformation going?
Melissa D. - 00:17:14: So my team was part of the pilot to go through this transformation. So we were selected and also kind of self-selected. We were the ones that were the guinea pigs and we're always up for that. So our same always up for that. So that is great. We had fantastic coaches. So we had external advocates and external ambassadors for us, which I know. Not every organization has, right? Sometimes you're kind of on your own and you're delivering this yourself. But the same way that I do it with building products is you find one and you start with that and you build out a proof of concept. You learn about what happens. You learn about how you can scale it. You learn when to pivot, right? And you be very humble and very honest about the things that you learned and the way that you pivoted along the way. And then you show the measurements of success. And I talked about outcomes versus outputs. There are a few measures of success that product teams can really lean into because they are this centered around these experiences that you're building for your customers. There's a team success metrics. So one of the ways we did it was show increased velocity. So I know I've mentioned output is not the measurement, but you will, you want to make sure it's output with quality. And that's what measuring the velocity is done. And you'll notice it's obviously from a lot of the agile principles. It's just much easier to do in the product model.
So where a team, started maybe being able to deliver 30 users story points, a sprint, they're not moving into 60. And it's because they stayed together and then they kept moving forward. You talk about burned out. Where were all the things where we didn't get pinched and how are we able to really have that downward trend in getting everything delivered? How often are we adhering to ceremonies. Are we doing the demos? Are we making sure that all the key stakeholders are involved in what we're delivering? And the second that is the product health metrics. So rallying around kind of the customer experience of delivery, you know, how fast is the page loading? Where are the right APIs? Did you migrate them over from soap to rust or if it's the opposite of what you're doing? What's the stability and reliability of that platform? What's the struggle score? So really understanding those platform metrics. And then finally, the key performance indicators that everybody is interested in, right? The revenue drivers, the operations expense takeouts, did it result in more conversions? Did it result in more enrollments? And so when you're speaking sort of the language of all of the measures of success, it's kind of an easy sell to show how much more beneficial the model was.
Melissa P. - 00:19:34: What I liked about what you're saying right now that I think a lot of people misinterpret is that you did mention the Agile metrics. And I think there's such backlash against Agile at the moment. So people hear like the word velocity and be like, I'm not going to talk about that. Like you can't talk about velocity. But there's so many organizations out there that just can't ship at all that I do think it's something that we need to talk about. And we do have to get customers out there to things out there to customers. So it's not something that we can ignore. How do you maintain that balance between those product metrics and the outcomes that we want to achieve and the Agile velocity metrics? So everybody's not just zeroing in on what you were talking about quantity over quality there.
Melissa D. - 00:20:13: So my big thing and what I'm kind of preaching to my team, coming into Green Dot and understanding some of the opportunities that we wanted to solve and take forward is really maturing the product organization. And part of that is to not just be calling a little bit more of a strategic shop, but to understand that giving a date is a commitment. And so how do we make sure that we are making that high integrity commitment of giving a date and talking a little bit again more about what's the difference between some of the organizations and how do you make sure that it's the right one for us is, in my previous experience, a date slipping was important, but not as important as I find it to be now. So we would uncover things, defects would pop up and we'd have to sell this wonderful story of why we're going to slip out a sprint or two. But it wasn't really sort of the end of the world. I know that's melodramatic, but it can feel that way these days. We have an end customer who is a partner. They are balancing their internal work based on the dates that you are giving them. So they're standing up their internal resources. They're talking to marketing about when they're going to sell and talk about these great experiences, maybe even promising their customers because things will look and feel different and they want to make sure that they're getting excited about their products. Giving your word on that date is one of the absolute most important things that you can do. So when we talk about velocity and understanding what we can truly work on and how we can deliver, it's really about when we can deliver and really getting fine tuning that and understanding when that's going to be. And you can't do that without understanding the velocity of a team.
Melissa P. - 00:21:49: There are so many people out there too. And I feel like this is something that I learned a lot as I got more senior with my career, where if you are on a team as a product manager, you really want to be like, hey, no dates, right? We're not going to commit to any dates. You'll just get it when we get it. And the more you get into the business world and the more that you're responsible for the P&L of the business and feel the accountability there, the more you realize that's fiction. Like you can't actually run a business that way. How do you balance and how do you encourage your team to balance that predictability with the opportunity to actually innovate or go out and discover new things?
Melissa D. - 00:22:25: It's funny because I, back in the day, have said that, well, we can't give a date because we don't know. And so we have to be able to do it. So I really think that a big majority of it is process. And you can stand up a process and you can leave it and say, it's process over people. And that's the end of it. And this is the way we have to do it. But what I like to do is say it's people over process. The process is a tool in order to give us a way to deliver what we need to do. And so we are actually at Green Dot going through an entire project delivery process revamp and really understanding where we are getting pinched at every single turn, understanding who is responsible and accountable for driving things forward so that we're making sure we're just like this really fine-tuned wishy. And when you don't have to think about how to do your job. You can think about the creative solution and cool innovative things that you want to do. And so everything we do really has to draw on a foundation. And I think coming up with those innovative moments is no different. Fine-tuned, everything's humming along. That means that there's plenty of time for groups to get together and do things like 30 minutes to innovate. So every sprint, I like to have my team spend a half hour, pencils down. And just kind of talk through things, right? What's the data we're seeing? What are other people doing that we think we want to do or do it better? So it's really just giving them the ability to carve out that mental space so that they don't have to think about how they're doing their work all the time.
Melissa P. - 00:23:51: 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. When we talk about process, I think people's heads go straight towards, I'm a fan of process. I think we need process. And I keep preaching that. So this is not me, but a lot of people and a lot of pushback I've gotten since I've written product operations as well and wrote a section on process is that they go immediately to things like safe, right? They're like overburdened in process where every little thing is actually defined. A lot of financial institutions I've worked with have adopted SAFe. And it's been my experience once I come in that I don't like the way that SAFe does product management because nobody who created safe ever did product management. But I also don't love the way that they're really communicating how strategy goes down. When you look at a process like SAFe versus what you want to implement in your company, how do you balance too much process? And how do you think about the product management process there? What's your views on that?
Melissa D. - 00:25:13: I believe you that no one ever did product management.
Melissa P. - 00:25:16: I know everybody who actually wrote it and nobody has ever done product management.
Melissa D. - 00:25:21: Interesting. Yes. Okay. So in a previous, we did transform to SAFe. And it was very much sold on the benefits of having rigor and understanding the way to do things and the planning. And I think that is so important. And so those kind of underlying principles are still there when we think about product management. I would say that if you ever looked at the process flow for SAFe, you don't see the customer until the very end. And I think that's one of the reasons why it absolutely failed. When I think about process, I just see it as a tool for the delivery of what we want to do and that's it. And you have to set increments of when you go back and structurally revisit what you've designed. And that's true in everything. It's true with continuous improvement. Everything you do, you should take a look at because what was good then isn't always good now and vice versa. Sometimes you come up with things and they're not ready for now, but they're ready for later. And so when I think about process and product management, I believe that there should be rigor and planning. But I think where SAFe failed and product mild picks up, and is the ability to pivot. And so when you're on a path and you learn something and you think, hey, this might not be the best possible outcome, then we should have that conversation and move forward. If you think about SAFe and planning in 12-week increments, you really can't have that conversation until the end of the 12 weeks. And by then you have a lot of wasted effort and a lot of wasted cost.
Melissa P. - 00:26:44: That is one of the big issues that I hear from people when they're in SAFe is that we get into this 12-week cadence. And by the time we're done with that piece, if we have anything that should go beyond the 12-week cadence, let's say, or something that's a little longer term, there's no place to fit it in. And then they get yelled at or they're trying to massage something that doesn't really need to be massaged just because that's the nature of how things are built into these increments that are just arbitrary, right? They're just quarterly. And you're like, what's quarterly? It doesn't really matter. It's just a moment in time. And sure, we do have revenue goals, but anything that would be that big was never going to hit it for revenue in that quarter anyway. So why are we all trying to just arbitrarily end it June 30th?
Melissa D. - 00:27:23: Yeah. And you've kind of given the notion that you are going to finish. And so when you get to the end of that 12-week increment and lo and behold, you have not completed something because it actually needed a couple more sprints, people, they're upset and they're happy. As you mentioned, they get yelled at. Executives get bored. The more, the longer something takes, the more we're kind of talking about it. Looking at that new shiny object. And so when you aren't so restricted into that increment that you have to feel like you have to deliver, it can be much better.
Melissa P. - 00:27:51: How do you temper those commitments? So we were just talking about those 12-week ones. Do you do it more on a continuous method? Are you saying here's things that we know we can commit to in this quarter? Here's things that we don't? How do you think about those?
Melissa D. - 00:28:04: At Green Dot, we're in a project delivery with agile principles. That's how I would call it. And so before I got here, and one of the things my boss has really challenged me to do is to think about how can we accelerate timelines? How can we really commit to the dates? And so we, if you think about a project, at the end of it, maybe we've delivered 12 items. And there's a big sacrifice sometimes in quality of that. Because when something is so large, there are things that are missing testing. I'm making, obviously, a broad generalization. But I don't think that my product-minded folks would argue with me of, you know, delivering 12 things at the end of six months. Is the highest quality thing that you can do? Now, if you stagger the delivery, if you sequence, if you think about building it in smaller pieces, you can actually realize a lot more of the benefit upfront. So maybe you have 12 items, and six are before that final date, and six are after. But the upfront ones that had higher value, lower effort that you've decided to implement, you're now seeing the value, whether it be revenue, contribution, operational expense, takeout. And you've finished it. And you can learn from it. And as you're building the other items, and you're really sort of learning about how customers are using it, you can actually maybe decide to pivot and not do one of the things that you would committed to, because you've learned that something else may be of much higher value.
Melissa P. - 00:29:22: And it's the key there, just communicating it back up. How do you make sure that the leaders know and anticipate that? I think that's everybody's biggest fear, right? Is that they say they're going to do something and the CEO is going to get mad at them because they didn't deliver it. How do you handle that? And what's your advice for product managers on how they should be communicating those things?
Melissa D. - 00:29:41: I find that so much is hearsay. We're so worried that someone's going to be upset or get mad that we tend to sometimes come up with that in our heads, instead of going and talking to the person and saying, hey, I know we had thought about doing it this way, but it actually have this much better way, in my opinion, to do it. And the answer might be no, right? Or there might be some unforeseen force that you didn't know about. But having that conversation is key. And I always joke that I want our stakeholders and our business people to say to me, oh, I'm so tired of your team. I can't be in a meeting without hearing them communicating the timelines and the status. And I never have to ask you, where's my, what's my, when am I going to get my? Because we're doing so much communication and we are so transparent. And that's really the key, I think, of building up the trust and really can benefit us with our stakeholders.
Melissa P. - 00:30:29: Another point that I wanted to get into is kind of how we structure our teams in large organizations and especially financial organizations, too. A lot of companies that I've worked with have adopted this journey owner model. And it's where we have a difference between, they'll call them product owners, but it should be product managers. But they're acting like product owners on the team. They're not doing anything strategic. And then the journey owners are people who are overseeing. It's almost like a matrix, right? Product owners are overseeing individual features that cut across larger journeys. For example, if you're logging into a banking app, there'll be a journey owner over the entire app. But then there would be product owners who plug in at various points across it. And they're struggling with how do we get ownership over those things and how do we actually think through a full strategy? How do you think about cross-cutting functionality and cross-cutting user experiences, let's say, for customers in a larger, more complex organization? And how do you structure your product teams?
Melissa D. - 00:31:25: There's a couple of ways to do it. You mentioned journey and customer journey. And so when you're thinking of your product site, the first thing you want to do is understand the product from a customer lens, right? So it's not sort of creating that internal view, but understanding a customer lens. When you think of a journey, you mentioned the cut across. We tend to sometimes build experiences in this very linear fashion. I login, I sign up, everything's fantastic, I move on. And that's not what happens. They're signing in 20 times a month. They're looking at their account balance. They got distracted. They're standing in line somewhere. It's just, it's a very different experience, I think, than we always sort of build for. So one of the things is really understanding that there's no start and stop in the journey. And there's always somewhere that it's going to be picked up. Another thing in the product model is you can sometimes silo yourself. So if you think about the notion that a product manager is responsible for the journey from start to stop. And as I mentioned, there is no real end. It's just where the customer goes next. I like to think of a strategic way to string everything together. And so what we've recently set up and what I've done before that I've seen to be very successful is this notion of a product council. And so it's the, in here, it's the director and above. And we actually had our first meeting this week. And we talk about, it's not a project status update at all.
But it's a very, hey, I'm building this. Did you see this? This might help you with this. Oh, I need this person to be involved. We're talking about very strategic things and how we're building things and what we might need from others. Design is in there. And so they're understanding things that people are working on. Because they're very much a glue and very much that horizontal, as you mentioned, to be that key moment in all the journey touch points. But it's really making sure that you have the right setup so that people are talking to each other. We also talked about having an intake. And so you don't have to go find someone and you don't know who to look for when you want to initiate a new concept. Or even just are struggling to talk about or articulate what you really want to build. And so part of our key skill set is to understand what customers need when they can't articulate, not only telling us what they want. So in the beginning of the product council, there's a 10-minute increment where people can then come in and sort of deliver this one pager of something that they sees an opportunity or problem to solve. And everybody hears it. And then everybody kind of takes away from it from their own lens how they can help build it.
Melissa P. - 00:33:44: Another thing that I found helpful in the past in organizations like that, too, is to have some kind of like design system. So that when people are plugging into different parts of the apps or experiences anywhere, there's something that's cohesive. And there's some kind of set of rules around it. So it's not just a free-for-all. And I've worked at companies that have 10,000 different types of buttons. You, I know, did a lot of work on that at Discover as well with your design strategy team. Can you tell me a little bit about what that team did, what it was responsible for, and then how it plugged into product management?
Melissa D. - 00:34:15: We had three different teams that sort of had that design hat. One is the design hands-on keyboard, really creating the experiences. Some of it was agency work and some of it was internal. We also had the design strategy team. And this team is the customer journey. They're the ones who are doing the competitive analysis. They're pulling the data, kind of doing these experience assessments. We appoint them of what are the current ways that customers are doing things. And then the third team, about 18 months ago, was kind of won over the hearts of leadership to create a design operations group. And we didn't have a cohesive design experience across all of our products. And that's the big P across lending, across deposits, across card to say hey, we are one brand and we're going to show up that way to our customers. And so we had these Poppins before I would say, different teams had created some efficiencies and they were you using a common component Library repository, but the idea was to actually create one across the brand. And so if you think about a developer in there creating a new page within the web and all the app each time, they were essentially recreating it. And so they have to recreate every button, every link, every template that we were going to use the one person. And it takes $5,000 to create it.
If you put it into a repository and you have this library of assets to just reach into, the next developer maybe takes 15 minutes while they input the code and just test it. And so it was really the way that we sold it into the sufficiency play that stood up that group. That's kind of the way I think about design from a stand-up perspective. And we definitely have that at and have a really great team that's been working on that for the years. They've even named our design system and they're working on the Denali version. But also, when you think of design and the way they plug into product management, it's never done in the same way that our fashion trends change over the years. People's expectations of how things are going to look are going to do that as well. And you can become antiquated really quickly. If you kind of think about the 10-year increment or even the midsection of where things shift over in a decade of what people are expecting. And so you have to constantly have that care and feeding to make sure that you are updating your look that's going to meet and exceed those customer expectations.
Melissa P. - 00:36:24: Nobody wants to do a huge redesign. I feel like that's the kiss of death for so many organizations. What are you doing to constantly stay on top of changing design trends and trying to figure out where to take it? Is that the responsibility of the design ops team? Is that a different team member who would be doing that? How do you incorporate the rest of UX in that?
Melissa D. - 00:36:44: So I'd like to start with the competitive analysis and kind of see what others are doing. We definitely look at other financial services. And I think you want to make sure that you look like a trustworthy brand, right? Is a heavily regulated industry and an expectation that there's safety and security around holding onto people's money. There's definitely a little line you probably don't always want to cross. But we always look at what are the best experiences that we feel are out there that people are doing it, right? And right now, it's safety, it's security, it's simplicity. It's how you're marketing no fees. It's how you're marketing rewards for customer. What's the benefit to them? So there's really, it's really, I would say, the design team that drives it forward, product that implements it. But the responsibility of everyone to understand that this is a big thing that we always need to do.
Melissa P. - 00:37:31: I find that design sometimes gets treated like an internal nice to have. And everybody complains about it. Certainly if they're a designer. I've been seeing a lot of angst on LinkedIn, you know, lately about it. To me, I always started, I started as a hybrid like UX PM. So to me, I always look at things through the lens of UX. Other places do not. I also hear it likened to kind of internal tools and platform type work. So I get reached out to by a lot of platform product managers who are working on internal services. So like some kind of API or microservice. And they have this question about how do I relate back to the business metrics, right? You keep telling me that I need to be able to explain my story and how it drives growth for the business or cost reduction or something like that. I'm just the person in charge of the APIs. How could I possibly tell that story when I don't interact with users? How do you think about people defending the reasons why they should be doing this, whether they're on that platform team or maybe they're on a design team or an internal team? And how do they get leadership to listen to that?
Melissa D. - 00:38:38: I was just talking actually with our enterprise architect the other day about the need for an API product person, someone who really manages and understands what needs to be governed with APIs. And there's just, there's these things out there that I feel like you, you know, it's kind of the Men in Black, right? Where you're working behind the scenes, there's always an alien invasion for anyone who gets that reference, but it's never exposed to the public. And so there's, it's really these foundational items that aren't a problem until they are a problem. I would venture that not every company is so mature that they have beautiful APIs and elegant APIs that load lightning fast and are always running concurrently instead of consecutively and they're doing this. So I would say that it's probably pretty easy to point to the things that are going wrong right now, unfortunately, in an effort to really talk about it and convince people to do it. One of the things that we've had in our past is we didn't always use APIs. And we really thought of channels independently. So you think about the call center, the agents are using the agent interface.
You think about mobile app, the website, even the IDR. And everything was what we called or what we refer to as hard-coded into the GUI or into the platform. The underlying thing that occurs when that happens is you start to put in things like calculations. And so when you are displaying a savings rate or an APY or a credit card interest rate, when it's calculated in the GUI, you run the risk of either it breaking or it being out of sync. And now you have a reg violation. And so when you think about the benefits of how you can move to microservices or move to API based architecture, these are really the things that you want to find in site. And like I mentioned, they probably exist today, it takes a little bit of time and it takes someone who is passionate about this as you. But you go in and you find them and you show where the issues are. And you show that a lot of obviously regulated industries have compliance issues and you're bound to have one of those pop up.
Melissa P. - 00:40:41: That's a really good way to justify it. I think everybody's concerned about compliance when it comes to finance. One topic I wanted to talk to you about too, before we close out is you are a chief product officer in a bank, FinTech. This role I think is finally starting to pop up more at our large financial institutions, which is fantastic. But there are still a lot of people out there. I think that don't understand the difference between like, why would I need a CPO here versus having a CTO or a CIO? Like, can't they handle it? How do you think about your role compared to those other roles? And why do you think it's important when it comes to financial services companies or FinTechs?
Melissa D. - 00:41:21: I would say, you know, product management has different spots in different financial institutions and different companies, as you had mentioned. Sometimes it rolls up to the CMO. Sometimes it rolls up to the chief digital officer. Sometimes it rolls up to technology. And it's kind of still, I would say, maturing product in its form today to really find its place. And I think the companies that you can point to and say that there's a CPO is the first thing I would mention is they're taking product seriously. And that's really refreshing to see because we just had our product offsite last week and we got together, just the product team. And talked about who we are, how we want to show up for our customers, how we want to show up for our internal stakeholders. And one of the questions I asked them was, what do your friends and family think that you do? And hearing them say, you know, one of them was like, I'm a risk analyst. And one of them said, I work in technology. And one said, I work in the help desk. And it's really fantastic to get together as an organization of people who self-defined run around like a chicken with their head cut off, trying to get everything to get together and understand that we're taking this seriously and the product is a serious role. Any advice or lessons learned that I would give out to anyone who's looking to maybe stand up a more formalized product structure is, you have to understand what product is going to deliver.
And traditionally we kind of had the business working side by side with technology and we had an IT centered organization where they were very just sort of ingrained in the business strategy. But when you have people who are maybe just telling others what to do, you don't get the quality product that you want. And product is really the creative solutioners, the creative problem solvers, the people who say the easiest solution is not always going to be the best one. And so we're going to take a minute. We're going to involve the people that need to be here. We're going to find the best path forward to deliver the best customer experience with the highest quality. In a nutshell, that's how I would describe our role and the seriousness that I believe that taking on this responsibility of building these customer experiences. But it is, it's truly, it's here. It's not something that I think is a fly by the seat of the pants. We have an entire model in transforming companies to rally around it. But I really think it's the maturity of an organization. And that's kind of the ones that I'm hoping we kind of meet the way for.
Melissa P. - 00:43:37: Me too. And I hope everybody listens to this podcast and realizes that it is a critical role and they should be hiring more people like you to lead it. So thank you so much, Melissa, for being on the podcast. If people want to learn more about you, where can they go?
Melissa D. - 00:43:49: I would say probably LinkedIn is the best way to go. It's got a very detailed history of my role. And I'm always open to talking to people.
Melissa P. - 00:43:57: Great. And we will put all those links to Melissa's profile and also to Green Dot on our Product Thinking Podcast website. So go to productthinkingpodcast.com and make sure that you subscribe so that you never miss an episode. We'll be back next Wednesday with a great guest and we'll see you then.