Product Management Webinar: Building Product Teams

Janna Bastow: All right. Hey everybody. Welcome. Come on in. Come on in. Welcome. So we’re going to kick off here and I want to say hello and welcome to the product expert fireside series. We’re joined here by Maggie Crawley. We’re going to be talking about building the dream product team from scratch.

Maggie’s got some great stories for us about how she’s done that before we kick off into that story and exactly how that came together. I want to tell you a little bit about. So ProdPad is something that was started by my co-founder Simon and myself. We were both product managers and we needed tools to do our own jobs.

And essentially we needed something to gather the ideas that we were hearing and all the customer feedback and connect it to the objectives that we were given, and basically titled together into one product management platform that just didn’t exist. So we started building something and started sharing it with the other product people around us.

And today ProdPad is used by thousands of product people around the world. So it’s a free tool to use. You can jump in and start. It’s a free tool. It’s a free tool to try not to use. You can try it today. We even have a sandbox which is free, to to try out as well. Which is a preloaded version of ProdPad.

It has all the things like, okay, ours is preloaded. It’s got ideas and feedback and roadmaps, all this stuff ready to play with and interact with that. You can try out, see how it all fits together. And from there, see how it works. We’re product people ourselves. We’d love to get the feedback.

We’d love to hear how it’s working for you. Jump in there, give it a try and let us know how it works. In the meantime, I’m super excited to introduce you to our guests for the day who is Maggie Croley. So Maggie is a she’s the VP head of product at Charlie health. She is an Olympian.

She is also the she was also the host of the podcast build and as I had lots of stories about different product managers and product people around the world and just has great product stories. Every time we’ve had a conversation, I’ve been on her podcast. She’s now been on she’s now being on my webinar.

Every time we have a conversation, it’s always just great product chatter. And so today she’s going to be talking to us about how she built the dream product team from scratch. Maggie jump in with an introduction that’s fills in any of the gaps that I left there. 

Maggie Crowley: Yeah. I’m, it’s really fun to be on the other side of this.

And not being the one, doing the interviewing. So I’m really enjoying this. And I think the one caveat I would add to what to your intro is that I am building the dream team building. Yeah. So it’s not done yet. There’s really only a couple of us so far, but it’s been a really interesting challenge to go from a sort of hyper-growth scaling startup.

Back to another one that’s in an earlier stage and to think about if you were going to start from scratch on a product team, what would you do differently? What would you keep? What would you change? How would you approach hiring what would your values be? I think for most of us unless you’re a founder or you’re really, early stage, a lot of that, a lot of those things come with the role that you take.

And so it’s pretty rare to have an opportunity to say to take the time, to be intentional about how you’re going to make your team and your principles and how you’re going to work. And that’s been probably one of the most interesting parts about, the role that I’m in, 

yeah, absolutely.

Janna Bastow: It’s a really unique lens because if you think about it, most of the time, whenever you’re coming into a role, we end up adopting existing teams, infrastructure and products. If you’re coming into a role as a product manager, most of the time you adopt somebody else’s product, you rarely get to work on Greenfield products.

You have the existing tech debt and constraints and customers for better or for worse, right? But working on a Greenfield product has a, just a set of freedoms with it that you just don’t get when you’re starting something from scratch. And it’s really rare to be able to build out an entire product division from scratch, unless you are the founder yourself, which comes with its own challenges, but to be able to be brought in as the product person and being, given the space and the permission to build something out, it’s just a really unique situation.

Maggie Crowley: Yeah, I think it sounds probably more exciting on paper than the lived reality of it. Like many things. I think it was one of those things where I saw it and dove head first yeah, I’m going to do it. It’s gonna be amazing. And then three months in calling my friends, being like I’ve made a huge mistake.

What do I do? And I think probably the best piece of advice I have from the last. So I’ve been in this role for about four, just over four. Is like building the network of people that I, had met including yourself, which is how we got on this topic was I phoned a friend and was like help.

I need to make a roadmap. I think having that network of people that you can tap to help you to help help you think through problems. I think it was really fun, challenging, and continues to be a fun challenge. But what I underestimated was how product almost never operates in a vacuum. So you would almost never be in a role where it’s just you and not an engineering leader and not a design leader and not a couple of technical folks here and there.

And I think what I missed was having someone just to give, me feedback in a way that was like more relevant to the work that we were doing. So obviously there’s other people at the company you have, co-founders that kind of thing, but they’re not experts in building software. And so they didn’t have the kind of lens I’m used to having as my sort of foil for when I’m planning things.

And so I think that was probably the hardest part was not having those voices in the room when I started and making sure that I could find people to talk to as I got the team off the ground. 

Janna Bastow: Yeah. So how how long ago did you start this process? 

Maggie Crowley: Yeah, I joined the company in October. And what’s the reason why there wasn’t a product team is at the team.

And I think this is quite common in healthcare, which I’m, new to you. So if there’s folks in the chat who have healthcare backgrounds, please chime in, but there’s a lot of bias towards using tools and processes and other sort of ways of building rather than reaching for software. In my prior role, working in B2B SAS, the default answer to a problem was let’s build something.

And in healthcare, especially in health tech, the default answer is there’s a tool for that. And so there’s just a different, mindset when you’re thinking about building, probably because I’m going to make a broad generalization, the. The sort of historical development and healthcare has not been about software.

That’s been really expensive and hard to do, and there hasn’t been enough interoperability to make it make sense. And so that’s just, they’re just not in that place where that’s the thing that everyone knows to do. And so that’s probably why, or part of the reason why there’s all are all sorts of a focus on pools.

So you can get away with not having a product team for a long time, especially if you’re validating your business model and growing, sort of the idea. And so I don’t think it’s uncommon to have product join a little bit later. So what I’ve been focused on is, okay, now that we have this business what are we going to build?

What should the team look like? To build it and starting to do all this stuff that we all know and love. 

