S1E1 | How We Got Started and What We Hope To Achieve

Intro
Three, two, one, go. Hey, I'm katie. Hey, I'm Chris, and welcome to the Product Versus Engineering podcast.

Katie Welker-Muraguri
Hey, thanks for joining us. Before we hop in, just a few things. First things first. This is the very first episode of our very first podcast, so count it as our first pancake, as Chris would say, or our MVP for everyone else. It's going to be awkward and it definitely won't be perfect, but we believe you'll find value in our conversations, and we hope you continue to listen. Second, we'll be releasing on a biweekly cadence every other Thursday, so make sure to find us Thursday mornings on Spotify or Apple podcast. Lastly, thanks for taking the time to listen. We truly appreciate it. All right, let's hop into our conversation about how we got into product in engineering and what we hope to achieve with this podcast.

Chris Welker
So, Katie, how did you get into product?

Katie Welker-Muraguri
So, I got into product by chance. I started a sales and marketing position and quickly moved into a brand management position for a paper company. I was there for a few years and was thankfully mentored by women who were other brand managers and marketing managers. And in the time that I worked for that company, I realized that I needed to get into technology. So a few years after I took that job, I interviewed and moved into technology. And that first job I had was as a quote unquote, product manager. Then from there, I worked in a number of different spaces industries telecommunications, fintech, property management, software, most recently doing consulting for Digital Experience Agency. And then now I'm in the security space. I've been in product management for about 14 years, and it has been one of the hardest and most rewarding jobs I've had.

Chris Welker
What's rewarding about it?

Katie Welker-Muraguri
I love to create new things. Create a product from zero to one is great. Even though I didn't realize in the beginning, because it was so hard, I hated it. I was like, Why do I keep getting projects like this? But then I started to appreciate it when I got into Spaces, where I was just maintaining a product. And that, to me, is not as entertaining, not as fun, it's just not as stimulating for me. So coming up with new things, figuring out how to make them, if it's a brand new product for an organization, teaming up with engineering to understand how we can actually do this, and then to see it come to life and people actually use it, that's the best feeling. And then, of course, working with all the people who make that happen, because as a product manager, where they say they call you like the CEO of your product, but that's not true. Let's just wipe that off. It's about influencing other people, creating partnerships to get work done. And it's one thing that I pride myself on throughout my career, is to be able to do that, to get things done.

Chris Welker
What were the skills that translated from brand management to product management? How do you make that leap? They're not different disciplines.

Katie Welker-Muraguri
They're not vastly different. When I think about brand management, I was managing like physical products and there was a broader brand and then there were smaller brands underneath the organization that I work for. But within those brands, there were tons of products that needed to be managed and essentially you're just managing those to elevate that brand or whatever the outcome was. So I was responsible for pricing, which is typically something you're responsible for as a product manager. I was responsible for positioning. What's the value proposition? Like all of the normal stuff we deal with as a product manager, I dealt with as a brand manager.

Chris Welker
At that company.

Katie Welker-Muraguri
Yeah, at that first company I worked for, all of those skills, even the marketing side of it, have benefited me in product management because I, for majority of my career, never worked with a marketing person. So like a product marketing manager, as people know them as today, I never had access to those people unless I was inside of a very large organization. So majority of the time I was thinking about the marketing piece, about how I would position this in the market, how I would sell this to a customer, that sort of thing. So I think all of that just made a natural kind of it just naturally translated the product and I still use it today.

Chris Welker
Interesting. Yeah. So all the GTM, all that stuff that you use back in the day is super beneficial now. The only difference here is switching out the product being delivered essentially the same skills for you.

Katie Welker-Muraguri
Yeah, I mean, sometimes I equate that first job because it was a manufacturing it was like a physical good. Right. So paper products and thinking about those machines that manufactured the products in relation to machines that we use or code that we use today to create products. Right. And typically what I say is that those machines were limited in what they could do. Right. Because either if you wanted to do something new, you had to buy something to add on to machine or buy a brand new machine. Hugely expensive. So I can still draw similarities between the two. But yeah, I mean, trade out the paper product for another product, financial transfers, whatever it is. Right. The same principles exist.

