Episode Thumbnail
Episode 68  |  17:08 min

Maggie's Top 5 Product Lessons for 2021

Episode 68  |  17:08 min  |  01.15.2021

Maggie's Top 5 Product Lessons for 2021

00:00
00:00
This is a podcast episode titled, Maggie's Top 5 Product Lessons for 2021. The summary for this episode is: A new year means a chance to reflect and learn from the year before. So in this episode Maggie looks back at what she learned in her day job and over the past year of Build and shares the five lessons she is committed to bringing into 2021. Like this episode? Leave a ⭐️⭐️⭐️⭐️⭐️⭐️ review, hit the subscribe button, and share the pod with your friends! You can also connect with Maggie on Twitter @maggiecrowley
A new year means a chance to reflect and learn from the year before. So in this episode Maggie looks back at what she learned in her day job and over the past year of Build and shares the five lessons she is committed to bringing into 2021. Like this episode? Leave a ⭐️⭐️⭐️⭐️⭐️⭐️ review, hit the subscribe button, and share the pod with your friends! You can also connect with Maggie on Twitter @maggiecrowley
Warning: This transcript was created using AI and will contain several inaccuracies.

Welcome to build. This is Maggie. It's a new year. Thank goodness, which means that it's time to reflect on what work last year but didn't work and reset for the year to come. I want to look back at 9:20 and pick out the lessons. I learned both for my day job and from the podcast that I want to carry into 2021. Obviously there were things going on last year that colored everything that I learned and experienced. I'm going to soak the Five Lessons. I'm taking from 20/20. Our products are workflows commit to date your team is your peer group when in doubt it's your job and never forgot to sweat the details. Let's start with the biggest lesson learned and that's the products are or close. This lesson goes out to be Sr. CTR co-founder. I learned it or probably we learned it from him last year. So typically when you're working on a user problem or story, I think we frame it as the user has this specific problem and that problem gets in the way of them achieving whatever outcome it isn't were looking for and we are hopefully prioritizing solving for that outcome verses

And then once we get into the solution space be focused on the specific challenges that has every single part of Team operates. That way then every team is just looking at the section of the product that they're changing to solve that specific problem is identified. And then you start to lose sight of the overall user experience which inevitably is going to cross each of those kingdoms and what they're working on the price of having small a Thomas seems that you can lose track of that bigger picture and you can get into a situation when you're solving problems and as a p.m. Unknowingly creating workflow issues for your user because those were closed happen outside of the domain of the team that your aunt.

I was running into this challenge last year and we came up with a ritual that has really improved how I think about their product that were building as a whole because it forces us to account for the full user work slow. Even if the thing or changing is every week. We have time set aside to go through work in progress. And the new part is that the format is the same almost no matter what stage of the process you're in from pitching a problem to solve Two showing progress on Research to showing a proposed concept 2 showing the solution for ticked off at Sara the deck that has the problem outline using a specific and real customer with their real information to highlight the issue followed by supporting research on how you identify the problem why it matters for the user then a one-page summary of that solution that point five point makes it clear how it solves the specific problem using it for that specific user. And then the last part is a really detailed start to finish.

Of the user workflow of the proposed solution to each of these sections gets added on really as you move. She's at work. So you might start with a pitch on the problem and your research and then you come back sometime later having added on the concept picture of a solution after you done your Discovery work and then you come back maybe once again when you're moving into build to show progress on what it's shaping up to actually look like in reality. The thing is most important is that the problem is in terms of the user and that the solution walkthrough is the entire user experience from logging in what it looks like on their screen how they get the problem area. What's the new experiences like and what happens after even if again 90% experience isn't changing you have to force yourself to show the full thing and the practice of fatalities outlines and use that we're forced to stay accountable to the problem and the entire work so that the user has to go through serve no matter where your team is that means that we end up being able to reduce the weird stuff that happens when your shipping

Dear future start to get messy you end up getting way better feedback from the people you're sure because you give the reviewer a ton of contacts that they can use questions any better suggestions. Cuz again, they can see the Falls Dover logic and everleigh insertive nicely contact way and it also ends up creating a story for your product like going to the exercise you create a shared narrative about the problem and the user and the way you're solving at the other teams can grab onto as you do more and more of you version and I did this for a big project that were actually building right now we should because all maybe I'll do a show about but the document that were using has gone from a pitch on the problem to a pitch on the solution to a concept outline that we used to help constrain the individual teams work Meister of Canada. Who which team to a living document that are now using to power any woman for our sales and customer success. And the lesson here is to ask me because managers of product managers and above