Janna Bastow: Yep. Absolutely. So how did you begin breaking that problem down? 

Maggie Crowley: Yeah. I think this is like the sort of classic. Product strategy question. And I think what’s, really interesting is a lot of people.

And I think we’ve talked about this in the past, but a lot of people love to talk about product strategy and that’s like the shiny thing that we all want to do. But it’s really, in my opinion, it’s simple, right? It’s just simple, not easy. So it’s, if you understand where your business is going and what matters to the business and then you do a really thorough survey of where your business is right now, then there’s like a series of gaps in between here and there.

And there’s gotta be a couple of those gaps that product can solve. And so that’s what I did was just trying to get really deep with the co-founders and where we’re going to spend a lot of time mapping out what the product is right now, where the gaps are. And then given what our business goals are, there was a pretty clear like this is the right place we need to start.

And so that’s where we started. And I think given the stage, I would say, I probably could have in some other universe spent a lot more time mapping out and then. But at, some point, especially when you’re early, it’s it doesn’t even matter because you already know where you have to start in almost any scenario.

And so what I decided to do was cut off that work and say, who cares? What comes next? I already know we have to do this part. And so I’m going to go heads down and do that. And I’m not going to spend my time doing like a five-year roadmap and thinking strategically about where we’re going, because today it doesn’t matter.

And I think getting that balance right between like today and the future is another thing that was different about this, opportunity. 

Janna Bastow: Yeah, absolutely. And you can imagine in a different parallel universe, somebody else might’ve come in and just had this temptation to try to hire one of everything or get one of everything set up and try to do everything.

And I guess it must be hard to resist that temptation you’ve got nothing and it’s let’s just try to solve all the problems all at once. 

Maggie Crowley: Yeah. Yeah. And I think given that the product, when I joined had been organically created over time, I think ideally I was like, okay, I’m going to come in.

And I’m going to find the first workflow and we’re going to build that workflow step, top to bottom, and then we’ll start iterating on it. But every, the only analogy I could think of was like, it was like a big puzzle on a table. And every time I would pick up a puzzle piece, the whole puzzle would come up with it.

And so I couldn’t figure out like where was the right place to start? Because it, it was all so interconnected. And I think that’s another thing. This is a principle that we had at my last place. And I think it was probably from Amazon or something, but bias for action. Like at some point you just have to say, it doesn’t matter, you just have to get started.

And I think that’s probably the hardest part about this whole thing was how do you know how to get started when you have so much optionality? I definitely underestimated that, how terrifying that would be. And I just went skiing last weekend. This is also top of mind, but it’s like when you’re standing at the top of the ski run and you’re like looking over the edge and you just have to go.

And so there was a lot of that. 

Janna Bastow: Yeah, that’s absolutely right. And we spoke about this before, which has this idea behind decisions that are either reversible or irreversible. And I think a lot of people get really afraid of making decisions, but I think the reality is, most decisions are reversible, most decisions.

You can actually do something. And as long as it’s not something that’s going to materially change the business, you can there’s small things. You can undo them, you can try something and undo it if it’s not right for the business. And so that, bias reaction makes a huge difference in so many businesses.

Maggie Crowley: Yeah. And I also think that the, I love that point about having to the courage to make those decisions. And I think a lot about how there’s a lot of pressure and a lot of our role is to be right. And I think it’s, definitely harder to admit when you don’t know if you’re right.

 The way I handle that was always calling out when I don’t know, and being really clear about what is a bet and what am I confident in because no one really knows. And I think that’s, we talked about this too. Like one of the lessons I learned from doing the podcast is that everyone feels like they’re making it up all the time.

And if you know that about everybody else, then it’s fine to say look this is as far as I got to figure out what I want to do, like coming back to that strategy question you asked. The way, like I often find it hard to figure out what does it look like to do a product strategy?

And the way I do is I literally write a whole doc that has every sort of logic step that I took to go through that process of like, how did I figure out what our business goal was? If it’s not clear, how did I do figure out where we are today? What are all the market forces and things I need to pay attention to?

I just write it all down. And I try to explain my logic on every step. And then maybe I make a presentation if a deck is a more appropriate artifact for the team. But when you can share that level of logic with everybody else, you can highlight I’m guessing like this step break here, big guests from here to here.

And I think that helps people. It helps me make better choices, but it also helps people have empathy for that, that you’re in that position where you have to make a bet and maybe they have a better idea or maybe they don’t and then you can all just acknowledge yeah, we’re making a bet because we.

Janna Bastow: Yeah. Yeah. And that’s actually hugely useful to have like that, type of documentation for decision logging. The amount of times that even I’ve gone back on things going we did this thing, but why did we do that? And that you’ve done it because you had some intuitive decision that you made, but you didn’t actually write down how you got there.

Oh, why did we come up with that? And actually having those logical steps and say, here are the assumptions we made and here’s where it was a guest. And here’s where we’ve got evidence having that would actually be hugely useful, like a repository of that. So that’s probably a good habit to, but to take forward.

Maggie Crowley: Yeah. And if you’ve been at PM for long enough, you’ve definitely PM in a product where no way someone didn’t write that thing down. And then you’re trying to build something and some code gets shipped and all these weird bugs happen because no one had any idea that there was 15 secret features.

That were unlabeled, like hanging around in your code base. So yeah, I think that’s one of the, if you were to do it again from scratch, what would you do? And everyone I’ve asked that question to says, I would document what I did more to avoid that. 

Janna Bastow: Yeah, absolutely. Absolutely. It’s one of the things that we do here at ProdPad is try to carve out space and everyone’s week to, to document stuff the way that it talks about it is you’re paving the path for the next 20 people who are joining the company.

The next 40 people are joining the company. It’s not just for you next week, but it’s for you two years from now or the junior that you’re going to be training. 

