Five Mistakes to Avoid in Your Product Career with Jackie Flake

0:00Season three of the Built Right Podcast is right around the corner, but we've got one big change coming your way. The Built Right Podcast is now the Talking AI Podcast, and we've got a lot to talk about in AI. In the Talking AI Podcast, we'll be having in-depth conversations with both AI experts and early adopters of AI. That way you can understand how the technology works and how early adopters are beginning to implement and, more importantly, get value from AI. Our guests range from AI research scientists to founders of AI products to industry leaders putting AI to work in their business. While you're waiting for season three, go ahead and subscribe on your favorite podcast platform so you don't miss an episode.

0:41And make sure to leave us a comment about the AI topics that you want to hear about. So get ready to talk some AI in the new Talking AI Podcast, coming your way August 6th.

0:58Welcome to Built Right, a podcast by Hatchworks where we help you learn to build the right digital product the right way. In each episode, we'll deconstruct the layers of successful product development, break down popular trends, and offer real advice to help make sure your product is built right. We may not have all the answers, but we've built a lot of digital products across a lot of industries, and we've seen a thing or two. Let's get into it.

1:33Today, we're chatting with Jackie Flake, founder of Option One Partners, serving companies through technology and product consulting. And this year, she just launched ProductX Agile, an on-demand training platform for product managers and Agilists. And product and Agile are two of my favorite topics, Jackie. So you already got me one over there. She's made the list of Atlanta Business Chronicles 40 Under 40. So she's a local Atlantean, which we love here at Hatchworks, where we're founded. And she believes that product management is the key to changing the way the world works, plays, and connects.

2:07But welcome to the show, Jackie. Hey, Matt. Thank you. Yeah, great to have you on. And I'm excited for the topic we're getting into today. So you got a fun one for us. Today, we're going to get into going deep into the five mistakes to avoid in your product career, as told by Jackie, who clearly has a lot of experience and a lot to say here. And P.S., number four is my favorite. So make sure to stick around for that. But without further ado, let's jump into it. I feel we need a drum roll or something, but what's, what's number one, hit us with number one. Okay, sure. Um, yes. So I created this list because I have made a lot of these mistakes in my own career.

2:49And I also see a lot of my clients making these mistakes. So very common, um, and things to avoid. So number one is simply believing that you are not strategic. Um, and so this is something I really struggled with early in my career as a product manager. and it kind of comes down to three things. The first one is just the simple fact that you don't know how to be strategic or you think that you don't know how to be. And I think as product managers, we put this pressure on ourselves that we should be having these light bulb moments that are creating multimillion dollar ideas, right? Like the next Uber or Apple or Amazon.

3:30But really it isn't about that. It's about understanding how to look at both qualitative and quantitative data to inform product decisions. And so, you know, while you may not be building the next Apple or Amazon, you're working on really interesting B2B, B2C, B2B2C products. And those things can all benefit from just learning how to do discovery work and understand analytics and insights. Okay. I love this one because when I first saw the list, this one like hurt my heart a little bit because I love strategy so much. But the way you're framing it, it's not that you don't need to be connected to the strategy, understand the strategy, but don't be burdened by like the whole company strategy on your shoulders.

4:14In other words, it's like how do you translate that into a product? Like you mentioned discovery, go a little bit deeper there in terms of how you think about discovery. Yeah. So discovery is also something that is a really scary word for product people at times. They know they're supposed to be doing it, but they don't know how to go about it, how often to do it. You know, they know they're supposed to be talking to customers, but when you talk to customers, how often and how do you interview them? And there's so many different ways to do that. So I always encourage my clients and people that I'm coaching to, we learn different discovery techniques and then we just practice using them.

4:51Because as an agilist at heart, I believe in experimentation as well. And that absolutely applies to product discovery too. You gain learnings and you iterate on them. And it starts with talking to the customer. This is kind of off topic, but any fun or funny stories talking with customers or doing discovery from your past experience? Or any interesting nuggets from? I'm sure there's too many to even name. Yeah. Yeah. Yeah, probably, I can't think of anything specific, but probably like coming into a customer interview, thinking I'm going to nail this. I've got all the right questions and just feeling so shut down by all the questions I'm asking and thinking like I am getting zero insight into this customer's head right now.