Chris Welker
Do you think the user demographic is different? How do you think about that in relation to that kind of switch from brand management, which was brand management, quasi product management, and switching over to purely what people call traditional, kind of the traditional product management role?

Katie Welker-Muraguri
I don't think about it very differently in terms of the demographics, like the users. Because who is your customer for a paper product? Who is your customer for a money transfer? Right. Those are totally different demographics. It doesn't matter whether it's manufactured or it's technology. So it's still the same principle of knowing your customer, knowing what their problems are, and understanding how you can solve those with really good products, whether it's a physical thing or it's a technical thing, tangible or intangible, whatever. Right. Yeah. I think a lot transferred, and I think that job thankfully set me up for really good success in moving into product management.

Chris Welker
Cool.

Katie Welker-Muraguri
All right, chris, how did you get into engineering?

Chris Welker
I think I was on the cusp of the kind of, I want to say the digital transformation, because that really started much earlier than me, but the cusp of the Internet as we know it. And so, you know, kind of I span this kind of very analog world to a very kind of digital driven world. Right. So this is like the early ninety s, and I really like computers. I had always liked computers from very early age. I was exposed to them very early, and I think that it just kind of molded me into always wanting to do so. I didn't think of it much as a career. I didn't know what I was going to do when I started college and then eventually found a group of friends that were really into kind of some of the early Internet stuff, and so got into that and really started to kind of want to learn everything. So I started to learn as much as I could. Eventually left college early and got a job as a system administrator, building computers, working on networks, that kind of stuff, when everything was accustomed build, and then eventually made a shift of I want to learn how to program. I'd always been interested in it, and I think I'd taken some program classes. I tried to take them to college and didn't really get it. I don't think I was in the right frame of mind at the time to really understand it. For me, it works by I have to have a problem to solve, and then I can go figure out how to do it. I can't, like, learn in the abstract without a reason to understand it. So I think that's why I wanted to play games with my friends, so I had to figure out how networking worked. Right. And so that kind of really molded and shaped my career, and I just kept learning. Every book, like every Friday was spent walking through Borders or Books a Million, looking for books to read that I would read over the weekend, can apply in the next week. Right? And that's how I tell myself the program and I set out, and I'm going to go get a job the program. And that's what I did. And that's what I've been doing for the last 25 years and worked at a lot of small and big companies to get just really great experience seeing things at scale, seeing patterns, kind of understanding that. I would say those are the different educations that I've had over the last, really, 30 years or 31 years. Really, every job has been a different education, and that's what I look for out of those particular jobs. What am I going to learn here? What am I going to get? How does it move my career forward? Like, if I would have graduated from college in the mid nineties, I wouldn't have learned what I used on a day-in and day-out basis anyways, because what's taught today versus what was taught then are not the same thing. Right. It was very much about managing systems, not managing not writing software. You could do it. There are definitely classes to do that. But it was very computer science, and I have a deep appreciation for computer science folks. I think a majority of the software built is really around business enablement or as a product and that kind of stuff. Right. I think real computer science, like real hardcore computer science work is done by technology companies where technology is their business versus most companies. Most companies that most engineers work are generally services company and providing a service, and we use technology to deliver it. Right? So I don't think I could do the low level, the low level bio stuff that people do, but I can certainly build systems and scale systems, and I think that those are just two different skill sets. One of my very first jobs was with an engineer that wrote the BIOS for the PS Two. And like, I'm I was definitely not him. And it was clear I was never going to be like that. So, you know, I just focused on what I was good at, which is enabling services through technology. And I've been super fortunate throughout my career to land in good spots and work with some really good people, and that mentored and helped me grow to this position.

Katie Welker-Muraguri
When did you realize after you started studying and teaching yourself that this was the direction you were going to go? This was the career you were going to make for yourself? How did you know that?