Maggie Crowley: Yeah. That was when I was at drift before this, there were definitely, I was there long enough where there were features where new PMs would join the team and they would be fixing something and they would come to a meeting and be like, who made this decision?

And almost every time it was me and I, got to sit there and be like, yeah, I totally did that. And I can not tell you why. 

Janna Bastow: Yeah, absolutely assume good intent. I hope. Yeah. I’ve been working on pod fed long enough that I’ll be looking at things like who made this decision and I look back and I’m like, oh, it was me.

Oh, yeah. Okay. 

Maggie Crowley: It really takes the wind out of the sales of your team when you’re like, oh, that idiot. 

Janna Bastow: Oh, yeah. Yeah. I knew he documents more. I’ve learned this now. Team depends on it. It makes a big difference. That you’re talking more about that that, that, mindset, that ability to, take chances, take those risks.

I think that’s really important to get bedded in as a mindset early on. So did the company already have that mindset or did you come in with that and are having to set the stage for it? The question 

Maggie Crowley: I, don’t know. I never really talked to anyone about that. I think it’s just how I operate. Because there’s, and maybe it’s more unique to this product that there’s so much uncertainty in whether what you’re doing is gonna work and how it’s going to work because of the, human behavior aspect of it.

But I think a lot of the other roles are more this is the task that we have and we solve problems and then we just March forward, I it’s been a while since I worked with a team where when a problem, like an ops team or when a problem shows up, someone goes and solves it. And it’s one person going on solving it versus I think the harder part was the team getting used to the fact that like, when a problem shows up, I’m not going to immediately turn around with an answer instead, I’m going to say, oh, that’s really interesting.

Where does that fit in with what we’re working on? How what’s the priority. And then running a research process to understand the scope of that problem and to break it down and figure out how we’re going to solve it. I think that rhythm was more weird for the team because they’re used to like problem solution and not like problem in the context of more problems and then scoping and then research.

And I think that process was, more odd for them. Yep. 

Janna Bastow: Yep. Absolutely. And so speaking of a research process, what does your ideal process look like? 

Maggie Crowley: A million dollar question? Yeah. Honestly, we talked about this a little bit before from doing the podcast. I have so much written down about this I’m at different stages and what a good process looks like.

And I think for me, what I’ve been trying to focus on is what is a good enough process. That’s not too heavy for the stage that we’re at and the hallmarks of it are always, starting with the problem and really understanding the problem space and not making sure we don’t jump to conclusions too quickly.

Making sure that we build in a good ritual for collaboration and making sure that design and engineering and product management are all sort of spending time together to understand our problem, really making sure we have a way to bring in the, our clinical team and some other teams ops and strategy teams that we work with, which is unique to our business.

And then making sure we, start with a good understanding of how we’re going to track the success of things. And that was enough to start. I don’t think you need to do to overprocess your team. Right now we’re a full-time team of four with a large sort of contract team. And yeah, I think that was like good enough.

And then what I’ve been doing is as we just trying to pay attention to as like friction points come up and like people start to get confused. Those are the signals I look to say, okay, now we’re going to add in maybe a little bit more process. Whereas we, the team gets a little bit bigger. It’s okay, now we need to add this ritual.

Maybe we need to stand up. Maybe we need slack, what we’re doing each day in the morning kind of thing. But then I think the funny part is you can write down all of those plans. You just don’t do any of them and you just wing it some days. So there has been a lot of yeah, that’s a good idea.

We should totally do that, but can you just do a sketch or can you just build a thing or 

Janna Bastow: Absolutely. You, run into this problem that you might get process debt you end up with different processes, but they’re not getting followed or they’re getting followed by some people and not by other people.

And it creates more problem than, not. Yeah. Any, sort of thoughts on how you might tackle those sorts of issues as they start creeping up? Yeah. 

Maggie Crowley: I care more about there’s some rituals I care a lot about, and then I care more about our operating principles, honestly. So rather than focusing on, did you do every step of this process exactly as written.

Yes. I want to make sure that there’s a spec or a one pager that has all of our decisions documented. Yes. We need to make sure that we’re collaborating with our different functional counterparts throughout. And we also need to make sure we’re doing retros so that we’ve learned from what we’re doing.

Like those are table stakes, but then again, what I care most about right now is momentum and building that momentum up. And I think the best way to do that is to have the team operating in the same way. And so I spent a lot of time recently with our VP of engineering on what is that language like?

What are our principles? How do we think about. The worlds that we’re building and what are the things that we use to make decisions? And I think if the team got that really well and was really on the same page with that, that would help them even more than use this checklist. 

Janna Bastow: Yeah, absolutely.

That makes a lot of sense. And somebody actually asked a question what does to you, what does a great product management org structure look like? How would you structure this? 

Maggie Crowley: I’m just reading this question. So I would start with just the first one, cause I think there’s five questions in there.

Yeah. So I think I, it depends on what you’re building. Of course classic Pam answer. It depends. So I would say it depends on what you’re building the stage of your company. I have a lesson that I think everyone learns in some different ways is that you will ship your org chart. And so I really try to think about what is the experience that your users have or should have, and then making sure that there are people who can span, can look across that workflow to make sure it’s consistent.

And so really orienting the org chart around or the the org design around what are those macro like workflows, and then maybe building out underneath that if, it’s like much more complicated and a lot more work. So you can rough, let’s say it was a small product. You would loosely align your squads to like each user persona or user workflow.

And then I love the, like 1:00 PM, one product designer engineering manager, and then a sort of smaller team of engineers working as a team. And autonomous teams talked about them. And so that’s how I like. 

Janna Bastow: Yeah, that makes sense. I like that you’ll ship your org chart. The you ever heard of a Conway’s law one that basically states that your company will will basically take the shape, your product will take the shape of the the organizational chart that’s behind it.

So your customers will eventually see like how your company is structured based on the products that you put out and you see it with certainly larger companies and the way that they produce products. 