5:37Yeah. You know, things like that. Yeah, I think it's interesting, too. I've been in discovery calls where it goes a completely different angle than what you thought it would. And that's why you have the discovery, right? is to actually understand how the customer thinks, how they tick. Such a big piece of it. Yeah, exactly. So that's number one. Let's jump to number two. Okay. So number two is another huge pressure that I put on myself. And I think this is going to maybe ruffle some feathers when I say this, but it's believing that you have to be technical to succeed in product management. And so what I mean by that is, I mean, what is being technical?

6:18Like how technical do you consider yourself to be, Matt? Yeah, not as technical as the developers on the team or as much as I think I should, right? It's like that imposter syndrome. If I'm working on a technology product, I feel like I should know how to like code and get in there. So I love this one. I totally get this, yeah. Yeah. Quick break in the pod. If you're listening to this podcast, chances are you've been thinking about how to actually use AI inside your business. And that's exactly why we built the AI Opportunity Finder. It's a free tool that helps you uncover high impact, tailored AI use cases based on your business, your goals, your pain points, and your industry.

6:55No fluff, no generic use cases, just real ideas that fit your business and the ranked by ROI potential. It takes about three minutes to run and it's like having your own personal AI strategist for free. If you want to try it for free, check out the link in the show notes or go to hatchworks.com backslash AI dash opportunity dash finder. exactly but it's like i mean that being technical is such a range and you hit the nail on the head i mean as product managers our job is not to be doing the coding right our job is to understand what our customers want and need um and build products that delight customers under the constraints of our business and so i think this is an industry debate and i i really despise when i see uh job job descriptions that are titled or roles that are titled technical product manager because now you're eliminating a really big part of the market who are just going to assume that they can't apply for that role because they're not technical enough.

7:51And so unless you're building, you know, a heavy, heavy backend or API or database product, then I think as long as you're a PM that knows enough to be dangerous, you know, our jobs are to understand what the technical constraints and abilities are of our product is, and then be able to translate those in layman's terms to our business partners and our customers. And that is the skill that a product manager needs, not necessarily being technical. And as you and I both know, as we've gone throughout our careers, you pick up tech jargon and lingo and you learn as you go. So knowing enough to be dangerous is important.

8:32Yeah. And I think you hit on the big point there. It's being able to connect it to the business outcome. I feel like that's such a big critical role of the product manager is understanding the business outcomes that they want to achieve and helping drive the roadmap, translate that for the team delivering. Because everybody has a role on the team. And as product manager, it's not getting into the code per se. Exactly, exactly. And here's my little tip about how to kind of get through that as a product manager is I always like to say, this is what really helped me in my career. I would find a developer on the team or someone who's extremely technical on the team.

9:12and I would, they would become my buddies and they would not make me feel stupid for asking questions. And so I always knew that when I was with that person, it was a safe space. And if I didn't understand something technically, I could ask them to break it down for me because we've all worked with, you know, more technical people that make us feel small for not knowing things that we shouldn't know in the first place. So finding the developer that doesn't make you feel stupid is a really good trick. Okay. I want everybody to pause. If you're like listening passively that is such a big point there find the buddy on the team you know how to network and find that person that's like your your uh your um what's the word your co-pilot or something exactly i love that because they can help translate stuff and maybe now it's generative ai is like the next evolution of that's a whole other topic uh but i'm curious though what's what is the line because i i've like you i've seen some product managers that have no technical expertise.

10:09And I've seen those that can actually be dangerous. They understand how, you know, APIs work, how they can kind of view the code. They're not going to get in there and write it, but they can start to understand the logic behind how things are developed. Sure. Yeah. And a lot of times, the more technically you are, that can serve you very well. But then there's times where it can hold you back. You know, you do have a handful of product managers who came from an engineering background and wanted to transition into product management. So that naturally they are going to be pulled to want to look at code and maybe even write code, but not to say you need to stay in your lane, but you need to be able to do your job and do it well.