Chris Welker
I don't think I knew. I mean, I happened to be good at it. It wasn't like you sit with a college counselor and you're like, I want to go write software. It wasn't that. I had a bunch of friends who were really into this. I picked it up really fast. I think that's the thing that's benefiting me the most. There are definitely times where, I mean, today I'll be talking to an engineer, and they'll be talking about patterns, and I don't quite know the name because there's a name for a lot of these things. There's books on these things. I don't quite know the name if they describe it to me. Yeah, okay, I got it. Right. Sometimes I have to have people slow down and kind of explain, oh, okay, I got it like I've seen them, but I don't necessarily know. Right. And so that's what you see. I think it's kind of interesting. Before this became the job to have like an engineering job to have, it was just people that wanted to be really good at this kind of stuff. And now people are going to college or learning how to program. They're coming out of college with the skills that I had to acquire on my own. Not had to, but I chose to acquire on my own. So there's definitely gaps in that kind of stuff. Like, I see it, but at the same time, I come with a mindset of I can learn whatever it is I need to learn. Right. And I think that's just by me going through that process of not not having any real classical path to technology and to these particular roles, in some ways it's helped me. Right. The meandering system administration to engineering has really helped me understand and really been beneficial to me over the last 20 plus years. So of what you learned early in your career, how much of that are you using today? I think principles generally hold true. I think what's interesting to me now is that a lot of newer technologies or ways of building things in the world today are rehashes of older patterns. An example of this would be single page applications. Everybody's very high on angular react and all this other stuff. And that's really just client server all over again. With a better distribution method, you don't have to distribute an exe anymore. Everybody's got Chrome or everybody's got Edge or whatever your browser of choices, and they could just run the application in that. But the pattern is no different. And I would also argue the pattern is no different and the constraints are actually really no different either. And you still need to pay attention to the same things you were paying attention to. Right. And that's the part where people get twisted, is when you don't pay attention to the basics. You're running in a constrained environment. There is a limit to what you can do. You need to be smart about how you get to the outcome rate. The design principles generally hold. I don't feel like the designs are all that different. The technology is used to achieve them, sure, but the principles always hold right. And then it's using the principles and the gotcha of those principles to help educate engineers about, well, we should be thinking about this differently, or what's really important. We're talking a lot about these days, we're talking a lot about acid and atomic transactions. And a lot of people are just like, oh, well, it'll eventually get there. I'll go do 100 transactions, or something like that. And it's like, that's not a pattern. You want to be depending on the industry or depending on the software you're writing. That's not necessarily a pattern. You really want right. So, I mean, they're all situational. And I think that's the part that I use the most these days. What pattern fits the right use case and the patterns that will scale? Because I had a long list of a bunch of patterns we tried that just didn't work at scale. So those are the things that I generally hold, like languages. I've learned so many at this point. I may think in one language, but I can do it in another language. Right. You kind of always tend to think in the first language you learned, but generally they all have the same stuff. There's a few net, new ones, go scala, things like that. But again, that's just functional programming versus kind of like this object oriented programming stuff.

Katie Welker-Muraguri
So when did you first work with product management in your engineering career? What was your first introduction to product?

Chris Welker
I don't know. At least in my lifetime. I think product didn't really exist to me until maybe 14,15 years ago. Right. There was a lot of business analysts. That's what you had early on, business analysts. Right. What should the software do? It's a similar function. Maybe not exactly the same because I don't know if they're building businesses. It's a supporting function to a builder of a line of business. Right. I think as more and more startups and that kind of stuff, it's blended into you own the business and you own the expectation of developing the requirements. I say that. And people don't like that word anymore, but that's really what they are. User stories. Is that better? User stories. Call what you want. It is what it is, you know what I mean? Yeah. The requirements and developing those requirements. I've always been with somebody. Right. And I would say when I got more direct to consumer product more Internet. Internet? Well, no, they've always been kind of Internet focused. It's always been around business analysts and those business analysts, those folks that fit that had moved over to kind of product management. Yeah, it's really interesting. Business analysts, they still exist? I think it depends on what you're I don't know. At the end of the day, the thing is we need to somehow translate a business problem or opportunity