Maggie Crowley: Yeah. The most obvious one is that a marketing site looks nothing like the when you logged in and it’s yeah, cause they’re two completely different teams, the two completely different design teams.

So yeah, just that, but within the product absolutely happened. 

Janna Bastow: Yeah, absolutely. Sure. Ash calls it the mirroring effect as well. Yeah. Yeah. Different ways of calling the same thing, which shows that it’s just this a huge problem. 

Maggie Crowley: Yeah. And I think that, again, this is a theme and everything I’ll say I, there’s not a right answer.

I think we’re all trying to it’s if only someone would tell us the right way to do it, that we could do it that way. That doesn’t exist as far as I understand. And so it’s just about making trade-offs and like understanding where your team is going to get it wrong and then trying to deal with it.

Janna Bastow: Yeah. I don’t think there is a right way because it comes down to the context of who’s in the team. Who’s got particular skills what’s available and also what it is that you’re actually trying to achieve, because we’re not all trying to build the same product. We’re not all at the same stage. We don’t all have the same markets or goals.

So of course our org charts should all differ and it’s lightweight. There are going to be some best practices that we can create from each other, but it would be surprising if we all had the same thing. 

Maggie Crowley: Yeah. Yeah. And then an example, a concrete example of this is there are so many PM.

Competency and level docs floating around them in the world. And I feel like every product leader I know has a version, that’s they got, they started with this, company’s version and then they added it when they were at this company. And then they like added some other company’s thing and it’s like sisterhood of the traveling or dirt, or like PM competency, leveling matrix ladder, or whatever you want to call it.

And that’s an example of a thing that people would just continuously trying to get. And always never getting it quite right. Yeah, absolutely. 

Janna Bastow: Absolutely. And it’s really difficult to somebody just asked the question, like, how do you escape this? I think how do you like change the org chart that’s a really difficult question, I think. 

Yeah, I my, the way I do it is like I go to places where I can do myself. But I know, I think I really answered that question is. I’ve found curiosity in a lot of these like tricky sort of work chart. I don’t have the authority problems to be the best method.

And I think asking honest questions about why things are the way they are and just trying to learn and understand has always served me well. And maybe there, the answer is that there’s a reason that you don’t know, maybe the answer is that’s just because that’s how it happened and reorgs are painful and a lot of ways.

And so it’s not worth the cost of that. But I always just ask that question, right? Because it you’ll learn something and maybe the current orchard that UN is you’re in, isn’t a fit for you. And, but then that’s feedback that you, or knowledge that you can take to your next opportunity and you can screen a company for how they about they have set up their own.

Janna Bastow: And remember, it’s not always an authority problem. I’m a CEO. I have ultimate authority, but I can’t just reorg everybody tomorrow. I could, but they’re humans it’s difficult and you have to think about the repercussions and what actually happens. He can’t just reshuffle people like chairs, they’re not furniture.

You have to think about how the skills fit together and how that changes, how people interplay and how it affects team culture and all this sort of stuff. It affects a lot of different things, so I can see why reorgs are so awkward and so difficult. And not just type of thing, you can snap your fingers and do.

Maggie Crowley: As a manager, I would also say that a thing I try really hard to do is to acknowledge where those like when and where those situations may arise. So maybe team members are joining right now. I try really hard to say things. This is what it is today. These are the reasons why we might decide to change this in the future and the factors that will play into this decision.

Because another thing is okay, you’re the CEO. You, have such a view that your team members don’t have. And I think this as a sort of person, who’s moving up in their career, you start to see other levels of what the conversation is and like why people are making decisions. And what I always thought was weird is like, when you’re an individual contributor, you don’t know why those work decisions are being made.

They just happen to you. And I try really hard to explain them because it’s like, they, don’t just, it’s not the whim of a person. Hopefully it’s not the whim of the leader, but there’s a reason. And you can describe that reason to somebody and maybe that’ll help them understand. So I also try to be honest with.

Janna Bastow: Yeah, absolutely. Sometimes the job of the product manager is interpreting, figuring out what’s going on and what the the the, motivations are behind various decisions and trying to re-interpret them in ways that make sense. And sometimes they do make total sense.

It’s just that you weren’t necessarily looking in the right places or sometimes following the money, figuring out oh, actually it’s tied to your bonus. That’s why you’re doing it that way. Or it’s tied to a particular way that the business operates and makes money. But we were looking at it in terms of these types of user values.

Didn’t align that’s an issue. And sometimes it’s just a complete misunderstanding or sometimes it actually does really help people understand things, but the product manager can be really, helpful in those situations with with, clarifying that. Yeah. And actually that takes a test to another question.

Somebody asked the question around how to manage the relationship with founders. Sometimes you aren’t you not being active in product or sometimes don’t necessarily have the the closest relationship or don’t understand product. 

Maggie Crowley: Yeah. Yeah. This has been a really interesting journey for me as this is my first time working with founders who haven’t really built so much software in the past.

And I think there’s like the classic. I get this question a lot, actually, when I’m interviewing people, asking this because they want to know, is it a founding situation where they’re like, you’re your tech support or are they really believing in product? And I’m obviously oversimplifying they believe in the product and they value what you do.

Okay. Yeah. And I wouldn’t have joined the company if I, if it was it support or just like a service org that just does what they’re told. But what I found was that it’s really hard to communicate what product management is to people who have never seen it in action. And there’s a million articles written about this on medium or whatever, but it’s just like really challenging to do that with words.

Especially when you’re remote. So you’re remote you, can’t, there’s very little non-verbal communication and you’re saying words and there’s nothing that they’re seeing from you. And so I spent a bunch of time spinning my wheels on that in the early days. And then I had this amazing principal designer and I went to him and I said, Can you just spend an hour and queuing, get your iPad or whatever, and can you draw five things for me?

And I just need to, I need this tool. I need something to communicate what I’m trying to get across. And so we just started doing these like really lightweight sketches on iPads and like sharing photos with each other. And that was how we started to involve them in this is what we mean by what we’re doing.

