speaker-0 (00:05.646)
Welcome to the Hard Tech Podcast.

And everybody, welcome back to the Hard Tech podcast. I'm your host, Deandre Hericus, with the usual suspect, Grant Chapman. And everybody, today we have a super exciting guest that leads product management for a product you more than likely have at your home, Tiffany Mayo with Yale in August Home. How are you?

going everybody.

speaker-2 (00:25.037)
Good, how are you all?

doing fantastic. We're really looking forward to doing this podcast with you today. Grant has one of your locks on his doors, and I think a lot of people don't even realize that they're engaging with this smart connected device all throughout the day. And so we'd love to get a brief overview of yourself and your background.

Yeah, absolutely. So Tiffany Mayo, I'm currently the director of product management for connected devices at Fortune Brands Innovation. And I have a focus and a specialty with the Yale and August Solutions, as you said, SmartLabs. I've been doing this for about 10 years, but prior to my life with product management, I actually went to school for marketing and I have a marketing background. So started at a small manufacturing company in Connecticut where I did

marketing, product marketing and transitioned into product management and it's been product management ever since and I absolutely love what I do. And Grant, I'm so excited to hear that you're a Yale user because it's fun to get feedback from people that are actually using the product.

Well, it's funny because I switched from a Schlage smart lock originally that was not meeting my needs and the August lock has done it so well. actually have two of them. So it's really been great to unbury the lead battery life.

speaker-2 (01:34.964)
Yes, yep, battery life is always one of those things that we all have to worry about.

Yeah, and again, our space and developing IoT or connected products, it is like, how do you balance feature set, responsiveness and battery life altogether? And the great thing is it gets easier over time because both batteries get better and everything gets lower power over time. So I think in the next five years, battery life won't be an issue for connected devices that are needing batteries replaced once every year or two. It's only going to be the devices that need to last for five and 10 years, basically like built-in batteries that don't need to be replaced.

I think that'll be the new frontier we all face is like, you know, product obsolescence because the batteries aren't replaceable.

Yeah. would love to be in that world. So get there sooner rather than later.

That's right. You hear us hear first all the all the silicon manufacturers. We just need lower power chips. Keep going.

speaker-2 (02:24.503)
Exactly.

So Tiffany, you start off in marketing, or least go to school for marketing, you end up in hardware product management. What was that sort of transition and like, what are some things that you wish you knew moving into the PM role coming from the marketing world that you didn't know going into it?

Yeah, absolutely. So the transition started because as I mentioned, I was working at a company that did manufacturing of hardware devices and it was a small company. And the direction I was given was when you're doing marketing for a company like this, the next logical step is to go into product management. And I was happy for the promotion and really wanted to dive into what product management was, but I didn't know very much. So at that point in time, and as I navigated through my career, I think it would have been really helpful if I had.

more of a structured overview of what product management was at the start. So something that really outlined what product managers do, what they don't do, where the boundaries are and where ownership and collaboration lies. Because, you know, obviously it's different between all the different companies that are out there. And when you're with a smaller company, I feel like product managers end up doing a little bit of everything and they go over that line of ownership sometimes, but really at least having the basic foundation.

I think would have helped me step into the role with a little bit more confidence and probably spent less time just trying to figure out, you know, basic things through trial and error that I had to do.

speaker-0 (03:45.646)
I think one of the hard parts about product management, especially in a hardware, like in manufacturing, is the timeline to learn that you made a wrong call isn't fast. Your iteration cycle is very slow and unfortunately very expensive in time, money, effort, headache. If you're building a pure digital product, it's still, again, can have leads or you don't find out you're wrong until later. But in hardware, you've cut tooling, you've built jigs and fixtures, you've done something in the real world.

that you've invested engineering time and then someone had to go make it and someone had go realize it didn't work. knowing where and how to put your test points, both physically on the board, that's pun, but really as a product manager, how do you test if the team is doing the right thing?

Yeah, absolutely. I think that's like a really important area to discuss is there's just so many different levels of testing that have to happen. I think, you know, putting together that plan with the different people within the organization is what is super important. You know, I think there's, especially with what we're doing, where it's hardware plus software, there's a lot of different things that have to happen. So you really need to work with, you know, what physical things need to be tested.

And that can start way before tooling has to happen. So you have all of your metrics that you put in place with the different, with your quality team, making sure that the parts that they're bringing in are quality parts. Then obviously once the product is built, you're going to be doing testing in-house. You have different ways that you can, you know, put together, mock your emulators so that testing can happen. Then really diving into an important structure, you know,