Katie Welker-Muraguri
...or customer problem.

Chris Welker
Customer problem. Thank you. A customer problem or opportunity right. Into something that is understandable by a broader group of people in order to be able to deliver it. There are many people that fit that bill. There are definitely engineers and engineering managers that fit that. There are definitely product people, other people. It really can come from anywhere. But we need a discipline because you want people focused on things that are going to drive their particular business forward, whether that's a business analyst or whether there's been an opportunity presented. And the person that you're holding accountable to making sure those get translated is that person. There's a lot of people like, well, engineers can do that. Yeah. Okay. They can. I mean, in a pinch, right? They can, because they have to understand both sides of it. And I think that's useful. That can be super useful. Right. You can find people that are definitely passionate about that. Now, you may be giving up one for the other. I think it's really hard to do both of those things really well, which you need to. But again, what matters to the business, what matters to the outcome you're trying to achieve. Right. I was on a call recently, and it's like, well, something around they want to implement a particular feature. Is that core to your business? If it's not, then I wouldn't worry about it. I wouldn't worry about it right now. I'm not saying it won't be. Right. But if you got people focused on the right things right. We can you can figure you can generally figure that out. So, I mean, I would say I've always worked with somebody in collaboration with somebody to actually deliver the software. Yeah. That's how I would have defined it then. You know, and how I would define that relationship today. It would be product. Right. That's not how I would define it 20 years ago.

Katie Welker-Muraguri
It's really interesting, the evolution of that business analyst position to where it is now and kind of how it's yeah, we should talk about that at some point.

Chris Welker
So, Katie, how did this idea come about?

Katie Welker-Muraguri
I've actually had this idea before when I was working and consulting and having many discussions with engineering, and I thought it would be really helpful if product and engineering would get together, have some conversations about how we could best work together. Because I know what's worked for me in the past and I know how I like to work, but I think there's benefits to helping people understand how product and engineering can work best together. So you and I have had a number of conversations over our professional careers, I guess within probably the last, what, five years? Six years.

Chris Welker
Sure. Something like that. Yeah.

Katie Welker-Muraguri
And, you know, I don't remember the last topic we were talking about, but it just brought this idea back up, and I was like, we should totally make a podcast about product and engineering. And I told you to be Fire, and apparently you agreed because you showed up. 

Chris Welker
I'm not sure what kind of brother I'd be if I didn't show up.

Katie Welker-Muraguri
I mean, you could say no, and you could probably easily say no.

Chris Welker
I'm naturally the villain here.

Katie Welker-Muraguri
Aren't you always, as an older brother?

Chris Welker
No. I guess so. That's where it came from. You said it was going to be Fire. Yeah, I believe my text was we should remember actually being used, and it had the Fire emoji.

Katie Welker-Muraguri
Go back, check receipts.

Chris Welker
I delete stuff after 30 days.

Katie Welker-Muraguri
Seriously, I should probably do that.

Chris Welker
I don't remember it being fire. I remember you asking me, hey, we should do this because we've had multiple conversations through various trips about what you do and what I do and the general frustrations with the other not person, but function. Yes. And I thought it'd be fun to do with you. I hope people get some benefit out of it. We'll be that cliche. Even if one person gets it, it's worth it. It'd be fun just to see if we can help some people.

Katie Welker-Muraguri
Yeah, I guess that's the added benefit. But I think, too, from my perspective, I really appreciate your perspective because it's not the perspective I've run into throughout my career. And I think I've told you before, you for me, are like, I can count on three fingers people who have run into like you throughout my career. And so I think it's important for other product people and engineers to know that folks like you exist and this perspective exists and that there can be this positive relationship between product and engineering. It doesn't always have to be this tense struggle or whatever you want to call it. Doesn't have to be stressful.