This is what this, is why this conversation is meaningful. This is why we’re asking these questions. And so I think just like moving way, faster than I normally would have to sketches was the best tool that I had in my like toolkit in the. 

Janna Bastow: Yeah, absolutely. And actually I think you’re absolutely right.

It’s really hard to explain what credit management is. If you haven’t seen it. And oftentimes you can’t really explain what it is until you take it away. It’s sometimes really hurtful when she’d be like what’s the point you mentioned really? Do you know if you weren’t here tomorrow, we’d be fine.

You’re like, actually you actually would write if the developers weren’t there, nothing would be developed. If the marketers weren’t there, the salespeople, no sales would happen. Fine. We get that. We give you a couple of weeks a couple months you’re going to start building just random stuff.

And then you’re not going to have a product that, that actually. It takes off and does great things. You still need someone doing product management. Otherwise you’re not going to end up with a product that actually solves real problems. You need somebody doing this stuff. And oftentimes when you do have a team that doesn’t have a product manager but still doing really well, you have a founder who’s been doing the product management or somebody on the team has been doing it and they just don’t acknowledge it because they didn’t have the hats didn’t have the role calling it product management.

It makes it really difficult to explain what it is because it’s a, hidden skillset, I think. 

Maggie Crowley: Yeah. I also I, screened for this too, because I think I want to have a team. Understands each other’s roles and values then, because I think that’s going to make for better collaboration and a better team environment.

When we value what engineering brings to the table and engineering values, what PM does, and like design same for design and engineering and design and product management. I think all functions have to have a really healthy respect for each other. And I, think it’s even, I would even go so far as to say like views, the other skill set is like magical because it’s not like you do this thing.

That’s so cool. Enters your you’re like making something out of nothing. I don’t understand it. And design you’re just like creating these things and you’re like driving to solutions in a way that’s really magical. And hopefully they can feel a little bit of that from product management as well.

And I think that’s, the kind of interaction that I think makes for the best teams when it’s not only oh, I get what you do. 

Janna Bastow: Yeah, absolutely. And somebody actually asked about the opposite, speaking of teams who respect different divisions and areas. What about founders who insist on making all of the product decisions themselves we get to?

Maggie Crowley: Yeah. That’s a tough one. I think, you know what I thought about this a lot in, past companies and I think. It’s really easy to fall into this narrative where you want to be autonomous. And then there’s a lot of stuff around how you want to have an autonomous empowered product team. And you want to be autonomous.

You want to make your own decisions and totally, we all want to be autonomous, but at the same time, if you’re working at a startup, you joined because your founders had a really great idea that you believe in, and they have a unique point of view on the market and they know more about you or not about you.

They know more about the market than you do, hopefully don’t, they don’t know more about you. So there’s a reason why you joined them and you believe in their mission. And so I think it’s really weird when this comp this question comes up because it’s like, why do you no longer trust that intuition?

And instead I would frame it as why are they bringing, maybe they don’t have the right language and maybe they’re not showing up at the right time. And that’s frustrating, but you can deal with that. I try to take a point of view of, okay. What information did they have that I don’t have?

What am I missing that they’re seeing that makes this thing that they want me to do so obvious to them. And so I think it’s really easy to see it as like an, you could take it as an ego hit, like you got it wrong and they want you to do something different, or you could say they have different information.

And I want to get curious about what that information is because maybe then I would make different decisions. 

Janna Bastow: Yeah, absolutely. I think the, some of the confusion comes around or some of the, clashes comes around us, whether they’re trying to provide insight as to which problems need to be solved, which they should have really good insights because they’d been in there longer than you.

They have that insight, as you say or whether their insights are around how quickly it can be delivered and whether the team can deliver it and when they want it and that sort of thing, which all of a sudden, you’re like, no, actually I’m the expert in that I know how to deliver stuff.

Maggie Crowley: Yeah. And then this might be a harsh take, but then I think that as a product leader, you’re doing a bad job. If you’re not able to manage that conversation and help them understand the why’s of what you’re doing and the why’s of the timelines to their satisfaction, like that’s on you that’s your job, that’s your whole job.

I can hold you up, but it’s a lot of your job. So if you’re struggling with that, then I would look inward and say what about your communication style is not working for this. 

Janna Bastow: Yeah, absolutely. And that’s one of the tough things about a product manager. You’ve got to manage both across downwards and upwards and managing upwards is often the toughest one, because you don’t have any authority in that sense.

You’ve got to manage through influence and you’ve got to sometimes make these tough calls and stand up for what it is that and believe in, which can be really tough 

Maggie Crowley: Yeah. I think I had an Actually an interesting one more concretely that I can maybe talk about where I, something was obvious to me having worked in product for however long and it was just one of those things that I don’t think if you’ve been a PM for a while.

No one would question this thing that I was talking about, but I had assumed that knowledge and the team and the way I said something was like obviously the answer is X. And there was a lot of whoa, like how could you pop? What? And I realized that I hadn’t had empathy for no one had the same knowledge that I had.

And I sounded like really aggressive was saying those words, thinking that it was just like an obvious thing. And so I’ve had to take a step back and focus a lot more on how scenarios. So if you’re in one of those situations to be concrete you can do things like, okay, great. You want to have, actually, this happened two weeks.

You have this really amazing idea for this thing. You want it to be done yesterday. Awesome. I love this idea. I want to understand what the potential impact is. Give me a day, I’m going to go and figure out what it would take to do it to three levels of satisfaction. And then I’ll come back and okay, cool.

We can do this here. All of the things that we said we were going to do classic, like this is the, plane, the game board that we have. We only have this many people. We only have this much time. And this is, these are the options. And my recommendation is X because of AB and C, but like we can do the other one.

And I’ve almost never been in a situation where people aren’t reasonable about that. And again, it just comes back to what are they, why do they want to have that thing to their.