Beta program is super important and getting those products, you know, in my case, getting the product on the door and walking people through the different use cases that need to happen. So the products being used properly, seeing what they do that, you know, maybe we didn't think of. think what the coolest thing about end users is they do things that we did not think of as product managers and getting that feedback early is really important to make sure that you have the full life cycle of the product and you can account for all those use cases.

speaker-1 (05:54.038)
Are there any funny stories you have of the folks using the product in ways you guys would have never imagined previously?

the funny, but not actually realistic is with the key free products that we sell. there's no cylinder in the product whatsoever. You know, there's reasons why we do that. Not having to worry about lock picking, lock bumping, rekeying products, all that good stuff. But it's so small that users actually installed it upside down. Like on the door upside down. Didn't, I don't, didn't realize it. I don't even know how they got the latch and I have so many questions, but.

Like the numbers were upside down and they're like, this isn't working. And they sent pictures and as product managers, we'd be like, huh, I wonder what made them think that was the way to do it. Especially with our products. There are like, have a label over the keypad that shows the numbers. So the numbers would have visually been upside down, but that's always an interesting one. When we get to that, go back to those beta tests and look at our findings.

Yeah, my CTO is notorious for pulling the stickers off of anything the second he pulls it out of the box. Like, every little clear screen protector or film or instructions that he just peels right off the product so we can see it. And I'm like, were there an order of operations and when we're supposed to do that? He's like, I don't care. And that is exactly how something that the numbers don't show up until it's powered gets installed upside down. So that is absolutely hilarious. I think zooming out from the product managers and product owners perspective,

Something you touched on that was interesting like emulators and when to test and how to test is something that is often overlooked in a early PM's Lifecycle, you know, they don't understand that no you need to tell the engineers When they have to test their stuff because they'll assume it works because it works in their head up until the day they tested it and it doesn't and so You know at glassboard we go through what we call alpha and then beta and then design for manufacturing So alpha for us is you have a looks like prototype that does not work

speaker-2 (07:40.3)
Yes, absolutely.

speaker-0 (07:49.838)
This is just your 3D print industrial design. This is what the aspiration of the product is and then you have what we call the shoebox ugly version It's a bunch of wires and dev kits with as minimal 3d printing components You can fit that actuates whatever it is if it's an IOT toaster It you know has a timer and a temperature sensor and pops up a solenoid that would say hey the toes would come out when this happened Do you guys start at that level when you're doing like early new product development like what is your shoebox look like?

Yeah, absolutely. On the hardware side, definitely. So, you know, we start with those emulators. It's kind of like a mock-up of what it could look like. Raw PCB, like literally sitting on somebody's table and they got all these different wires connected to it. And that's how we are verifying the firmware and making sure that the different commands are working properly. Working with the software team, a lot of times...

it's the full product, but at an alpha level or even in a basic engineering sample, like they don't need the product before tool or off tooling. So it can be done before tooling, but they want to make sure from the app side, you know, we have door position sensor and you know, the bolt needs to be coming out the correct way. So they want to make sure that when that's happening, they're physically seeing the bolt come out and then the app is responding properly to it. But it's definitely there's some

give and take that has to happen. I think when you're integrating with a software product, earlier that group can get some sort of hardware that has firmware, the better because there's work on there and that needs to be done to make sure that they're receiving all the commands properly from the product so they can develop the app properly.

Yeah, no, and it's so critical to do this. It's one of those things that takes time to engineer a test kit for the software team. The hardware team never wants to do it. like, no, no, like, just tell the software team to make it work. But it is something to be said about getting, even if it's like the dev kit of the microprocessor you're that's got a little breakout board that has switches, buttons, and lights that would say, hey, click the switch to the door sensor to tell, you know, fake that the door would be open or closed or that the bolt sensor's locked or not. Or this light turns on to show you that you're actuating

speaker-0 (09:55.054)
the motor output, right? And let the software team play with that piece of hardware on their desk for months while the hardware team is going through alpha, beta, DFM so that the software can dovetail into that hardware effectively and no hardware team wants to take the month or two it takes to build 10 of these little dev kits up and send the software team, but man, it saves so much time.

Yeah, absolutely, I would agree.

So one of the questions I wanted to ask Tiffany was, if you were creating like a curriculum for a brand new PM in the world of hardware to that could like get them started, what would that curriculum be to kind of like get you into the space?