Chris Welker
Sorry. Yeah, I would agree with that. I hope based on I think what we've mapped out over the next series of episodes that we're going to put together is general hot button topics that are always contentious, prioritization estimation design and how do you think about it? Right. What is the right way to think about these things? Not the right way. How do I think about them? How do you think about them? I mean, everybody's mileage may vary on what's worked for me. What's worked for you? I think experience is a big part of this. And delivering in different environments in different industries is super important because everything's kind of somewhat different. But I hope people get if we can have better, more common conversations around what people are talking about, around a particular topic, I think without trying to talk about, this is my role, or this is your role. Right. Where there's empathy in the conversation and there's an understanding. Right. Because I think what happens is there's this notion that engineers, that you have to come with some sort of technical acumen and they're not going to listen to you. So what I see happen and why I think this is so deeply important is I think everybody understands customer problems and outcomes and that kind of stuff, which is really where it should start. But a lot of people start with, I need some technical solution. Pick one. API integrations? I don't know. Right. Everybody comes with this. It would be really cool if we had a system that did this, this and this. And I think I just don't think that those conversations are helpful because it stops the creative process, which inherently both of these functions are creative in their different way. Right. From my perspective, parks creating lines of business, lines of business, value, helping derive value. Engineering is creating the substance of that, the expression of whatever that is in their own unique way. And I think it gets missed a lot because it's an art and a craft, and I think craft is super important. I think that if we could just spur people, have better conversations all around, I think that would be awesome. And I think it takes a lot of work to get those conversations right.

Katie Welker-Muraguri
It does. And I think one point that you make is about having empathy, and I think we all show up with expectations, and whether they're founded or unfounded, those get in the way of what we should really be doing. So I'm with you. What you just said is exactly on point. Just help people have better conversations. You'll make better products.

Chris Welker
Yeah, it may not lead to better outcomes.

Katie Welker-Muraguri
It may not.

Chris Welker
It may not. But there's a lot of work that goes into that. But I think where can you push how do you hold people accountable? How do you drive change? How do you implement that change? How do you get people on board? How do you get consensus? I mean, these are topics even today, I think everybody deals with all the time, but I don't think people recognize them for what they are. Right. And it causes a lot of in a very engineering centric culture, it means engineers typically are pushing product around. In a product heavy culture, it means product is pushing engineers around. And neither one of those are really I don't feel like, are super happy with the situation because somebody's losing. Yeah. Right.

Katie Welker-Muraguri
It has to be a partnership. It has to be

Chris Welker
yeah, it has to be win win. It has to be win win. I think there's a way to get there in either one. But I think you have to understand, like, you have to spend time showing the perspective either way about where you're coming from and why it's important and that kind of stuff. Yeah, I know we've said it a bunch of times, but let's just have better quality conversations.

Katie Welker-Muraguri
Better conversations, better outcomes. Fingers crossed. 

Chris Welker
Okay? Hopefully, what specifically do you think do you hope product folks walk away with that are listening to this podcast get out of this?

Katie Welker-Muraguri
I hope product folks who listen to this podcast will gain a better understanding of where engineering is coming from, what their motivations are, how to use those to your benefit to build your products. And I hope that product people will be able to have better conversations, like we already said, better conversations with engineering and not dread the idea of getting in front of a group of engineers to talk about a product.

Chris Welker
Do you dread the idea of getting in front of a group of engineers and talking about products?

Katie Welker-Muraguri
I absolutely have in the past. Not always, but yes. And I just think that I think it has a lot to do with the culture of some of the companies I worked for, but especially you kind of mentioned it, that product people sometimes feel like they have to have some sort of technical acumen to have a conversation with an engineer, and I feel that pressure myself. But if you come in and say, listen, here's what I'm trying to do, I'd love to hear what you have to say about this and how we might be able to accomplish this, it just drops that, and they can be the expert. Right. So, yeah, the number of times I've dreaded conversations with engineering is, unfortunately, countless.

Chris Welker
What do you think the percentage is?

Katie Welker-Muraguri
Early in my career, it was probably 75%. Now it's probably 25%. And usually because it's a new product. Right. So I'm coming in without a lot of knowledge about what I'm working on, just feeling like, potentially an imposter and feeling like I should know, but if it's new, I can't know, but I don't beat myself up for that anymore. And I ask questions so that I can understand.