10:50And with that comes focus. And so if you're trying to be everything to everyone, then you're not going to serve anyone well or your product well. Yeah. You just, you just hit one of the core elements of strategy right there. You can't be, your product can't be everything to everyone and you yourself cannot be everything to everyone. That's great. All right. Then we've hit the first two. What is number three? Give us number three. Okay. So number three is only playing the role of PM. So I know we just talked about being focused in your role, but at the same time, when, um, when you're just a PM and you don't understand how any of the other roles work, then you aren't able to be a more effective and well-rounded product manager.

11:29So what I mean by that is we always talk about in product that we need to have empathy for our customers. However, we rarely discuss how we need to have empathy for our teammates because we cannot build a product in a silo as an individual, right? So, you know, taking on other hats allows you to learn tactical skills to be more effective and well-rounded in addition to driving empathy for your teammates. And so the roles I always encourage my clients to learn how to do is QA, because first and foremost, you have to know how your product works. And the only way to do that is to QA it up inside and out.

12:09And then, you know, wearing your Scrum Master hat. I grew up in the Atlanta startup scene, so I didn't always have the luxury of having a well-balanced product team. And so a lot of times I had to run the agile ceremonies and I had to report on the team performance data and product performance data. And so that forced me to learn how to facilitate effectively, how to block out for my teammates. And I think that's a really core skill that you can take into any role in your career. I say, you know, learn how to wear the dev hat. But what I mean by that is just to try to put yourself in a developer's shoes because the way that they have to learn how to solve problems through technology and coding is a very different way of problem solving than how you and I approach problem solving.

12:55So understanding dev and the challenges they undergo in their jobs is important and drives empathy. um other bonus roles would be learning the product design role because again i didn't have the luxury of having a fully balanced product team so a lot of times i'm the one creating the wireframe your wireframe yeah totally totally um scary if i look back on the ones i've built um and then just also just understanding how customer success and sales work together and those are the frontline people in your organization a lot of times. And when you don't have access to customers, they do. So making sure you're building those relationships with those people is really important.

13:38And then another bonus role would be product marketing, because if you're not involved in the go-to-market strategy of your product, then you can't influence that function either. Yeah. And for anybody in product, they probably get this or somebody thinking about getting into product. That sounds scary because you're talking about almost every area of the organization. But it's true, though. I mean, like the product manager, I'm sure you've heard it before. They're kind of like the CEO of their product. So they have to have tentacles into these different areas. And I love the way you put it, empathy.

14:10In two of the roles you mentioned, the developer side and the design side, one thing that I've noticed painfully through my own experience is, again, make friends with them and get them in the process early on. Because if you're defining things up front and then handing it over to design to do something and then handing it over to dev to go build it, you're in this kind of like transactional output focus. But engineers are super smart for a reason. And if you can bring them early on, they may have a different way of solving the problem that you have, knowing how the thing is architect. So I love getting them up front in the process.

14:50Yeah, absolutely. I mean, you know, product idol, Marty Kagan says, if you're not bringing your developers early into the discovery process, you're only getting 50 % of their value. Yeah. Yeah. Marty Kagan's like a, uh, uh, one of the main people we love here at Hatchworks. Anybody that has not read some of his books, like just, you know, stop what you're doing, go to Amazon, go, go, uh, purchase both of his, I think he's got two books right now. They have a couple others through Silicon Valley product group there, but he's great. Yeah. I had the opportunity to meet him. Um, and no way. Okay. Yeah.

15:26It was awesome. It was good. I'd love to, I'd love to hear more about that. Yeah. So, um, Marty, um, Marty and I agree on the same thing that there's not enough product management coaches in our industry. And so he invited 50 product coaches from around the world to New York city in December for a two-day workshop just to network with other product coaches so that he could then recommend them to his clients. And, but it was also workshopping, learning from the best. He brought the entire Silicon Valley product group team. And I was fortunate enough to be selected to go as a product coach and meet him and work with his team.