Yeah, absolutely. I think that's a really interesting question. So for me, you know, I think that there's three core things that people need to be aware of and need to be learning about, especially in the world that I live in where it's a hardware product supported by software. So I think the very first thing is just defining the role as a hardware PM specifically. So clarifying responsibilities and the scope and where the role actually differs from software, because there are a lot of differences.

Then the second side of that is understanding the role from a software standpoint. So again, what are their roles and responsibilities? There are so many areas where the work intersects that you want to make sure you know that the difference is between the two because you can't really appreciate what's happening if you don't understand how the other person, how they live and what they're doing. And then the third area is bridging the two together.

speaker-2 (11:25.686)
So practical strategies for collaboration, aligning timelines, managing natural tensions, because that's always going to happen. bringing that all together really makes it feel like the product ends up being seamless to the consumer.

Yeah, but I love that managing those tensions between the hardware and the software team because the quiet part we haven't said out loud is there is software, there is code being written in the hardware team called firmware and they, you know, it's one of these things, you're seeing that Spider-Man meme where they're all dressed up as Spider-Man and pointing at each other like blame them for the problem between the electrical hardware, the firmware and the actual like app software, we are first doing integration and we call it integration hell. There's always a problem that comes up and everyone points at each other and no one actually knows who caused the problem yet.

And how do you build a safe space is the right word, but like a constructive way to test to find out where the issue is without blaming that team. Everyone's collaborating to find the problem and then some poor guy has to go be the one to fixes it. But everyone should be collaborative to find the problem and not be defensive to, you know, save face. wasn't them. We all make mistakes. It is as a team how well can we work together. So how have you structured that interaction between your hardware, your firmware and your software team to lessen that friction?

Yeah, that's a great question. And it always happens. Like you said, it is a huge risk that finger pointing thing is going to happen when you're at the intersection of the hardware, firmware and software. So I think as a product manager, part of our job is to really set the tone for the team and make sure that you prevent that. So when I run into issues like this, one of the things that I've done is ask each individual team. So the physical hardware, the firmware team on both sides.

and the software teams to stress test their own area. So get creative, think about what you could have possibly done wrong that caused the issue. And then everybody comes together and compares findings. And then from there, we're able to pull things apart and see where that issue really lies. So having that shift in mindset really helps with that, you know, the blame game and brings it more to a problem solving, like, hey, let's work together. Let me focus on my...

speaker-2 (13:30.996)
area, not worry about what other people are doing, they're going to do their side and then we're going to come together as a team and figure it out. And I think that usually leads to a faster and more collaborative way to do it versus, you know, people just being, having the tension and pointing fingers at each other.

Yeah, no, and I think that the emotional side is just as important as the tactical side of doing it. Hey, I'm not as a PM. I'm not angry at anybody that there's a mistake. This is just how product, you know, the sausage is made. The question is, I'm going be the happiest when one of us finds the problem first, especially with your own. I'm proud of you for coming to the table hat in hand. Like this is the thing that I screwed up, whether it's a board spin or a firmware update or just a software update. Like I don't care how big the impact is, the faster we know about it and the more honest everyone is about what happened, the faster we all get to the end game together.

Absolutely.

I found one of the breakdowns between talking with a hardware team, especially like, you know, physical PCB, firmware, they speak about the same language. They usually have a simpler background and skill set. And it's the app or web app or software team that speaks a different language, right? They have different sprint terminology, different milestones, different testing gates. And one of the terminologies I teach my firmware and hardware team is to use the word API. Hey, treat this like a software API as if you're making a call to a different piece of software, even if it's on our firmware. Don't worry about it.

tell the software team, tell me what you want your API to be and how I can test it early. And even without their software, you can inject those quote API calls into the firmware and vice versa. The software team knows what API calls they should be sending and what they should be receiving. And the faster you can get them speaking this API language that there's a connection layer. Here are the language we're going to use together. The faster you can get to not the lane game, because the hardware team is going to say, I need to receive this message within some amount of time.

speaker-0 (15:17.074)
Firmware is much more time dependent than software is. And it's one of those things, if you put that in the API, the software team is always going to say, I sent that message too slow. That's why I didn't get you to the right state at the right time. And I think that's the magic there is communicating English to English translation amongst the different disciplines.

Yeah, that is a really good way to explain it. And I think that's one I'll add to my little playbook because that, you know, getting the teams to work together, there's always some tension and friction there. And I think, you know, we're all speaking English, but sometimes people don't understand what each of the groups are saying. So I like that.

I guess that leads me to my next question. If you had to create like one RACI that could be for like the implementation of a new SmartLock feature, like what would that be?