Katie Welker-Muraguri
What do you hope people, engineering folks, get out of this podcast?

Chris Welker
Engineering folks? When you were answering this, I was thinking about the I think the process of construction is just not well understood, what it takes to get there, the type of I don't want to call it precision, because I think that's too precise, but the level of detail that's needed to really deliver something. Right. I think a lot of times there are two answers. This, well, I wasn't told to build it, which comes out of engineering or the flip side is the engineers that want to do a really good job really push back on product. And then it's like, well, they're the ones that are a problem because they're not building what I asked them to build. And I think the recognition that people that everybody is trying to get to the same place, if they're not, that's a different problem. It's not a product or engineering problem. That's just a people problem. And how do people really kind of come together? Right. I think once people really understand kind of what goes into construction, why things happen the way they are, there is this notion, I think, that exists about engineering, because you'll hear about big ones. Oh, well, they built us in a day. Yeah. What you didn't see underneath the hood is that they spent months and months building the stuff so they could build that in a day. And if that's the outcome, then people need to recognize that. Right. It's very difficult to build essentially stuff that does not exist in a day of quality. Deployable shippable to a customer, sure, we could hack something together in a day and get it kind of working. Will it meet all the requirements? Probably not, but I don't know. Change of text, sure. But, like, a new feature that didn't exist prior. My hope for both sides, engineering and product, is. That just a deeper appreciation of the craft that goes into each, say, discipline to make this really work. Because I do believe that most companies where engineering and products are going to work, it's an important relationship between these two because that's generally what drives growth.

Katie Welker-Muraguri
Absolutely. Yeah. What should we expect for season one of Product versus Engineering podcast?

Chris Welker
What to expect from season one? I think we're going to, I hope, interesting topics. I think since it's called product versus engineering, we're going to dive deep into what is product like, how does it work from generation to idea generation all the way down to meeting with engineers. Then we're going to talk about what is engineering, the function, what does it need to do? How does it work? What are the things that happen under the hood that nobody talks about? I think a big one that I'm looking forward to is our product and engineering aligned. I think everybody I know you and I have definitely experienced this, where there's a lot of misalignment and then missed expectations. So I think that will be a rich, fertile ground of angst, alignment and leadership. Just kind of on that theme. But how do you get alignment in leadership and what does that really look like? Prioritization and solution estimation. I know when we were thinking about when we were thinking about topics for this podcast, that was a big one, like, how do we prioritize and how do we estimate? Because nobody believes the estimates. Everybody thinks that the estimates should be shorter and then cuts the time and then expects everything they want. Estimation still gives me a sense of dread. Just the word, but it doesn't have to be that way. Then I think there's a deep dive on construction. What happens during construction? Like, what are the gotchas? That kind of stuff, which I think is an outcome of engineering delivery and GTM. What does it really mean? I think this is really misunderstood, especially by engineering what delivery and GTM is. I wrote the software, I deployed it, I'm done. You're kind of the start of something, so can't tell something that doesn't exist. What we can may have unhappy customers, feedback customers and function. How do you really get feedback? What's the right way to give feedback? What's the right way to get feedback? What's the right way to give feedback? Some gotcha around that and then I think we're going to end with what do you wish you knew then? What are some of the things we wish we knew that would have helped accelerate not necessarily the career, but the kind of relationship between product and engineering and that's we hope to get ten episodes out of that. I think that will happen and I hope that it will be interesting.

Katie Welker-Muraguri
How much do you think you're going to learn about product throughout this ten episode journey?

Chris Welker
I was thinking about this when we were putting together this outline I'm intrigued by the what is product, because it's not quite clear to me. Like, I have opinions about how we should go, how you should tackle markets and that kind of stuff. It's not clear how that actually happens. Need the problem. How an idea shows up on something that I have to prioritize has always been a mystery to me, even in leadership. Right. It's very opaque in my mind. Sometimes it's clear, sometimes it's not. But the clear ones are like, hey, we need to add a button to this, or we want to do this particular optimization test. Like, those are clear. Right. But if you're trying to build a new product from scratch, even today, is still super opaque to me. So I'm really interested to get into that. The GTM conversation, I think, is super interesting because I feel like those are relatively newer topics, like people are talking about. I hear it more now than I used to. Right. Again, it's probably one of those functions that was always there, but we didn't call it by that name, or I've always been in organizations that already had solved that problem, and I was scaling it. That's entirely possible too. I'm looking forward to that. I'm looking forward to a spirited discussion around prioritization solution estimation. I think that'll be interesting specifically because you should trust the estimates, and you don't want to hear that.