16:05And I'm still on cloud nine. And that was five months ago. Wow. Jackie, why was that? You should have gave me that as part of your bio. That would have been the ultimate hook. I'm best friends with Marty Kagan. That should have been the intro. I wouldn't go that far. I don't know if Marty would agree with that, but I still look up to him so much. Nice. That's great. Okay. So we've hit the first three. Let's do number four. Okay. Number four. This is very tactical in nature, but this is the inability to write really great user stories. And I say this is a mistake I see in people's careers, because if you as a PM are not able to write great user stories or your team, if you're a leader, is not writing great user stories, then you are doing a lot of wasteful work up front.

16:50So, you know, if we take all of that time to do amazing discovery and understand what our customers want and need, and then we don't take the time to distill that down into the smallest unit of work to translate our product strategy and vision to our team, then the downstream effects of that are devastating to your delivery function. Yeah, that's kind of your main mechanism of not your main mechanism of communication, but it's your artifact in a lot of ways. And having structure and I'd love to hear kind of how you structure it, but it's not just the as I want to do so I can X like there's the acceptance criteria element.

17:30There's all these different pieces that are critical in helping your developers, your designers, QA folks, you know, everybody across the board. But I'd love to hear kind of your thought on user stories and if you have a framing that you use in the process. Yeah, for sure. I love user stories. I love teaching people how to write them. And I actually have built, I've done several client trainings on user stories and I've built a, an on-demand course on user stories because it is so important to get it right. Yeah. But really what it comes down to is your job as a PM is to create a shared understanding of what the work is and equally as important what the work isn't.

18:13And so getting user stories right is about removing assumptions and ensuring everyone is on the same page. Otherwise, we're doing a lot of rework. We're rolling back releases. We have unhappy customers. Downstream effects are just, you know, very negative and you're not serving your team or your customers well. Yeah. Everybody hates rework, or at least they should if they don't. Yeah. You hit on one piece there. you know, it's that shared understanding and knowing what to do and what not to do. It's back to that empathy element for your team, because if there's ambiguity, you know, you're kind of leaving it in the developer's hands to interpret, you know, how they think it should be interpreted.

18:57Right. So having that clarity is important. I'm sure like this is discussed in ceremonies like your sprint planning or your refinement sessions, where you get to have that discussion around the actual user stories and clarify as well, right? Yeah, absolutely. And what I hammer home to all of my clients is that I want you to share the user stories with your team at least twice, if not three times before they start working on them. Because you can't just take a user story, run into sprint planning, throw it over the fence to your team and expect them to hit the ground running, right? Like they need time to think through how they're going to approach it.

19:34again, as a developer, how they're going to problem solve it. You know, they need to see it several times so they can iterate on it. And also, you know, we're human. So we're not going to bring a perfect user story to the team for the first time. So we need time for once the team pokes holes in it to go back and fix it and iterate on it and just work it and get it to a good place. That's a key lesson. And I've been at fault of this. Your team should not be seeing the user story in sprint planning for the first time. That's great. Especially with different personalities on the team, right? Some people may prefer to, you know, take time to understand something, think through it versus on the fly.

20:13So you're not getting as much collaboration if you go that route. That's great. Yeah, exactly. All right. Last one. Number five. All right. Number five applies to anyone in any career. This is just simply not meeting people where they're at. And this one is really important as a PM because product management is, I like to say is one of the hardest jobs because you have to get people to work for you that don't report to you. And so that is a huge challenge. Um, and I've seen people do it horribly and I've seen people do it really well. And, um, you know, building those relationships with my team has really served me well in my product career.

20:54Uh, and just understanding that everyone has something to offer, no matter if they have years of experience on you or, you know, they're much older than you or much younger than you, just not making assumptions that you know more than them. And so I also like to say that, you know, we assume that we need to find commonalities to connect with people. Like I have to, you know, go play Dungeons and Dragons with a dev on my team in order to connect with that person. And that's not necessarily true if I don't enjoy that as well. But it really is about developing micro connections and shared experiences.