And what's racing for those of us uneducated? What's our HCI stand for?

Yeah, so the R is for responsible, the A is for accountable, the C is for consulted, and the I is for informed. So it's really looking at that cross-functional team and where each of the different disciplines would fall into it. So I think that's a good question and how I would think about it for a smart lock. So I really would want to keep it simple. So engineering, both on the hardware and the software side, they're the responsible product of

speaker-2 (16:36.03)
responsible party for building a specific feature, whatever that feature may be. The product managers, again, both on hardware and software, are going to be accountable for making sure that the solution that comes up from the engineering team meets the needs of the users and meets that business goal. Design, security, QA, they're consulted throughout the entire process to make sure we're following Figma specs, we're following any of the security constraints.

and that the product is actually working properly. So we want to make sure that it's usable, it's safe, all those good things. then leadership and marketing and then the support team, they're typically informed so they know that it's ready for launch, ready to put it out into the field. So really having all that clarity together, make sure that there's no overlaps, there's no rework, and we're delivering the product that we need to.

I really like that. What's interesting is that mirrors a lot of the medical device, FDA development process that we have to do for all of our regulated devices that you basically have your user needs that are typically verbalized in English by your product marketing team. This is what we wanted to do.

your program manager works with their engineers to translate that into design input requirements. Here's the technical spec it has to meet. The lock has to work when it's cold outside. has to withstand someone turning the key with so many new meters of torque, and you're defining those tech specs. And then you need your regulatory consultants that for you guys are your security and quality team of like, what specs do we have to meet that aren't from the marketing team? This is just the area we play in. How safe do we have to be? And I love that.

we often in medical device development forget to go put the eye back in, the informed. How do you communicate to the leadership of this product company where we're at in space? Are we going to meet all the user needs? Are we going meet on budget or timeline and have that open conversation? Deandre, you and I love the Triangle of Fund, the good, cheap. You can never have all three. Which ones do you want to balance today? Conversation. I think that's awesome.

speaker-0 (18:31.438)
No, that's super cool. I'd love to dig into like, how do you guys use I, use informed? Like what are the mechanisms or meetings or structure for informing a larger, because you work in a larger organization, like how do you guys make sure that information isn't burdensome? And like what's the actual tactic you guys use to share that?

Yeah, absolutely. There's so many different ways to do it. And we try to balance between meetings because you don't want meeting overload. But then the same thing goes on the email side where it's like email overload and you have hundreds of emails that go unread. So we balance it across the organization and it really depends on who the message is going to. So if I'm looking at it from a product team level, marketing sales, they need to know what's going on. They don't necessarily need to go into the weeds.

that typically lives in a meeting that's actually hosted by our marketing team. I love that they do a go-to-market meeting. It's such a really nice strategy where they're the owners of, you know, the strategy from a launch standpoint, but they need inputs from some of the people on the team, but they don't want to get too technical. So they kind of highlight all the areas where they need information and we use it as sort of a working session slash update meeting.

to get them what they need so they can do spec sheets, digital catalogs, PDP pages, packaging, all of that type of stuff. And they're getting the basic information right then and there. And then as a product manager, we're able to approve it. So that's how we would handle somebody that's on the cross-functional team, but needs to just be informed. From a senior leadership standpoint, two ways that it happens. And I've done it both ways. It really depends on the product launch and how high level we need to go.

We try to have syncs very regular with the senior leadership team, whether it's a weekly meeting where it's just going over all the top projects within the organization and giving them like red, yellow, green status. So, you know, they see green, they're like, all right, move on red and yellow. What's happening? What do need for me? How can I help have go into a little bit of deeper conversation or if it has to get taken offline, it can. So we've done it that way weekly, monthly, just really depending on where we are within the business. I mean, email updates in that case work.

speaker-2 (20:41.612)
you know, make sure that it's high importance, get the high level pieces of information that are needed, and then call out specifically, you know, if there's an area where you need something from the leadership team, or if it's just, hey, FYI, so you know what's going on, we're on track, we're not on track. I'm definitely, you know, communication is super important. And that's one of the areas where product managers have to shine is we have to be able to have that communication and do it in a way that we're resonating.

with all of the people within the organization. So not only cross-functionally, but being able to speak up to our senior leadership teams so they feel comfortable as well.