Katie Welker-Muraguri
It's not that I don't want to hear that.

Chris Welker
I think feedback. Oh, no, you just don't believe it. How could it possibly take six months? It needs to be three months or I'm not going to make my number. Yeah, got it. I think feedback, I think that's interesting to me. I've been in companies where we've definitely had people that gathered the feedback and synthesize it, but I don't know how in my mind, it's super important, but I just don't understand how it's folded back and how that changes how product thinks about things. Yeah. I think every single one in here, every single one of these episodes, there's like, rich, interesting topics, I think just your perspective on, because I don't think we've ever talked about any of these in true depth.

Katie Welker-Muraguri
No. We've just complained about them to each other.

Chris Welker
Right. Yeah. So that's why when we were putting this together, why it was like, it's really interesting. So I think those are topics that are top of mind to people. I think these are things that I think both engineering and product struggle with at times. Right. How do I give an estimation when I don't really know what it is? How much is enough? You hear this all the time. Right. And just how do you think about it? How do you work through it? What do you do? I think are super interesting topics to get into. So that's what I'm looking forward to. What are you looking forward to?

Katie Welker-Muraguri
A number of things. I think one of the topics I'm really interested in hearing your input on is alignment and leadership because that is a struggle of so many product people and from where your position and you sit in organizations. I think it will be helpful to hear how we can handle that or how we should deal with that construction. So I have ideas about how this happens, but I would love to hear I'm looking forward to hearing how

Chris Welker
Do you really want to know how the sausage is made?

Katie Welker-Muraguri
I am one of those product managers and I will tell you my very first product management position, technology. I was given, like, a set of requirements and I started working side by side with engineering and my manager told me, katie, you don't need to know all of this. You don't need to know how it works. And that's just like the idea of that just blew my mind because if I don't know how a product works, how am I going to know the impact of an ask? Right? Like, I don't need to know the ins and outs. I just want a basic understanding so that if I ask you to put this button someplace or change something else, I can know some sense of what does that mean to you? Right. That blew my mind. But now as I've gone further, my career, knowing how things work is helpful in creating a product that I would love to hear from your perspective because obviously I've just gathered that from so many people over my career. Prioritization and solution estimation. I can't wait for that. I cannot wait for it because I think product everybody comes in with an expectation and what I want to get out of that conversation is like, what is the compromise? What should product come in with, what should engineering come in with to get to an agreement? This has always been a point of contention throughout my career. So those are my top episodes, my top topics, I guess. But honestly, I love to talk about product with anybody. So I'm just excited to have the conversations and to see what you think because we've had a number of conversations, but this will be much more in depth and I'm just excited to hear your take on it so I can correct it.

Chris Welker
Yeah, it's going to be fun.

Katie Welker-Muraguri
It'll be good. All right, so episode two.

Chris Welker
As a reminder, you are not the eldest, so correcting me is not in the cards.

Katie Welker-Muraguri
It could be I could correct you on product understanding. You may not like it

Chris Welker
...and you may not like solution estimation. It is what I said is.

Katie Welker-Muraguri
I can guarantee you I won't.

Katie Welker-Muraguri
Thanks for listening to our chat on how we both got started. Next episode will dive further into what product is and you'll have a front row seat to how engineering thinks about it. See you then.

Outro
Thanks for listening to the Product versus Engineering podcast. You can learn more@prodversenge.com that's PR odvseng.com be sure to subscribe. We're of you listen to podcast so you don't miss an episode and leave us a rating review if you like what you hear, we'll see you next time.