Episode 166: Intentional by Design - Building Careers, Teams, and Technology That Work
The Meridian Point Podcast
Guest: Patricia O'Shea, Senior Director, Product Management, ADUSA
Host: Kumar Dattatreyan
Kumar: Hi, everyone. Kumar Dattatreyan here with Meridian Point. Today we're joined by Patricia O'Shea, a customer-obsessed technology transformation leader who spent thirty years turning the "why" into action. Patricia's journey started in the most unexpected place -- raising funds for cancer research through telemarketing -- where she discovered that connecting people to purpose is the ultimate catalyst for change. I can certainly attest to that in my experience with change transformations.
From there, she's navigated through enterprise digital transformation initiatives, stood up transformation offices, and made a deliberate five-year career pivot from leading PMOs to becoming a product management leader. Patricia brings a rare combination: the urgency of customer centricity paired with a strategic vision to simplify the complex. She's here to share how she disrupted her own career path and what it takes to help teams see technology not as an end, but as a means to make people's lives easier.
So without further ado, let me bring Patricia on stage. Hi, Patricia. It's great to have you on the show.
Patricia: Hi, Kumar. It's so good to be here. Thank you.
Kumar: Of course. So in a prior conversation we had getting ready for this episode, you shared that transitioning from PMO leadership to product management took deliberate effort over five years. And as part of the intro that I just gave, some mentors doubted that you could do it. So walk us through that journey. What was the catalyst for wanting to make that change, and what were the pivotal moments that made it possible?
Patricia: Sure. So there was a significant part of my career that was related to program management or PMOs. I was a project manager. I was a program manager. I was leading PMOs. And it was something that was serving me well. I was good at it. I had risen to a senior director level.
But then I moved into a new role working in PMOs at Cars.com. Cars is a technology product company building custom solutions that connect people who are buying cars to people who are selling cars. So I got exposed to what it meant to do product, and I realized that I wanted to do that. Instead of orchestrating the product work that others were doing, I wanted to do it directly.
Now, I did have a challenge, though, because I had gotten to a point in my career where I was really very specialized. And when I talked to the product leaders around me, many just couldn't see it. They saw that I was very good at program management, but couldn't imagine that I could do product. And I didn't have the experience either.
But I sat down with our chief product officer at the time, who was great to spend his time coaching me. Basically, what he helped me see was that there were many skills that I had that were transferable. Based on his coaching, I took a look at the types of skills that product leaders had, put that up against the skills that I had, and then recognized what I needed to develop.
In addition to that, I decided to go ahead and take a product management course just so I could get those basics and be sure that I understood exactly how it worked. Then from there, I looked for roles that were going to develop the product skills that I didn't have yet. And those were not roles that actually had "product" in the title. They were adjacent -- roles that were very strategy-focused, or roles that were in some cases related to helping product teams be more effective. So those were the first steps.
The other thing that I did, though, and I think this is really, really important -- and whenever I talk with people on my team or anyone who wants my help around career development, I talk about this -- throughout the whole time, I had my own individual development plan. That plan was keeping track of what I was deliberately developing as far as my own skills at any given time. But what it also did was give me a platform to have conversations with others about what I wanted to do, how I was preparing for it, the skills that I already had, and what was my ideal situation for a job. I was using that to talk to all kinds of different product leaders.
Another thing I think about development and career is that a few things have to come together. You have to be ready. The role has to be open. And the people who are hiring have to know about you. For the role that I'm in now, all of those things came together, largely because I used my development plan to have a conversation with the product leader who turned out to be hiring. And now I am leading a product team.
Kumar: It's quite amazing. So everything was really intentional for you. You really thought about it and had a plan. You created a plan through the help of the leader of product, maybe in the company you're in now or maybe a company you were in before. That doesn't really matter, though. What I think is important is that you had a mentor who believed in you and believed that the skills were transferable from PMO project management to product management and leading product teams.
Can you elaborate on what some of those skills are that you felt, or maybe the mentor felt, you needed to develop? And what were maybe an example or two of what was transferable?
Patricia: Yeah, so what I think was both interesting and astute is that my mentor did not tell me what skills I needed to have. What he suggested was that I go out onto LinkedIn and look at different people who have product titles -- look at their background, the types of roles that they played, the skills that they had -- and then start to do an inventory against what I had. That just kind of opened up my imagination. I think it also gave me some flexibility.
After I did that, some of the roles I played where I developed the skills -- and this was across multiple companies, so this definitely took some time -- but one was leading an agile center of excellence. I think agile is more about delivery. It's not necessarily about product, depending on how you're applying agile practices. But what it did was help me look at what was almost a product itself, like agile delivery and agile practices, and find where in the company was that needed. Where would it solve a customer problem? So that was using that product mindset in a role that was adjacent.
Another example is working as a business relationship manager, which many would say is the exact opposite of working in product with agile ways of working. I don't really agree. But being in that role, one of my responsibilities was to work with business leaders to develop strategy. How could we use technology tools to solve business problems? So you're probably starting to hear some repetition in the words that I'm using and the spaces that I was playing in. Those are just a couple of examples of where I built some of these transferable skills.
Kumar: Yeah, I love the way you put it. What I'm getting is that being more involved in product means you're looking at ways to solve problems. You're thinking both strategically and viewing things like the agile center of excellence as a product. What are the problems that product helps solve? And how can you view it as a product to think more strategically about how to utilize the people and the processes that come with it to support the organization and their transformation goals?
I really like that. That's what a product mindset is all about, right? What's the problem to solve, and how do you think about those things in a more strategic manner?
So would you say that maybe project and program management is more about the execution details that somebody else has created a strategy for? And when you started to look at what you needed to build in terms of your skills, it was really to zoom out a little bit? I think product management is more about what are the problems to solve and how do we approach that in a more strategic manner.
Patricia: Yes. And I don't want to discount my program management experience. In fact, I think that was critical, because if you think about working in product, you are responsible for not only working across teams and with your customers to understand what problems you're solving and how you might solve them, but you also have to deliver something. Having that delivery skill set -- knowing what it takes to deliver technology -- is a huge part of product. You can't be successful if you don't do that.
Kumar: Yeah, for sure. The company I'm supporting now is transitioning to a more product-oriented, product-led mindset. It's a tough transition, especially after being in more program and portfolio management-led environments with lots of little projects that have their own demands. But I think part of the promise of moving to a more product-led organization is that you start to see the connection between projects a lot more clearly. Would you say that is true?
Patricia: I do. I think that's true. Even in my work today leading a product team, we have projects. It's just that projects are a delivery method, and sometimes using a project to deliver makes a ton of sense. But I think you can still apply that product mindset of knowing what's the value that we're delivering, what does success look like, what is the outcome. Are we very clear about that and about how we're going to measure it? And then sure, you can use a project to deliver that if you need to.
Kumar: Yeah, I mean, the method isn't as important as people being aligned. They understand what the end goals are, the outcomes they're shooting for, and the mindset to get there. The delivery mechanism is not as important. We do get caught up in that, though, don't we?
Patricia: We sure do. And I don't think it's the most important thing. It's important to do it well, but it's not the most important thing.
Kumar: Yeah, I've met lots of project and portfolio managers that are amazingly talented, incredibly collaborative, and more agile than many agile coaches I work with who are more concerned with the semantics, the words, or the ceremonies. Those aren't all that important in my view. It's more about the people and how aligned they are in terms of understanding the mission, vision, and purpose of the work they're doing and the problems it hopefully solves. And having a mechanism to iteratively look at the data coming back from releases to see if it's actually solving the problems we set out to solve -- whether through a project method or an agile iterative method or some combination of the two -- it doesn't really matter.
Patricia: I think that's a really important point -- checking along the way regardless of how you're delivering something, because everyone has heard and many of us have experienced work where you set off to do a project and you're not measuring along the way. When you get to the end, you realize that the value you thought was going to be there isn't. You don't want to learn that at the end. You need to learn that while you can still pivot.
Kumar: Absolutely. One hundred percent agree. That's one of the things about agile. You probably know this -- the creator of the waterfall method, I believe it was Winston Royce. He wrote the paper back in the fifties about the waterfall method, and on the second to last page, he said that if you don't incorporate iteration in this waterfall process and continuously go back and check to make sure that what you did is actually what you want, your project is doomed to fail. I think people didn't read that page.
So anyway, I'm fascinated by your early career in cancer research. Working for a nonprofit gives you a sense of purpose, right? Purpose is very crisp, very clear. People who go work in an organization like that -- my wife works at a homeless shelter, and the purpose is very clear. The problem to solve is homelessness and how to provide people who are suffering a way to get back into a home and get a job. In corporate environments focused on profit, purpose can be hard to find.
So how do you help teams in large organizations connect with the people they're supposed to be building these products for in a way that is tangible to them?
Patricia: That's a great question. I think it's important to start by knowing your own purpose. The reason I say that is I'm very customer-focused, and the reason I'm customer-focused does tie back to those nonprofit roots. My purpose then and my purpose now is helping people. Helping people comes to life in many different ways, but that is very real for me. It makes it authentic when I am tying back the work that I'm doing or the work that my teams are doing to customers. And defining customers very broadly -- customers being anyone who's using what you're building. So I think that's the first thing.
Tying back to your customers, however you're defining that, is critical when it comes to purpose. Many of us work in very big companies where technology teams just don't have interactions with customers as part of their natural day-to-day. But if you think about it, there used to be a television show -- I can't remember the name of it -- where CEOs would put on some sort of disguise and get up near their front line. They would see what their customers were experiencing, what their employees were experiencing -- which, by the way, are also customers. And that made it very real.
To connect purpose to teams who are building solutions that serve people, you have to bring that people element. That means either getting them out of the office and bringing them to where the customers are, or bringing the customer stories back -- videos of customers talking about using your product. Anything that can personalize the work.
Now, that's not the only type of purpose. There are lots of different purposes. There was a time when I was working in almost a chief of staff role, and I did a lot of offsite work where I was setting up events. I was able to go to different hotels and figure out which one was going to be right for whatever environment I was trying to create. The company was working to save money and brought in a new program where we had to go through a team that would source hotels. For me, it really constrained what I was able to do. But when I found out how much money it was going to save the company, I was okay with it because there was a greater good, which is a purpose.
I think anything you can do to tie for your teams what's the "why" -- why are we doing this, what's the purpose -- it just helps, especially when things get hard.
Kumar: That's really the key. I think a lot of the people who are the doers, the people building the products, may be five, six, seven levels removed from the customer. It's finding a way to connect them to that customer so they can feel their pains and revel in their gains when these products are actually serving the purpose they're intended for. They get to take part in celebrating what they've created.
And that is increasingly harder to do in today's remote-led environment, especially in companies where some percentage of the teams building products are contract workers who are brought in to build something and then let go. All that knowledge disappears with them.
What is your experience there, and how do you help build more stable, cross-functional, long-lived teams?
Patricia: That's a great question. I feel like I am fortunate in that when I joined the organization I'm in now, we already had standing teams, permanent teams working on e-commerce. Of course, like with any team, you're going to have some people coming in and out, and we do use contractors when we need to increase our velocity in any certain area. But I am fortunate to have a steady team.
That hasn't always been the case, though. What I would say is this: one thing I see with communications -- and I can do this myself if I don't remind myself -- is we tend to communicate something one time and then expect that message is going to remain on everyone's minds. When you have people coming in and out of a team, that definitely doesn't work because they might not have even been there the day you shared the message.
If you're wanting to motivate a team and keep them very customer-focused, you just have to keep bringing that message back in different ways. Bring back the fresh stories. Take a minute if you're working with an app to go to the app store and download some of the reviews. See if the tone and tenor of those reviews are changing. Whatever you can do to keep it fresh and top of mind. That's really all you can do when people are coming in and out.
Kumar: That's a really good point, and I don't think companies do enough of that. You're right -- maybe in the beginning it's done: this is the product, these are the people, these are the personas, and this is what they do. But it isn't something that's repeated, especially when people leave and new people replace them. They don't get that inoculation into the culture of what they're trying to create or the products they're building.
It requires leadership and communication to bring that clarity about who the customers are. Something I need to think about, too, is that as leaders, we shouldn't get too frustrated when people don't know what they're building or why. It's probably because we haven't made it clear enough. That's a signal that maybe we're not communicating it enough, or in the right manner, so people can rally behind it. Creating alignment really takes work.
Patricia: It does.
Kumar: Have you ever heard of the marathon effect when it comes to leadership and communications?
Patricia: I haven't heard that term.
Kumar: So the idea is this. If you're in a leadership role, before anything new happens -- deciding to start looking at a new product, or to bring in a new technology system, or to reorganize a team -- before any of that happens, you're having conversations typically with a smaller team. That goes on for some time before the moment you're ready to start talking with the broader team and introducing the vision and the change.
It's like a marathon. With marathons, big groups of people are running, but they don't all start at the same time. The people who start at the beginning have already run the course. They've already seen where the great water station is, and they know how long it is until the next pit stop. The people behind them haven't gotten there yet. They haven't seen it.
As leaders, sometimes because we've been in the conversation longer, we forget that we have to really remind, communicate, and keep reinforcing. I use change as an example here, but I think that's just a constant -- an absolute constant if you want to keep everyone rowing in the same direction.
Patricia: Yeah, that's such a good point. I love that metaphor. Just because I've run the race doesn't mean that anyone else has. They don't have that experience. And so it's worth remembering.
Kumar: I'm going to go back a little bit in your career past. Most technology leaders come up through traditional IT paths. For me, I had a really unconventional career. I started in restaurants, then went to IT, was a developer for a while, and went into leadership roles. But I have to say that my restaurant experience still guides me today. Everything was confined within those four walls -- everything you would consider part of a business. You've got marketing, sales, business development, product. Your product is the food you serve. Everything, every minute of every day. It really prepped me.
You started raising funds for cancer research through telemarketing. That's quite unconventional, probably like my start in restaurants. What did you learn in that role that still shapes how you lead transformations today?
Patricia: Many things. I would love to say that this was intentional, but I wasn't one of those college students who knew what she wanted to do. What I did know is that I needed spending money. In my senior year, I was working as a student supervisor for this telemarketing organization. This was a while ago, so we were picking up the phone and dialing and using note cards to record any donations we got. It was a very manual business at the time.
As I was graduating, there was an opportunity to broaden the space we were working in. We were working just for the state of Michigan, and there was an opportunity to work nationally. But you don't raise funds nationally through telemarketing by picking up the phone and using note cards. You do it by having a sixty-seat, multiple-shift telemarketing center run by an automated dialing system with scripts on the screen.
I was just graduating, and my manager built the business case for us doing this. My first job became helping her open this center and manage it. It was kind of a startup atmosphere -- "I'll do this, you could do that." Even though all the technology experience I had was word processing and writing my papers for school, I became the person who was going to administer the automated dialing system.
So that was the first lesson, because there are at least two here. The first lesson was: even if you don't know how to do something, you can lean in, you can learn, you can do it, and it might shift your career in a way you never expected. I never thought that I would work in technology for my entire career, but this is why it happened -- because I said yes to running this automated dialing system.
The second thing is, what we had when we were raising money for cancer via telemarketing was a very clear mission and a very clear purpose. It wasn't about building this new center that used technology that was cool. It was about how can we be as effective as possible at raising money for cancer research. The technology just happened to enable that.
I think it's very easy to get caught in technology for technology's sake, but you absolutely have to ground yourself and remember that there is something you're trying to drive, some sort of outcome, and the technology is an enabler of that. That was the second lesson.
Kumar: That's fantastic. I love the way you put that. Speaking of technology, you've observed in our last conversation that it often runs ahead of people's ability to consume change. AI is a great example of that. You also mentioned that we don't really do hands-on training anymore, at least not the way we used to. We just expect people to figure things out on their own because systems built today are more intuitive. "Just go play with it and figure it out. Let me know if you have questions."
Is that working? What are we losing by not spending more time with people on technology change?
Patricia: I think we're leaving a great deal on the table. Before I was doing project management and getting into PMOs, my roots were really change management. After I worked at the telemarketing center, I started delivering training for Microsoft Office and then started writing training, and that turned into change management. That's why I have such a strong point of view on training.
When I was teaching Microsoft Office, these were adults who had very little computer experience. I would come and show them everything that Microsoft Word could do, all in eight hours. It was incredibly overwhelming for the people in my classes. When they came to me and said, "Thank you, it was great to learn these things, but I don't know how much of this I'm going to remember and be able to apply," what I would say is: half the battle is knowing what this tool can do. If you know what it can do, and I showed you how to use the help, you can use the help or your help desk and figure out how to actually do it.
I started saying that right at the beginning of the class because I realized it would be more useful if they came in with the mindset of "listen for the capabilities, don't worry too much about the step-by-step today, just know the capabilities of this tool."
It's completely relevant today. My dad wasn't very handy -- this isn't about my dad -- but I never got to watch anybody replace a garbage disposal. I did it a few weeks ago myself because I was able to go out to YouTube and get a video and watch someone do it. At work, if you know what the capabilities are of the technology tools on your desktop, you can go into Copilot and get help. You don't even have to ask anyone. It's all elevated now.
But I think what we're missing, and what training gives you, is knowing what the capabilities are of the tools. Microsoft is rolling out new features for Teams and other tools all the time. I see technology enablement teams that publish articles about the new capabilities, but I just think we miss that. We're busy. We're not reading it. But if you get sent to training, you're going to learn what the capabilities are, and then you can teach yourself and really extract all the value out of the tools.
I think assuming that everything is intuitive and that we're going to get the value by just letting people have at it by themselves is very wasteful. Like I said, we're leaving a lot of value on the table.
Kumar: Yeah, I agree. We are living in an age where you can learn just about anything. If you want to learn how to install a disposal, there's a video out there. There are probably hundreds of thousands of videos showing you how to do that. If you want to learn about AI and how to create agents, there are thousands of videos on that. There's tons of material out there, and of course there's Copilot, Claude, ChatGPT, and all these other tools.
But the key is, to your point, teaching people how to learn -- not teaching people what to do, but teaching them how to learn. Especially in today's world, the knowledge and learning opportunities are so vast that it can be overwhelming. Some simple things to teach people how to learn can be really helpful. And giving people that spark, that reason to go spend their time -- which is limited for everyone -- going out and learning with all of these resources that are available. You have to give people a reason to spend their time that way.
Patricia: Yeah.
Kumar: I want to end with a question and maybe a few fun questions toward the end. Your LinkedIn colleagues describe you as someone who simplifies the complex. In our world today, we have a framework for everything. We're drowning in them. How do you cut through the noise and help people see what actually matters?
Patricia: My answer is almost too simple. I feel like you're looking for something really big that I don't have. But I think when it comes to simplifying, for me, it's about using simple terms. It's about giving people something they can grasp onto. The thing about that, though, is in order to simplify something that's complex, you do have to take time. You have to think about what you're going to say, how you're going to say it, and sometimes you have to practice what you're going to say. I know that I invest time in that.
But the second thing -- my personal trick, and I certainly didn't come up with this -- is to use analogies. Especially if you're working in technology, use analogies. I have found that you can explain almost anything in technology by using a house analogy. I do it enough that I wonder if the people around me get annoyed. But I see the light bulbs go off.
For example, one of the reasons I recently asked a team to look at risk and where they might have risk in how we're working every day -- I used a house analogy. I said, you could buy a house that was rehabbed and it looked absolutely beautiful, but then all of a sudden you have a pipe burst. And then you're going to start wondering, "What else is it that I can't see in this house? Maybe I better go take a look and see -- is the wiring okay?"
So, a house analogy for looking at technology operations and whether we're operating with the highest level of quality that we possibly can. It works every time, I'm telling you.
Kumar: Yeah, I love that. I'm going to use it.
What would you say is the biggest misconception companies have when they try to shift from project-based thinking to product-based thinking or operating models?
Patricia: I think the biggest misconception is that product operating models are just another way for technology teams to do their work. Here's what I mean by this: a company that is truly working with a product mindset is not thinking that this is just a technology thing. They are thinking that this is a company thing, because in order to build a good product, you need to work across multiple groups within your company. You need to be close to the customer. You need to be driving towards outcomes that are company outcomes.
It doesn't happen just within the technology team. It's not just how tech works. I think that is one of the biggest misconceptions. My company is good at it, I think, but I have seen some companies that have put that line in between, and then it really just doesn't get you the outcomes you're looking for.
Kumar: Yeah, absolutely. One hundred percent agree with that.
Best career advice you ever ignored?
Patricia: That's a great question. I don't tend to ignore advice. I really don't. I would say that who I am today, the things that I do today, are completely built off of what I've learned from others. I'm always watching for models, whether it's a model of how someone's leading or a great approach to solving a problem. I'm always looking for those models. I honestly can't think of specific advice that I've ignored. I do really listen and take it all in.
Actually -- okay, so this wasn't advice exactly, but I ignored an opportunity, which is maybe advice but a little bit masked. When I was earlier in my career, my manager needed someone to help him with all things finance -- budget and all of that. And I just said, "Please, please do not give me that. I'm not good with numbers. I don't want to do finance. Please just give it to someone else."
And no one gets away from that. You never get away from that. So I really missed an opportunity to learn in a very low-pressure way about how we were financing the business. In giving me the opportunity to take the assignment, his advice was "learn this." And I ignored that.
Kumar: Yeah, I have similar stories that eventually caught up to me. I just would have been ahead had I done what was suggested years before.
Patricia: That's right.
Kumar: All right. AI -- we have to get to the AI question. Overhyped or underhyped right now?
Patricia: So when you and I first talked, I said overhyped. It's moving so fast that now I'm at "right level of hype." I've changed my mind.
First of all, just seeing the pace at which things you can do with it are coming online and making themselves available to everyone. It's just very democratized. I think that's amazing. And then the other thing that's changed my mind is I've seen companies, when they're talking about AI and AI capabilities, being smart about it -- saying we need to make sure we have the right data foundation, we need to make sure we're not automating broken processes, we need to be somewhat surgical in where we're testing to make sure these investments are going to deliver value and we're not going to try to just apply AI to everything.
So between seeing the pace at which it's developing and the pragmatic approach that many companies are taking, I feel like it's getting the right level of hype.
Kumar: Yeah, that's great. I wrote an article recently on AI and transformations, and it echoes some similar themes. I'd love your feedback. I'll send you a link to it if that's okay.
Patricia: Absolutely.
Kumar: All right. One last fun question. If you could go back to your nonprofit self, your nonprofit days, and give yourself one bit of advice, what would it be?
Patricia: I don't know that it's about my nonprofit self as much as my just-starting-my-career self. I would tell myself to be much more deliberate about career planning and development than I was. I shared with you earlier that part of the reason I work in product today is because I figured out over five years ago that that was what it was going to take. Had I figured that out earlier, I think I would have had even more diverse experiences across my career because I would have been intentionally looking to do lateral moves that would develop me, and I would have had a much stronger network earlier in my career.
I think that kids today -- I have a college student, so I'm allowed to say "kids today" -- when I look at my daughter, she is set up much more so than I was to do these things. But my advice is: own your career. Don't look to anyone else to do it, and spend the time, because it absolutely does pay off.
Kumar: If there's one thing that really resonated for me -- well, there are many things -- but one that really stood out was your intentionality. Whether it happened five years ago or before that, just the level with which you are intentional about your career. That's something I'm going to have to think about more for myself. And hopefully others watching the show will think about that as well for their careers -- how they've gotten to where they are, is that where they want to go, and how intentional are they in planning for their future, no matter what stage of career they're in.
Both my sons are older than your daughter, and I don't know that they're doing that. I'm going to encourage them to watch this show.
Patricia: And if they ever want to talk about career, I'm always happy to do it.
Kumar: Oh, that's wonderful. Anything I haven't asked you that you'd like to share?
Patricia: No, I just want to thank you for having me. This has been a great conversation. I always enjoy talking with you. Thank you for having me today.
Kumar: Thank you so much, Patricia, for coming on the show. I hope you enjoy this episode. There will be some links in the show notes on how to get ahold of Patricia. By the way, do you go by Patricia?
Patricia: I do.
Kumar: Patricia. And some of the links that we mentioned in the show as well. So thank you so much for watching, and see you next week. Bye-bye.
Patricia: Thanks. Bye-bye.
