Episode 90: Dear Melissa- Answering Questions About Program Managers, Switching Jobs, and Experimenting With Hardware
In this Dear Melissa segment, Melissa answers subscribers’ questions about relationships between program and product managers, the right questions to ask during the interview process so you end up in a company with strong product values, and how to experiment when iterating on complex hardware.
Have a product question for Melissa? Submit one here and Melissa may answer it in a future episode.
Subscribe via your favorite platform:
Q: What does a great partnership between a product manager and a technical program manager look like? If my long-term career goal is to pivot back into product, how might I build up my product chops in this role in the short term without stepping on the toes of my product partner in crime?
A: Program management takes a lot of communication and project management skills, which are important for product people as well. You definitely need those, but you’re primarily gonna be working more on the project management side than the product management side.
Q: Do you have any suggestions for questions I can ask when interviewing for a new role to make sure that I don't fall into the same situation in the future?
A: I [always] suggest people leave jobs that aren’t good for them, so congratulations on making a wise move. Here are things to look out for to ensure the next company will be different. A strong vision is a BIG factor.
Q: Do you have any advice for how to do product discovery when you are working with high-end systems and prototyping and iterating are really expensive?
A: When you're working on massively big products that are more hardware-focused, you have to remember that you're not using the same toolbox as you are when you're doing software product management. Here’s how reducing the risk early helps.
Resources
Melissa Perri on LinkedIn | Twitter
Transcript:
Melissa:
Hello and welcome to another episode of Dear Melissa. I hope your fall and your Q4 is going well. And today I've got three questions for you about program managers, switching jobs and what questions to ask and how do we experiment with hardware options, maybe not just software. And I wanna remind you that as always, you can write into me or leave me a voicemail@dearmelissa.com, and I'm happy to answer any of your questions. They can be about product management or anything I've done in my career. Super happy to dive in and answer any of those. So this week, let's kick it off. First question, this is the question by Tiffany Chang. Hi, Melissa. Starting a new role as a technical program manager here.
All right, so you are a technical program manager and they are incredibly important, and especially larger portfolios or complicated products. So program management takes a lot of communication and project management skills, uh, which are important for product people as well. So you definitely need those, but you are primarily gonna be working on more the project management side than the product management side, but that's okay. So typically what a program manager does is they work across product teams to help with things like road mapping, making sure that initiatives are going well. And this usually takes place when you've got really large initiatives that take, uh, product teams from different divisions or different business lines, and you need to make sure that they're all aligned and working towards the same goal. Um, so when I worked at a healthcare company, we had technical program managers who went between the different business lines.
Uh, these business lines were run by different VPs of product, and we had to make sure that things were integrating, um, that we were communicating and passing the data from one side to the other because when we did implement things on one side of the business, uh, it did flow through and affect the other side too. And that happens a lot in larger scale products and in larger scale companies and ones that have more complexity. So great place for a program manager to come in and help because, uh, it's hard to have one owner sometimes around this. In some initiatives it's pretty clear that most of the work is going to fall on one team, and you might see that proj, uh, product manager step up and become the owner of it and do a lot of the project management with the other teams. Uh, but sometimes it's kind of like an equal thing where many of the teams are working on it.
There's many moving parts, and that's really where you need somebody like a technical program manager to, to step in and help. So what you are doing here is you are making sure that teams are aligned and we're all working towards the same goals. So that means that when we are breaking down the strategy, breaking down the work, um, you're there to help facilitate it, make sure the teams are talking to each other, you're running the meetings to see how on track things are, make sure that they're bringing up any blockers or issues with each other. Uh, so you're kind of overseeing this whole thing, which is a really key role. Now, if you wanna start to kind of hone your product chops, I think what makes the difference between a good program manager and a great program manager is to add in some of those product chops, which means keeping your eye on the outcome.
If you can help suggest, um, ways in which you can structure things or do different parts of the roadmap, uh, reorder things, you know, scope things down, that's gonna help add another voice to the team where you can, uh, kind of align people and see the whole instead of just seeing the moving parts. And that sometimes happens on these big initiatives. A lot of the teams will be focused on what they need to get done, what their team needs to do, you know, what their business line is focused on. They might not see the whole. So if you really wanna hone your product chops, make sure you're looking at the whole, make sure that you're looking at the end to end experience, how it's gonna affect every part of the business, how it's going to produce those outcomes, and bring that into every meeting that you're talking about.
So if you're seeing any friction between the teams or things that aren't going well, like that's a good place to pull people back, say, Hey, okay, wait, let's take a couple steps back. This is what we're trying to achieve. Here's these outcomes. Um, let's try to focus on this. And you can ask smart questions about it. So don't just get into, you know, being the person who's like, Okay, what date are you delivering and what are you delivering? And getting into like super project management mode. Make sure that you're also helping people see the bigger picture of what they're trying to accomplish. Uh, that I think is a really good, important part of being a program manager. And they're very important when you get into these super complex initiatives that you wanna go after. And a lot of companies are working on them now. So great place to be in. And I wouldn't worry about, you know, losing your product chops. I think as long as you keep your eye on that, you can tell the story about how you manage those large initiatives, um, brought people together, that's gonna really look good when you try to transition back into product. I think telling that story is gonna be really important for your role. So good luck with that. All right, next question.
This one's from Marta. She says, Hi Melissa. I'm currently planning on leaving my job. Well, congrats on making the decision to leave. A lot of times that's the hardest part. So I really applaud you for being able to take a couple steps back, look at what the problems are and say, You know what? I gotta make a leap because that's scary. And I don't, you know, I, I suggest people leave jobs that are not great for them, but I know it's scary, so congratulations. I do think you're making the wise move. So let's make sure that the next company you go to doesn't have the same issues that you're experiencing now. So here's a bunch of things that I would do if I were in your position. One, ask about the vision and make sure it's not wishy washy and it's actually a vision. You don't wanna end up at a company that's like, be the best X and nobody can explain what that means.
That means that nobody has put any thought into the vision or the product strategy at all. So ask about the vision, make sure people can tell you what the vision is. Uh, make sure that you're talking to leadership and, uh, diving into those parts. So don't go to a place that's got a wishy washy tagline, vision that nobody can explain. Two, I'd interview with many levels of product people. So you wanna talk to people who are on teams. I'm not sure exactly what level product manager you are from your question, but, uh, let's, let's explore them all. You wanna talk to people on the product teams. You wanna ask them about their work. You wanna see that they're more strategic thinkers. You wanna, um, ask them about how they get strategy from the executives. Um, you wanna see if they can communicate why they're building the things that they're building.
You wanna meet with the middle layer and you wanna see what their day to day looks like. You wanna ask them about their biggest product challenges, uh, what strategies they're working on. You wanna see how they might discover new things that you go after, new initiatives that they're working for, and make sure that they're actually out there exploring new opportunities, doing the discovery work and helping to put that into practice. And then also you wanna make sure that you meet with the top product person as well, and that they can explain what their portfolio strategy is, their product strategy, ask them questions about it like, in the next three years, what do you hope to accomplish, um, with the product? How will it change from where it is now? Uh, ask them too like, what is your biggest product challenge from a strategy standpoint, right?
What are, what are you working on now? What's the next move? Where are you going for? And they should be able to answer those questions for you. Um, if they're saying things like, Oh, prioritization is our biggest challenge, and, um, you know, they go into process details and how people aren't working well together, anything like that, that's telling you that there's probably some dysfunction going on in the team, everybody's got a little dysfunction, that's okay. Like you, you don't have to worry if it's, if it's a sidebar about like, yeah, I guess we could work better together as designers and product managers, but if they won't talk about the strategy and all they do is complain about the process and the people and they talk about scrum type stuff and agile things, and like, that's the only part of the conversation, that's where I would start to get worried.
Um, good product people and good product teams are always talking about the value they're providing to their customers. The outcomes are tangible things that you can look at and say, Yep, that's an outcome. That's not just a velocity metric. Um, and they're talking about, you know, big hard problems to solve. That's what product lights up, product managers, right? Big hard problems to solve. So if they're talking about all those really cool problems and you're like, Yeah, that sounds like fun, that's, that's gonna give you a good sign that somebody's thinking about the opportunities and the strategy that you need to go after. So I would definitely look for that in those conversations. Also talk to the people who are not in product and get their perspective on what product management is like in the organization.
Sometimes people like to really amp up what the product team is like when they're interviewing people, right? They want, they're trying to sell. You remember that like when you go into an interview, people are trying to sell you. So they might make it sound really rosy. Uh, ask them about detractors, right? Like, does anybody not like the product team? Where's your biggest friction? And then ask to talk to people in those areas and see what their perspective is on the product team. Uh, they might slam the product team, and in which case you wanna dive in and see if it's actually a reasonable assessment. Or they might be like, Yeah, they're great, but we're just like working on some kinks.
Usually if the other departments are talking about product, well that means that product is doing a great job. But that's a great fast way to find out if product management is doing well in this company or not. Usually there's a lot of friction when there's no product strategy. And when product decisions aren't being made in a great way, uh, it's actually interesting. The better you get a product management as an organization, the better everybody works together. And the more people like product, the more sales is like, Hey, product is amazing. And at the beginning, you know, I think when people are moving from an organization that wasn't great at product to one that is good at product, there could be some friction. So you wanna assess what stage they're at in their maturity of product and start to talk about like, Hey, um, what have you done to develop the product team in the past year?
Uh, what kind of career opportunities are there here? What types of learning opportunities, do you do trainings? Do you do any of these things? That'll give you a good sense on, you know, if people are continuously learning and developing, which will tell you if it's a good organization to join. But if you find like people saying, Hey, yeah, we just went through like a big transformation, we have a new leader. Um, some of our product teams have not been product managers for a while. It might be, you know, a little, it, it, there might be some friction that you have to kind of delve into there, but it might not be awful. So just recognize that if there is a little bit of friction, try to figure out if these are things that you're gonna work past because the team's being better and when people have to change, everybody's not really happy with it.
Um, but you could see if you have a great leader, if you have somebody who really understands product management, those frictions usually are easy to overcome. So that's why I'm saying don't roll any of that out immediately, but really hone in, I think, and talk to the leader and figure out what kind of leader they are, look up their experience. I think that's gonna help you understand what this role is gonna look like going forward. I always say when you're in an organization working for a great leader, um, you will usually get the experience that you're looking for. So you wanna follow the people that you're gonna work for into a new organization. So spend a lot of time digging into that. All right, last question. This is from Herman and it's about robotics industry.
Well, thank you for this. I really love these types of questions. Um, when you're working on massively big products that are more hardware focused and not software focused, I think you have to remember that we're not talking about the same toolbox as we are when we're doing software product management. I believe all the theory stays the same of reducing your risk, understanding the customer's problems, designing things in a way that are gonna be solving those problems in unique, valuable ways. All of those things still apply, but the tools that you pull out of your toolbox, that's how I would like to describe it, are gonna be different. So no, you're probably not going to be rapidly prototyping as much as we were in software. You can't just pull up some code and be like, I'm gonna change this from green to blue. Like, that's not easy when you're working with hardware and that's okay.
So don't think you have to do exactly the same things as a software team. Um, we're not in the agile scrum world anymore. Usually, uh, you might be using some agile scrum techniques, but like you're not gonna be using everything that all the software people are. So that's okay. The one thing I think you need to remember when you're working on hardware products instead, or physical products at all, right, instead of software products, is to keep that theory in mind. So here's the whole thing that we need to do as product managers. No matter where we work, we need to reduce the risk early that this product will fail. So if you're working in robotics, think about it this way. Let's look at the whole picture. What are our assumptions about this product that are uncertain that we need to go out and explore? Maybe we go into our hardware toolbox and instead of doing rapid prototyping or using Figma to draw things up, we're doing customer interviews, we're observing people using similar products in real life.
We are, um, mocking things up in a 3D CAD thing to show to somebody. I don't know, uh, I'm not a hardware expert here, but I'm trying to give you some good ideas of how your toolbox might differ, but the questions are usually the same. And when you're working on a big product too, you might go more narrow on those risks or you should go more narrow on those risks. So maybe your big risk of the whole robot failing is, you know, mitigated. It's like, no, actually everybody loves this. We have good retention, blah, blah, blah, blah. Okay, so where's the problem when it comes to this for customers? Maybe there are specific aspects about the product that you're worried about. Maybe there's a new feature about the product that you're worried about. Those types of things are where you really wanna hone in, um, and start to figure out how do I experiment in ways that I can experiment around these little areas?
So don't think you need to use exactly the same thing that everybody else is using, right? Really study how people iterate on certain things in bigger products. Um, there was a story going around that, uh, how Apple kind of came up with the iPod when they were trying to figure out how big it could be or how it fits in people's pockets. Instead of building an iPod, they put like a little piece of metal that was the same weight as the iPod, right? In somebody's back pocket test out. Is this gonna be comfortable enough to carry around? Does it fit in pockets, right? Like you're not building the whole thing at that point, you're using this piece of metal to kind of answer the question of what size should it be? What's too heavy, what's too small, what's too big? What's the right fit for this?
So that's where you have to start to think outside the box and figure out how do we not just focus on like building miniature versions of this in prototypes or, um, you know, trying to rapidly iterate on it. It's more about really dissecting what are your critical questions and then coming up with unique and interesting ways to find out the answers to that before you commit to building the whole thing. So just keep that in mind. Um, it's never going to be exactly the same as software, and that's totally fine. Thank you so much for listening to this week's episode of Dear Melissa, and again, if you have any questions for me, leave me a voicemail at dearmelissa.com. Next Wednesday, we will be back with another episode of the Product Thinking Podcast. So if you do enjoy this content, please do me a favor and hit that subscribe button so that you never miss out on an episode. And I'll see you next week.