Janna Bastow: Yeah, absolutely. This is always something that I’ve always tried to do is bring them along for the journey show them the constraints.

 When I first started building ProdPad, one of the first inspirations was a whiteboard that I took over which was essentially a place where I took the ideas that some of the people on my team had and showed them in a very visual way when they came to me saying, we’ve got this great idea that’s great.

Let’s take your idea and put it on a sticky note, and then we’ll help me prioritize it. Is it more important or less important than all the other things that we’re thinking of? And I’d have them visually see as to all the other things, because otherwise they’d say this is the most important, great you can watch all the other things fall off the list and they go, oh, so there’s still a lot of things to happen. Yeah. So you can see this growing list that I’ve got to deal with. I’m not forgetting about them, but you have to see. There’s a lot going on here and we have to make decisions together. I’m not just saying no to spite it’s the product entrant system that is saying, no, we can only do one thing this week and you get to choose.

Maggie Crowley: Yeah. That’s, I think that’s, the best way anyone does this, but at the same time, the thing I struggle with is how do we create like a positive sort of everything is possible environment and not just like a constant stream of negativity, because it’s so easy to be like, we have a million things we’re never going to do anything.

So I think a lot about like, how do we keep that list small so that we can do things that come up that are good. Cause I think it can be so stressful personally to have that giant laundry list of things that you want to do and then you never make your way through it. And it’s just like a burden that you drag.

Janna Bastow: Yeah. My take on that was always to flip it around and say you know what? Most of this stuff we’re not going to get to and that’s okay, let’s just turn around and say what problems do we need to solve? And why? And then we’ll pick the things that allow us to solve those problems.

And the rest of it if it’s important, it’ll come off. That list hit into here and the rest of it don’t just ignore it for now. And if it’s important, we’ll pick it out. And that way you’re working with a much smaller subset of things that solve problems and things that solve problems. And people keep talking about stuff that doesn’t solve problems, unless you can identify where it’s going to solve a problem, then it doesn’t get onto the smaller list, which I call a roadmap.

Maggie Crowley: Yeah. My old, one of my old bosses, Craig, for those of you who might know him from the podcast I remember very vividly. One of the first, it was like week one of working with him many moons ago. And I was like getting trying to do a really good job and like keeping track of everything I was doing.

And he said, Don’t worry about it and I’m looking at him like no, I have all these ideas. I have to keep track of them. And he’s if it’s a good idea, you’ll remember it. And I just was like, I can’t, I cannot believe you’re telling me to just delete this list of things that it’s by precious baby.

And he was like, yeah, it’s a good idea. It’ll come back around. Like you’ll never forget the really good ideas. And I still struggle with it a little bit, but I think it was some of the best. 

Janna Bastow: All right. Yeah. Now I remember hearing that advice too, if it’s a good ideal, you’ll remember it. And I remember that absolutely painting me because I don’t remember anything.

I have ADHD, so I don’t remember even good ideas. Brilliant ideas passed me by. So if I don’t write it down, it’s gone. And so I think that was partly a coping mechanism of no, write it down, even if it’s bad, good, whatever it is. And that way it helps the good things float to the top.

Maggie Crowley: That’s okay. That’s a good balance to what I was saying. 

Janna Bastow: So don’t always assume that you’ll remember it depending on your, neurological state of mind. We were talking a little bit about the delivery side of things like in your dream team, our delivery managers required. How does that, how do you split that role with the product manager and that side of things?

Maggie Crowley: Yeah. Hot takes. Maybe, I don’t know. I don’t, I’ve never worked in an environment where that is a split. And I think this is again a very, I don’t want to offend anybody, but I don’t understand it because to me, you’re taking away the accountability of the team to be responsible for their own work.

And so I think the PM has to be re like a PM’s job is not to ship software or whatever. A PM’s job is to create business. And the right business value, however that shows up. And so they have to be accountable to the impact that they’re making. And at the same time, an engineering team is accountable for their work.

So I think having a, another way to say this, or when I hear you say that, what I think is a PM. Who’s helping project manage the engineering delivery. And to me that’s strange because it’s like the PM is not the person who’s doing that work and we should all be responsible for our own work.

And so we should be responsible for getting our work done on time. And so I have this conversation with our VP of engineering last week, about who who is the person who is responsible for hitting the deadline. Once it goes into build, and that’s like the engineers and the engineering manager, and ultimately the head of engineering because that’s us being responsible for our own jobs.

And so I feel really strongly about that because. You, can’t have to go back to our earlier throat about autonomy. You can have autonomy without accountability. And so you have to build an accountability in your team to make, to make it all run properly. 

Janna Bastow: Yeah, I totally agree. And actually, I’ve got a story for you going way back in my career.

When I was a product manager and the, team had grown quite a lot, right? I’d take on funding. We’d hired a whole bunch of people. And the team was just in kind of chaos. And so the, CEO hired in a scrum master who went by the book, right? This, person came in and just did everything by the book.

And he took the develop dev team and broke it up into four squads and basically had them do scrum for scrum sprints for the next. Two three sprints and I’ve never seen a dev team gets snapped into shape so quickly and deliver so much stuff so quickly and yet deliver no value whatsoever. Just the stuff that they were doing.

They totally disempowered me. Like I had no say 

Maggie Crowley: And I was like, oh no, am I wrong? 

Janna Bastow: I just sat there and be like what are you all working on? This isn’t what we needed. They just worked on whatever they, the scrum master said, I’m like, that’s not what was needed at all. Like we’re supposed to be working together here. 

No, So you needed to have the alignment towards the goals first and then work on the, functional delivery next. But instead they optimize for the other first, which did not bode well. 

Maggie Crowley: Yeah. I also think when I hear stories like that, That there’s this like pernicious narrative about engineers not being fully formed human beings, who can have judgment about the impact that they’re trying to make.