No, I love that. I think that it's that really important tact between not information overloading So you're actually making it their responsibility to make an action. It is like hey, everything's green light I don't need anything from you. I'm autonomous right fire and forget missile or yellow. Hey, I see a risk coming I think the word risk is never talked about enough in product that nothing's for sure Nothing in development is on the rails a hundred percent even if it is green. It's probably only on the rails 90 % We think this is going to work And when you start seeing risk in the future who?

We are feeling stressed about X, hasting your leadership. Do you want me to drag you into this today? Or I'm just gonna let you know, but if you want to dive in, come meet with me afterwards. I think it's a great tact. It's not making every yellow light a five alarm fire for them to have to leave whatever they're doing every day and come help you out in your job. And then red is we've hit a challenge. It's either gonna be a timeline or a budget or a feature challenge. And I need you to make a call which one of these things we're gonna sacrifice. I can tell you the options. I can present the menu.

I'm the waitress, like I'm the waiter waitress, this is what we're doing. Which option would you like to buy? Here's the problems, here's my solutions.

speaker-2 (22:23.426)
Yeah, absolutely. And I think sometimes it's a balance of, you know, leading a little bit too much and giving your recommendation. So I try one of the strategies that I try to do is, you know, highlight the risks where you can provide your recommendation based on the data that you have. Like, yep, we have these three risks, but I think that we need to go in this direction because it's going to mitigate two of the three.

And presenting it that way will also help them make an informed decision without having to go into the entire history of how we got to where we are.

Yep.

Tiffany, based on your background, I'm sure you've never made a mistake in your life. it comes to running a hardware team. I'm curious, if someone was getting into the world of project management or their current PM today, what are those common mistakes? And you've kind of alluded to them. It seems like a lot of it's almost in the soft skills that you can run into as a PM.

Yes, I think that, you know, one of the things that ends up happening and it really goes back to organization size. So everybody has to look at their specific situation and go from there. But I, in early in my career, I definitely did not delegate enough. Like we had a lean team for sure. and because of that, I felt the need that I had to kind of take everything on myself, you know, as product managers were the owners. So we are the ones that get.

speaker-2 (23:45.378)
the complaints were the ones that are told like, hey, you need to go figure this out. And one, not having that training upfront where I even knew what was my responsibility and what was, you know, ownership versus just something that I needed to be aware of. When I was getting those requests, I kind of felt like, this is my problem to solve. And so then it just ends up being everything falls on your plate and you have way too much going on. So I think really that delegation and knowing

who to go to and feeling the empowerment to even do that. So having that structured program really would have helped me recognize earlier that it's not really about doing everything as a product manager. It's about prioritizing things, empowering your coworkers and people that you're working with and really creating clarity so everybody knows what's needed and everybody can work effectively. So I think the delegation is a big piece and part of that.

comes clear communication and being able to work with different people within the organization and change how you're speaking in order to work with that person specifically. it's marketing, maybe it doesn't need to be as technical or on the engineering side, you need to dive into the detail. So kind of balancing all of that together.

No, and I think that the tact again marketing versus engineering how pessimistic do you use what words do you use with each team is totally different? like with marketing you need to be really pessimistic because like you need to tell them because whatever you say they're gonna take a face value because their marketers are gonna go you're gonna Plus it up anyways when they go put on the box or tell leadership about it so it's one of those like you need to be very like this is what I know to be true and Not say these are all things. hope to happen that are good right and that you really need to talk about these are things I fear in the next six or nine months

But with engineers, you need to do the other way around. You're like, guys, I know you can do this. Team, we are capable. You're smart. Pump them up. And then DTO, data trumps opinion. When they're pushed back, no, just go try it out. Tell me if it works or not. And then let them give you the green, yellow, red check boxes. You take that back to leadership or marketing, have the conversation, where do we want to invest? And it's always that conversation that I think, you nailed it, that who you're talking to changes the vernacular you have to use.

speaker-2 (25:54.754)
Yep, absolutely.

When it comes to like having the covers is that the case when you're talking to the marketers you were like really trying to dial back maybe like timelines and things like that versus whenever we talked to engineers or what is the actual dichotomy look like in real life?

Yeah, I think with marketing, I, have to be transparent. So there are so many things that the marketing team has to do and has to prepare for, especially, you know, if it's a large launch, it's, know, not just the digital materials, but they're creating videos, photography, they're going to be making like commercials that for smart TV, all of those things. And that stuff takes time. And you have to be transparent and honest about where we are from a timing standpoint without.