What is all about more than individual Feature work? We're responsible for the whole product experience. So we need to think in terms of that hole products and this ritual just one way that were folding. I just really useful and relatively easy to do and it's so many more areas unexpected. This is a perennial lesson and that's that dates are the best forcing function, even if they're arbitrary and yes, they are basically always arbitrary. The thing about billing software is a cross-functional team is that it's really hard to establish when you're done with basically every step in the process. There's always more research the p.m. Can do in the Palms base. There's always more than designer can do to prototype in diverge. There's more that the tech weeds and developers can do to produce Technical Solutions. And then of course, there's always more features that users just have to have for you know, whatever it is that you're trying to sit outside of getting the problem right in the first place. I think the next

Most important thing to do is to figure out the right amount of scope for solving that problem. And the best way to do this in my opinion is to commit to a date that day. It's going to Signal the appropriate amount of scope that the problem is worth. Right. So if it's 6 months of work, that's a ton is gopal really nasal problems versus if it's a week. It's a really small my scope not have to bring you one thing to note is that you can't pick those a scope and at 8 to start. If you define a feature set and a date you're going to let your team that the sale the teams have to use a problem and the date as a way to create a healthy can think for themselves and cut on this point. John Cutler has him back. He said there's a huge difference between a psychologically safe team of relative equals agreeing to a forcing function. They find helpful and someone else forcing a forcing function, right? So you can't force this on a team that has to be a tool that they use to help them build their picking a day's going to help you establish the amount of stuff you want and second picking it is also going to give your team a way to keep themselves accountable.

Plan to tractor work and to learn from what they're doing without a clear and shared Line in the Sand like a date. It's really hard to know how you're doing. And that's not because again Fates I or you need something to use as like a hammer against your team, but it's because the whole name of the inner product is iterative development to get better at what we're doing right? So if you can't evaluate help, it's damn hard to figure out what you're going to need to do to get especially as you move up in your working with lots of teens having clear specific constraints like problems and dates that are written down invisible becomes even more important for transparency and accountability and despite the natural tendency of a team to spin things when they share with you where they're at. I just something that's always going to creep into an organization and being exposed about the stuff really helps.

Another reason why I just made the list for me in forcing a team to take a date. You're also going to uncover all of those weird feelings and fears of the team has about that project. Are they reluctant to pick this is a day they picked like outside of what you thought the problem was worse. Those are amazing signal to dig into that. You might not otherwise pick up on especially if your remote and you're not getting these are some of the same Vibes that you might be used to getting when you're sitting in a room with the team and one of my favorite moments of last year was when after a ton of work on a problem actually the first lesson from making the story we did that understand the right amount of time that problem is worth to us the engineering director. I work with takes a date. It was a huge date and really important day for us and we all had to look at each other like shit. This is real or going to do this and that commitment felt good and I'm obviously going to be nervous about it until we hit the date, but I think it's a good nervous because

Is that we were ready to call are shots. We were done and third lesson your team is your peer group not your direct reports or your buddies that are in your same function at your same level. This is a short one but a good one that I learned this year from Craig. It's one of those things that can start to hold you back. If you don't figure it out as you move up, it's definitely something that I wouldn't have figured out on my own and I love it when I find out those subtleties of moving ahead Unwritten rules because then obviously I can do and what does it means that as a p.m. Your team is not the individual developers. You work with It's Your Design partner your Tech lead the product marketing manager you work with Sarah. You don't want to fall into the Trap of trying to be best friends with everyone on your team. You absolutely need a good working relationship with them. But at the end of the day you have to be able to make hard calls regardless of feelings as a product leader. My team is really

Injector I request a design director. I request + marketing director of sales directors and leaders that work in the same area. Where is he and we have to work together in order for the product because success is more than just building. It's making sure that the go to market works that are users are successful with it. And then it's making us money and that's a team that I have to admit time in to proactively fine with to work requests. Not necessarily the other product directors or my direct reports at all. Although of course, I love them and then the cross functional team at the level above you is who has to know your work an advocate for you. If you're looking to get promoted. I think it would be easy to brush that off the politics. But another more valuable way to think about that is that if the team knows your work and values it or is that he knows you're working guys that you've been doing things that are meaningful for the business, which is what you should have been doing anyway, and it's a good check again staying in the safe zone of just talking to you. No other product design and Engineering folks out there.

do you work and make sure that it matters in this is the one that's probably the most top of mine because of the collective exhaustion from the last year but it's to look out for in spite the it's not my job cuz he's a good test for whether is a sneaking into your bladder team is it when it's not clear who should do something when that task is totally flooded into a tourism has anything and the problem is that there's almost always a general sense of whose job it is and who would be good at step up and it. Person manager doesn't step up your starting to allow a little drop of annoyance or resentment to take place in the room because eventually the person who's going to volunteer is going to be a person who always on tears or the person who everyone looks too because they're awesome and they get it done and there was no look and say what can you do it, but that's how that person or those people start to burn out and how