21:29And I I have an example from a job long ago. So I was working at a local Atlanta startup called Bitrue, since been acquired by Oracle. And we had a huge deadline. We were building a product for one of our clients, which was Sports Illustrated. And we were really running into just this deadline with two weeks to go. And we were not as far as we needed to be. And so we did an estimation. And the devs were saying, this is definitely going to take us longer than two weeks. and so leadership had asked the team to work overnight until they could get the product launched um and so that was really hard pill to swallow for the devs but they were agreeable to it and so they were um gonna stay they stay till three and four in the morning we go home and sleep for a couple hours come back around eight or nine get back on the horn and start coding again well you know everyone else in the office left and would just leave these guys to their lonesome and i was like I'm the PM at the time and I couldn't leave my team.

22:28Like it was just, I, I wasn't, I couldn't contribute to the quality of the code. I couldn't contribute to the actual speed of the code, but I could be there to order them food, get them coffee, give them pep talks, you know, answer their questions around the tickets and things and, um, be there to review their work. And that time was really critical for us. And it really just, you know, that created such a safe space for our team. And, um, you know, that's an extreme example. We were up many, many nights in a row. Um, and I lost years of my life, not sleeping then, but, um, that's until you have kids and then everything.

23:04Yeah. I know we were just chatting right, right before this, we've had some fun child that had a sick one last night. It's a whole nother, but I love, I love this So, and that story is such a great example. It's, you know, meeting people where they are. And I know you've experienced this, those teams that have that level of connection, it's intangible. You can't really put your finger on it, but they just perform so much better. Their, you know, their velocity is so much higher. The ability to get things done, it's that connection and it's intangible, but I felt it on teams that had it and didn't have it.

23:45And I'm sure you have too. Exactly. Yeah, you're absolutely right. It's about building that trust. And just, you know, like I've seen PMs that take that complete dictator approach where they just, you know, hand tickets over, build this. Devs can't even ask why. Devs can't even look at a roadmap or understand the big picture. And they're not there to sit in a basement and code with a hoodie on. Like they are there to be strategic problem solvers. That's right. And so building that trust and building those safe spaces with your team will only serve your product better. Yeah, it's that servant leader approach.

24:18And I love those that are not on video. I can't see this, but you actually have a Kanban board. I mentioned I mentioned this earlier, but you have a Kanban board behind you. And this is the Kanban board for your life or your work. You actually have a physical that just goes how far, you know, you are a practitioner of agile and the product way of thinking. Yeah, for sure. I mean, I run my business on Kanban. I want to be authentic to what I'm teaching my clients all day long. So, and I know it works. Yeah, that's perfect. So that's another reason to use it. Yeah. Well, of course, so there's the five.

24:55And just to recap, let me see if I can hit them all. Don't put pressure on yourself to be, you know, strategic. And let me know if I'm butchering any of these. Don't put pressure on yourself to be too technical. understand how to write a really solid user story, meeting people where they're at, and the ability to wear multiple hats. And I think I got them a bit out of order, but did I sum them up there? Perfect. Nailed it. Yeah. That's great. All right. So I want to try something new. We have not done this on an episode yet, but I want to do a bit of a rapid fire round. I want to test this out in the practice of iterate to improve.

25:32It's one of the core values we have at Hatchworks. So let's test something new out. So rapid fire, I'm going to ask a few questions and just give us your first thing that comes to mind. All right. First one, what company is doing product management right? Well, this is a shout out to a local company here in Atlanta. The Home Depot is actually, I'm very impressed by their product transformation. I was brought in to help support their product transformation back in 2016. And they, just to see their growth since then has been amazing. They really focus a lot on discovery. They are very, very good at talking to customers and getting those quick feedback loops.

26:18They'll go into stores, talk to customers, talk to associates who they're building tools and products for. And I'm just so impressed by them. And you wouldn't think that of a, you know, a hundred year old retailer, but their tech team is doing awesome. No, that's great. That's an Atlanta staple right there, Home Depot. And to your point, it's like you think of those kind of older, large enterprises as not doing this well. So that's great. That's an example of one that is. I feel like I've been living at Home Depot lately. We just laid out mulch across our whole house and I'm still hurting. Yeah, I'm mulch over the weekend.