freaking them out. So it's definitely a little bit of a balance where you want to tell them if there's going to be some risk, but you also don't want them to think that this product is never going to launch. you kind of have to like feel that out. I think making sure that you have a really good relationship with your product marketing team is important. So you can have that gut feel when when you know you should be able to have those types of conversations and how to have it with that specific person, because the last thing you want is

people to get in that panic mode and think, you know, if they had done work previously, it's all wrong or it has to be fixed or it's never going to be used. But that's not the case. It's just, hey, something came up. We're going to be a little bit delayed. Here's where I feel that things are going to land. From your standpoint, I would recommend you do, you know, these three things and we should be all good.

speaker-1 (27:28.52)
know, Grant, that it really sounds like conversations you have with clients all the time.

I just got off a call with an enterprise client that, and I'm working with a product manager. This is really salient to this conversation. And our meeting we had today was completely not about what it ended up being about. This was about what are we doing next year and high level road mapping and all this stuff. And it boiled down into we needed to have a conversation, and we didn't need to have it. This PM needed someone to have a conversation with about how to position the product internally. How to position the good

good, fast, cheap, triangle of fun, or how much resources, or what feature set. And then it boiled down to even, I thought it was that, and then the last 10 minutes came down to, no, we don't know how to tell the marketing and the product team, like the actual definition of the user needs, how to separate a really expensive product feature versus a cheap one. And it was just crazy that I was a facilitator for a conversation, that the person I was talking to had all the data.

They just didn't know what tact to lay it on the table as you just said it's all about how to not freak people out but tell the truth transparently and how do you line these things up? And I love that that dovetail is kind of residing because like I see this every day. think 25 % of the meetings I take with clients as like in the CEO role because I'm not actively doing development. They took away my CAD license two years ago. We've never been better as a company for it. But I'm facilitating these questions.

and having the right questions to ask the team members is almost more important than having the right answers for people. Would that resonate with you?

speaker-2 (28:57.262)
Yes, definitely. It's funny. I've had that conversation with my manager several times where he's like, all I do is ask a lot of questions. Like, that's my job. We just go around and we need to ask questions and make sure that we're understanding the perspective of other people. And sometimes the only way to do that is by asking questions because people don't always naturally think how, you know, a product manager thinks, so they don't.

know everything that needs to happen from a product launch standpoint. So we're able to pull the information out that we need by asking the question versus just trying to have the dialogue or have an agenda for a meeting. Like, hey, let me just pick your brain for 10 minutes. I got these 10 questions I need to ask you. And then that'll pull out all the information that you need. So yes, definitely resonates for sure.

So funny and so so sailing how that works out like, you know It's always an hour or two before you go into something else You just had an experience that parallels that and you haven't had that in three weeks or something like that, right?

Tiffany, I always like to wrap up the podcast on a question. I have two different questions. You can choose your own adventure here. One is the one I had outlined, which is what kind of advice would you give to an up and coming PM? I think you've kind of alluded to a couple of things here so far. The second one I was also curious about, you can choose if you want to use this one as well, is what as a PM, what makes a successful project as a whole? What are the key elements that you kind of see consistently that lead to a successful project that you can almost repeat over time?

Yeah, absolutely. So I think that my advice that I'd give to an early PM actually ties into how you make a project successful. So I'm going to try to actually do this and answer both of them with my response. relationships, both the things that you need to worry about, whether it's just becoming a product manager and you want to do really well and make a really good project, you need to forge strong relationships.

speaker-2 (30:52.372)
Our job as product managers is to collaborate across the organization with a bunch of people that don't work for us. They don't have to listen to us if they don't want to. They don't report to us. So having those relationships to make people enjoy the project that you're working on will make the project better. Those relationships, they really depend heavily on trust and collaboration and making sure every interaction you have is done with transparency and respect.

And it's that type of working group that helps build a good project. Obviously having a good idea and making sure it's executed well is important, but people tend to want to have good execution when they're working with people they enjoy working with and they have that mutual respect for each other.

No, and I think that's a great tie in that like it's the relationship that makes the plan work, but the plan has to exist for everyone execute against. That's what I heard about that. Like you have to build this like, you're in the trenches together mindset so that, know, anything bad that happens to happen to all of us, not to one of us. And that builds everyone's ability to trust and help each other through this plan that we're going forward with together.

Yep.

It's all about relationships and the human to human translation. Everybody, this is the Hard Tech Podcast. I'm your host DeAndre Hericus with my co-host Grant Chapman. Thank you so much. We'll see you guys next week.

speaker-0 (32:13.794)
Thanks for joining us and Tiffany, thanks so much for hopping on.