Those awesome people that always volunteer start to resent the team in each other or how you create an environment where they were just endless problems and there's no energy to solve them because it's such a pain in the ass to figure out how to do it and get even worse and start to look like there's no consequences for not doing your job which increases the bad finger pointing and resentment spiral but to avoid it you have to hold each other accountable you have to always have clear owners for different things that you're working on. Ideally you set those owners when you're all feeling you have to Foster good discussion and honestly good arguments amongst your peer group and I think they're really important less than taking from this is that you have to be resilient because eventually it's going to be the thing that you are responsible for the debts that gas exploded in one of those conversations. And so you have to be honest right and ask yourself like are you contributing Scott disease?

Making sure you stamp it out and it's really easy, especially if it's something that you already know you should have done if you didn't do it comes up and when those meetings it's so easy to just stay quiet because it was that you were supposed to do but I think the Hallmark of a great team is on everyone's upset. Last one number five that's never forget to sweat the details. So like I mentioned earlier the whole game here is to ship the right thing at the right time, but the only way to do that is either to get lucky or to make sure that you're getting better at it every time you ship and that's why Everyone is always harping on shipping and handling because you increase your chances of getting up more right the next time if you ship small

If we're going to focus on getting better have to practice guitar version of practice is just doing all of the things we know we should do right that's following are process fucking threat number of customers doing the right steps will get all the data. We should falling all the advice. We always ignore like over communicating with people always doing the freaking retro the list goes on musically sweat all of the little details of the process every time I learn from it and you're going to set yourself up to Win 4 2020. I had a lesson on how following up is as important as shipping in the first place, but as the years went on I was learning that it's more than just following up you can go wrong at so many points along the way. So instead this year. I want to focus on being diligent and inexhaustible at hitting every step of the process including making sure there is a process before I start something not only does this mean that I'm going to get more reps and sets on each part of all these things, but I'm also going to create environment where I can learn from each step along the way.

The sooner we can learn the sooner we can get better. If you're not being explicit about what you're doing in the goal for each type of the work. He gets really hard to figure out what to learn. So an example of where they shut up for me last year April. I started working on something that was already in progress by another team. Are we done, and instead of rechecking everything? I assumed a bunch of stuff start process has been completed short version of this is that I I got this concept design and I was looking at as if it had been validated when it hadn't and I sought the problem had been spoken agreed upon and I made so many stupid mistakes all at once because of that I wasted probably two months and figuring out where I had gotten wrong then trying to dig myself out of the hole. I had created by trying to move forward with something that didn't actually have a strong Foundation if I had just made sure even just for my own knowledge to catch up on the whole set of steps. That should have come before that and make sure I sort of understood what had happened and I would have given

How much higher chance of being successful this is? Absolutely not that someone didn't do the work. They should have it was my fault. I personally made some shortcoming assumptions. I was a lazy by checking them which is definitely an example of not sweating the details when I did finally asked the right set of questions. I got the loud and clear answers that would have helped me a lot of time before really the lesson here is that is it's easy when you're trying to move quickly when you have a certain amount of experience when you're familiar with this feature working in to make a lot at least it's easy to say that processes for people with less experience or for new people on the team. But really it is also the best way that an experienced person can prevent themselves from falling for their own opinions. If I had followed the steps to make sure to check them off I be in a way different place. So my last big lesson that I'm taking you to 2021 is that we are never too good for those Basics. We need to go through them every time just like how an elite athlete never stopped practicing technique and getting Braxton. We do want to stop

Details because we've been doing this for a long time. Maybe you were going to get faster at those steps. I hope I get back. I think it's disingenuous to lead a team but then consider yourself for some reason exempt from the same standards that you want them to have. That's it. Those are my Five Lessons that I'm bringing in 220 21 close commit to dates your team is your peer group when in doubt it's your job and never forgot to sweat the details. I'd love to hear what your lessons are or what intentions are setting for this year. Please send them my way. I would love to hear from you. Let me know that's Maggie address.com they seem

More Episodes

[Rebroadcast] Answering Your #1 Question: What's a One-Pager? (With Daphne Funston)

Giving Presentation Feedback as a Manager

How to Turn Advice into Action with Whoop's Ben Foster

Building Early Stage Products with Levels Co-Founder David Flinner

Prioritization with Productboard's Srinivas Krishnamurti

Product Manager vs. Chief of Staff with Drift's Terrance Rogers