And I think shielding and engineering team from the point of what they’re doing is such a weird thing. And they’re like, of course they want to know why, what they’re doing matters. And of course they should be involved in that decision. And of course they should understand the choices that they’re making, how those are going to relate back to users.

And I think it can take time and be onerous to give, make sure everyone has that context. But I think the more you can do that, the better your product is going to be because they can make good decisions at the margin when they’re building. And they’re like, I think engineering leader I worked with in the past, he has, he always said engineers are creative problem solvers.

So treat, them as such and they’ll do great work. And so that’s a foundational principle. 

Janna Bastow: Yeah, absolutely. As a, as Marty Cagan, who said, if you’re only using your engineering for coding, you’re wasting half the talent. Yeah, absolutely. Yep. And actually there’s a good question here from a shriek Manji who said, in what ways can a junior PM fit into a product team if they’re not yet able to take ownership of the. 

Maggie Crowley: Yeah, I was just talking about this with someone on the team this morning.

I think the challenge about hiring PMs designers, engineers, without any experiences that you have to have enough people around them to coach and mentor and help. And so it can be really hard at an early stage to hire someone without experience because you don’t have enough time to give them what they need to be successful.

And so I think I, it always hurts my heart when I have to say no to people who are really, early in their careers right now, just because I want to do that. But it’s don’t have enough time to, to be a coach and mentor for every. But I think if your team is a little bit bigger and can take on a junior PM, I think the way I’ve seen it work really well is when you have a really nicely defined and scoped problem, that’s like relatively has relatively clear steps.

And was, if you think about the career ladder as grow growing in your level of ambiguity, that you can handle level of scope you can handle and how much impact you can make on your own finding, like important, like not silly, not make work, but really important stuff. That’s well, relatively well-defined that it has some simple research needs and just like trusting people to do the PM job with some oversight on their own.

And that’s, I think the best way to help people come on board. And there’s always like research tasks and there’s like documentation needs to happen and other things where PMs can pitch in and learn. But I, think that like I would only hire a PM and give them PM work. I would never really hire a PM and not give them a full product, even if it’s a tiny one.

Janna Bastow: That makes sense. I like that. And so where does testing and QA fit into your dream team? 

Maggie Crowley: Good question. So full, disclosure. I have never really only briefly have I worked at an org where there was a strong, like a QA team. So I’ve only really worked in environments where the team does their own QA for the most part.

And there’s obviously lots of challenges with that, but I think, again, it comes back to speed and accountability, and I like that. I really like it when the team is responsible for their own work and has to make sure that it works. I think there’s a really weird dynamic when. Finish something.

And that finished thing is not functional. And so again, I think it comes back to whatever system is going to make sure that we’re accountable for our own work and help us ship good softwares what I want to do. And I would also hopefully have a strong engineering counterpart that has a point of view on it.

Janna Bastow: That makes sense. That makes sense. And what about a user testing? So the other end upfront. 

Maggie Crowley: I think just all the time, all day, as many ways as you can. And there’s this is a way I would think about it. I think I, and I, Teresa Torres, I think she, she has like the best models on, this.

And there’s lots of books written about how to do user research effectively. And I think for me, it’s really about. Making sure I have a system where I can, or the team can connect with users all the time. And so whether that’s, you need to have a good group of people that you can talk to ad hoc, you need to have structured user research.

You need to have really good data coming in. I think just like baseline, have that happening all the time. And then always make sure another part of this is making sure that in our principles and in our language, we have ways to make sure that we’re in being specific about users. So a trick I always try to be like tactical, a trick that I use as a leader on our product team is when someone says, and I know Eliana’s in the audience and I’ve done this to her.

So hopefully she’s going to laugh at this. When someone says our users want X, you have to ask which users, how many users, what did they say? Can I see your notes? Like you just have to be really specific about it. And that helps your team really get in there and like really talk to the people and really learn because you don’t want them to be making generalizations.

And so I think it’s. As much as you can talk to users and then make sure you’re being really specific about how you’re using that. 

Janna Bastow: Absolutely. I see a habit in teams all the time where they, say that a, bunch of people have, asked for something, but in reality, they lost track of who this bunch of people are is live on two people.

Yeah. And it lives in fairness lives in probably some sort of CRM somewhere, or it lower passed on from a bunch of salespeople. Or and probably there were a bunch of people have asked for it, but that information has been lost along the way as to who asks for, and specifically what they asked for.

And then this is game of operator where, you know, when one person asks for something and then it gets passed around. And so by the time the thing is actually built, you end up building something that’s maybe adjacent to what they needed. And they asked for problem a, to be solved, but you solve problem.

Be slightly different problem. And by the time you actually get it out there and launched, you’ve forgotten who the person was. And so your marketing team just launches it out to everybody. They just tell the world, they just put it out there as a blog post or a press release or something like that. And then the person who asked for this year in the first place never actually knows that you actually solved the problem.

So you just end up in this cycle of constantly shipping features. It’s a feature factory and your customers don’t even know that you’re trying to be user focused, even though it sounds like it feels like internally you’re constantly shifting what the users are asking for. 

Maggie Crowley: Yeah, yeah It’s it’s such a hard topic because it has to be woven throughout every step of what you do.

I think to do it really well and to be truly like customer focus or user focused or whatever. And I it’s, that’s why I keep coming back to language because I think when it’s part of your language, like when you’re starting from scratch. Then it just becomes part of your culture, if that makes sense.

And so that’s what I think about even more than just making sure that we’re doing user testing, just end user generative, user research and user testing. It’s just making sure that we talk about it all the time. 

Janna Bastow: Yeah. That makes a lot of sense. Like actually sharing it with people, a team, and again, bring them onto the the journey and making the product management and the research part more transparent.

Maggie Crowley: Yeah, to that point my suggestion would be record, record them and post them do you do a user research session? Even if it’s a casual chat with a person who is a user record, it upload it. And what I do is I record onto my laptop. I upload to loom, I posted it in slack and I write my two takeaways.

Like it’s easy. That’s what I would do. And you just do that all the time. And eventually people start to see that. 

Janna Bastow: Nice. Okay. I always like those as sort of tool recommendations. And actually somebody asked the question earlier on, because we you’re talking about decision unlocking any recommendations on how to get started with decision logging for a team that’s not used to documentation yet.

Maggie Crowley: I can not claim that I’ve conquered this mountain yet. But I would, it doesn’t matter. Just write it down. My opinion on every tool is I don’t care. Just find one and use it. There’s no perfect tool. Okay. Maybe Brad pad, shout out. Admittedly. Haven’t used it, but Jan, I’m sure it’s amazing. I am using now next later, I am slowly trying out this new model.

But yeah, I would say like when you get started, the tool doesn’t matter. As long as you’re. 

Janna Bastow: Yeah, basically you can log this stuff in broadband, but log it anywhere that you can search right. Anywhere that you can basically find it again later. Your team will thank you down the line. Just start writing stuff down and putting it places.

That’s the important part. 

Maggie Crowley: Yeah. I would say the only opinion I have is make sure it’s cloud-based yeah. 

Like even email it to yourself, honestly. And it could just be you emailing stuff to yourself going, we made this decision because X honestly, just little things like that will make a huge difference if you’re trying to think things through.

And also just the process of talking it out can make a difference just writing it down is talking it out and you actually might clarify the points that you’re trying to make to yourself by writing things out. I’m just looking through some final questions here. Do you have any sort of decision matrixes or anything like that you use.

Decision matrix, this sounds like a partisation question to me. And the way I do this is the same, really the same way that, that I do this strategy thing that we talked about at the very beginning. I think every prioritization gets really easy when you really understand what matters. And I think when you’re caught in one of those like really complicated prioritization math frameworks, to me, that’s a sign of a couple of things.

One, you’re not really clear on the goal, and you’re not really clear on like the one goal and the biggest gap that you have to that goal. And two, you are not building confidence in your ability to make a decision. And I think those are the two things I see when I see really complicated prioritization matrix, matrices.

And so I would always say go back. Maybe as this, where we say first principles, I don’t know, go back to what is the point of your, what is your point, the point of view right now, make sure you really understand that. And the more clear you get on that, the easier it will be to figure out what the right path forward is.

So that’s, what I do. It’s not, I don’t know if you’d call that a framework or just a process, but that’s how I make. Okay. 

Janna Bastow: That’s really useful. Yeah. And I think some of the best addition frameworks are the ones that are licensed simpler and things that people can understand, nothing worse than a decision framework that people are like, ah I couldn’t be bothered to follow the flow chart and mark it all down.

It’s more about stuff. Just giving people an understanding as to how they should be logging stuff and how they should be keeping others informed about decisions. 

Maggie Crowley: Yeah. And the last part of that question, I just want to talk about really briefly the decision by committee is a really good one and a thing that I think about a lot.

And I think honestly, back to this question of building a software team amongst a company that wasn’t used to it, one of the other weird things is this, idea that there’s not consensus and consensus decision making will lead to like lowest, common denominator, bad decision-making.

And so bringing in the concept of a directly responsible individual or DRI for something. And just saying, like seeing the words out loud, there will be times when I will take in all of your feedback and I will not do it and I’m going to do something else and I will explain why, but this is my decision to make for whatever reason.

And we just all have to like, acknowledge that. That will be weird. 

Janna Bastow: Yeah. Yeah. Totally. All right. So time for a couple of quick fire questions, a couple of people actually asked about the sketches that that you talked about. Are these anything that you have published and can share, or is this sort of specific to your situation at that time?

Maggie Crowley: Yeah. Specific to my situation at times. So I can’t share them, but okay. Take let’s say your business has an app. And you were like trying to explain what an app is. You probably draw like a sort of phone sized rectangle, and you might put like NAV items in it. And then you might send that it was literally just an apple pen on an iPad, like drawing stuff.

Janna Bastow: Cool. Yeah. And I think that’s really important just like using visual pieces to explain what it is that we do. And how things fit together. 

Maggie Crowley: One other one, we also use Miro boards to diagram out how information would flow around. So there was a lot of sketching around about and then this information goes here and then through this thing.

Janna Bastow: Excellent. All right. And final question here is are you going, when are you going to launch another podcast? Launched another podcast. The last one was so good. It says Ricardo. 

Maggie Crowley: Thank you. I would love to do another one, but I need I’m, gaining examples and fodder, I think through this experience right now.

And I think maybe once the team is a little bit more set up than we were a little bit more running, forward together. I’ll circle back to that idea. It, I learned so much and loved doing it, so I would like to do something like that in the future. I don’t know exactly what shape it will take, but stay tuned .

Janna Bastow: And otherwise, how can people find you? What’s the best way they can find your writing or your tweets or your whatever? 

Maggie Crowley: Yeah. Just Twitter is usually where I’m hanging out these days. At Maggie probably would love to chat with everybody. I try to share what I’m up to there, and I think right now I’m just trying to execute all the stuff I’ve learned in the past however many years.

So I’m not sharing as much. But hopefully I’ll, have more to share. 

Janna Bastow: All right. Wonderful. Thank you so much for taking the time to share your story with us. I’ve learned so much and I’m sure everybody else here has as well. And thank you everybody for joining here today. You are absolutely welcome to join us back here again, next month, when we’re going to be having another product expert fireside series webinar.

This time with Melissa Perri, we’re going to be talking about product ops. She’s the best that’s going to be March 16th, same time, same place. See you all back here. And this session has been recorded, so you will be able to see this online in some days time. Keep an eye out for that.

And thanks again. Thank you again, Maggie. Talk to you later. 

Maggie Crowley: Thanks for having me.