Episode 103: Answering About Tech Vs Business, Level of Detail for Engineers, and When to Join a Startup
In this Dear Melissa segment, Melissa answers subscribers’ questions about whether or not adding a business owner into a product team is the right call, how much detail product managers should provide to their engineering teams, and if there’s a right time to join a startup as a product manager.
Have a product question for Melissa? Submit one here and Melissa may answer it in a future episode.
Subscribe via your favorite platform:
Q: I've been asked to include a business owner from outside technology in the teams. I'm worried that this will slow decision making and reduce our time to market. How should I tackle this?
A: Unfortunately this happens a lot, especially in large traditional companies and ones that are going through transformations. They've got this old mentality of the tech team being separate and responsible for infrastructure, and the business side doing the “real work.” Here’s how I would handle this issue.
Q: What do you think is a realistic level of detail for a PM to provide their engineering team?
A: It’s all about balance. There needs to be a balance between how much information you need and what your cultural capacity is to meet the expectations of the information provided. Listen in to find out how to achieve that balance.
Q: Is there good timing for joining a startup?
A: This company clearly didn't know what they wanted out of a head of product. It sounded like they may have wanted a lackey, somebody to do the lower level stuff. There is a point in a startup where it is too early for a Head of Product. Tune in to learn why.
Resources
Melissa Perri on LinkedIn | Twitter
MelissaPerri.com | CPO Accelerator
Transcript:
Melissa:
Hello and welcome to another Dear Melissa and Happy New Year. Can we still say that, have you been in 8,000 meetings? Where we start with that? Somebody says, happy New Year. Oh, it's the middle of January. Can we still say that? Because I have, and I will be one more to add to your list, but happy New Year. I hope your new year is kicking off to a great start. Uh, mine sure is and I'm excited to dive into these questions that we have today. We've got lots of great questions rolling in from dear melissa.com and I wanna remind you that you can go there too and ask me your questions. This is how I've been, um, you know, connecting with you, answering your questions, making sure that a lot of you can hear the answer because a lot of you ask the same questions, which is great.
We're all going through the same problems as product managers or people in technology companies out there. So I wanna make sure that I can get you the information you need to succeed. So if you have a question for me, go to dear melissa.com and submit it. Can't wait to read them. But today we've got three questions, um, which I'm excited to dive into because they are common problems that I've seen. One is about a large traditional company where we are splitting out our tech product managers and bringing in people from the business side to also be product managers and having two different roles for them, which I'm not a fan of. So I will talk about why our next question is going to be about what level of detail product managers need to provide to their engineering team. And then we're gonna finish off with when is the right time to join a startup as a product manager and when is it to you?
When is a startup too early to actually join and be successful? So, good questions. Let's dive it. Dear Melissa, I'm a lead product manager in a large traditional company where product teams inside our tech department build software products. We're hearing that our work needs to be more business led rather than tech led. And I've been asked to include a business owner from outside technology in the teams. I'm worried that this will slow decision making and reduce our time to market. It also tells me that the tech PMs aren't trusted to make decisions for the company as a whole. It feels like a step towards seeing technology as core to our business, but it also feels like a step backward in empowering our teams. How should I tackle this? All right, I have a couple issues with the way that the management team is handling this, but I'm sad to say it's not something I haven't seen before.
This happens a lot, especially in companies that are going through transformations and in ones where maybe it sounds like you're a large traditional company too. So that means that you've got this old uh, mentality of like, hey, the IT tech team is over there and they do like infrastructure and then our business side is over there and they do all the real work <laugh>. So you're coming back from a legacy of that. And now while the business does see tech as an integral part of their business strategy, which is why they wanna bring the business people in, they don't know how to handle that. And they're also have all of these old, you know, preconceptions about who you are as tech PMs. So that's what we're fighting. So first thing to address, they're assuming you don't know about the business as a whole, right? They're looking at you as like, oh look at our little IT people over there.
They're just in databases. They don't understand what we do. So this is a good question to ask and look at in your company, have they shared the business strategy with you, right? They're like, oh, our tech PMs, they don't understand the business. Have they tried to communicate what that strategy is to you? A lot of the times they have not. So ask, have they shared the business strategy with you? Have they defined good goals? Have they communicated and deployed that strategy down in a way that you can manifest it into product? Has the middle layers of product management interpreted that strategy into a roadmap that you can follow on a team? If the answer is no, then they didn't even give you a fighting chance to understand the business and that is their problem. Maybe they don't know what deploying strategy looks like. And I have worked with tons of large traditional companies that have no idea what to do to connect a business strategy down into a product strategy.
A lot of times there isn't really a firm business strategy that is actionable either. So that may be a big gap. They might not know how to do that and because they don't know how to do that, they're not seeing the business results. So they're going, oh, the tech PMs don't know what they're doing, they're not doing business stuff. And that's where this is coming from. So really dig into that. Do we have a good strategy deployment process could be a problem. Maybe the upper echelons of your product team aren't communicating well enough with the business side to ask for these things or they don't know how to ask for these things or that they're even missing in the first place. And a lot of transformations we bring people in to run the product teams. Well sometimes we don't even have like, you know, upper layers of product management cuz it doesn't go all the way up to the C-suite.
But a lot of times we don't have really capable leaders in product management too. So ask yourself that, are our leaders in product management able to talk to the business in a way where they trust them, they understand it, they're connecting back what we're doing to product, to how it's reaching business goals. That could be a huge communication gap as well. And that's where I have seen teams in the past go, oh we need some business people in here because the tech people don't know what they're doing. So all of these things could be a problem and that's where I would start is saying like, is any, are any of these gaps coming from that the business not understanding what to do with us or how to translate these things? In that case it's their fault really for not bringing you what you need to succeed.
And I would start asking those questions about the business to show them that you are actually interested in it because, So that's step two. Now what I describe may not be the case, you may actually have a firm strategy. Um, there is, you know, good capable leaders in the middle of product management all the way up to the top. So if they're open with the strategy, they're giving you good goals. D deploying it in a way that you can actually pick it up. Have you gone to the business side to build bridges? Have the other product managers gone to the business side to build bridges? Are your product leaders going to the business side to understand what they do to deeply grok it and to help translate what technology's doing into the business side?
That might be where you're struggling. So if your product managers are not asking the business questions about how they work, how um, you know, they reach their goals, what the market's looking like, how things are shifting, if they're not deeply interested in what the business is doing and communicating back up to them that they understand the business and they're translating all those goals into product goals, that's probably on the tech side of PMs not really talking to them in ways of, you know, communicating how your business is running to a point where they don't trust you. And that is a trust thing. Like you said. They aren't trusted to make decisions for the company as a whole because they may not be communicating back to the company that they understand it well enough to make those decisions. And that's one of those communication issues. So you might need to take the tech PMs, um, and anybody that you can and teach them how to have communications with leadership in the business side about these things.
Saying, okay, on the side of our, you know, on our tech side we have these different initiatives that we're accomplishing. Once we do that this will enable X, Y, and Z at the business level, which will enable us to meet your, meet our strategies and our vision. You have to tell that story. If your product managers are not good at telling that story, they might have a good knowledge about the business but they're just really bad at communicating and that's why the team goes, oh, we should put business people over here. So it could come from two sides, right? It might be a mixture of all these things honestly because I have seen a mixture of all these things prevent all of this from happening. Um, but really what is coming down to is a lack of communication either from the leadership down to the tech team about what the business is doing and why.
Um, and then back up from the tech team to the business saying, we understand what the business is doing and this is how we help the business run. So no, I don't think you should put a business person into your teams. That sounds, that's wrong. This is a, that's like a legacy old thing that we used to do before, you know, back in the nineties that's how we used to do it. But that's not how we work anymore. The thing is that we need to make sure that we're communicating as product managers to help build trust into the business by showing them that we know what we're talking about when it comes to the business. And the more you have those conversations, the more they're gonna trust you. So that's really what I would look at. Are we deploying strategy down wells business communicating to us in ways that we need and if not ask for those things. Two, are we communicating back up to the business that we understand what they're doing and we have good insight into how we're gonna meet the needs of the business through what we're doing. So work on the two-way communication and I think that's what's gonna solve your problem.
All right, second question. Dear Melissa, my company has grown a lot over the past four years. What used to be a small group of product owners has evolved into a large group of product managers. Senior leadership are keen for PMs to know the business, their users and experiment for maximum roi. While this is great, I see some hangovers from the product ownership days, some engineering teams expect detailed user stories and acceptance criteria from PMs before they'll pick up work which strains PMs who don't have enough capacity to do proper product discovery and meet the team expectations. What do you think is a realistic level of detail for a PM to provide their team? Ooh, I love this question because at the end of the day there's a balance. There is a big balance here about how much information we need, um, and what our cultural capacity is to meet the expectations of how much information there is.
So let's start here. Let's start with the ideal. What does this look like when we're all working well together? And I like to write about ideals and a lot of people get mad and go, oh well like we we're not like that because our situation is messy. It's like I know you, your situation is messy and you're not here right now, but I'm gonna paint you a picture of what it should be and then we're gonna work on how do we get there, right? Same thing we do in strategy. What's the vision of where we want our company to be? We're not there yet. We're gonna work our way into it. So let me tell you about the ideal you should be kicking off with your development team to build context. So what does that mean? As a product manager, you're presenting the problem, you're involving them in discovery about that problem and not a lot.
Not like, hey we're dragging every developer into every user research thing we've ever done. Uhuh not their job, they're coming to a few interviews a year, right? Not, not a ton, but what you are doing is taking all the things you learn through discovery and distilling it back into good information for them to keep them abreast of what's happening. You are basically digesting all that information. You or the user researchers or whoever's doing this discovery, right? Digesting that information, repeating it back to them to keep them involved so that they can build context.
Once you have accomplished discovery, maybe done a little bit of experimenting to figure out, you know, what it is you should be building now you build the vision and you involve people in that vision. You involve the developers and you involve UX designers and you involve your user researchers, everybody. And you need to end in some kind of document thing that builds context. You outline where you're going, you've got some good mockups of the vision to make it tangible, um, from your UX designers and you present that back to the developers and you talk about how the users should be using it. What's good, what are you not doing? What are you doing? What they should be able to accomplish and what the goals are. Once you build that context, the developers can now start to fill the gaps when you break down the stories.
So now we're breaking down stories at a higher level. They're accompanied by wire frames that specify more information in there. So our user stories don't have to be like, push a button here, right? If we have a great clickable prototype, um, wire frame out there, the developers could see where the buttons are, they can see if you click on that button, it should take you here, right? Those types of context things come in through UX design, they come in through conversations. But you shouldn't have to spec out every single little detail into 18 different pages because you've built the context. They should be able to fill in some of those gaps. You are gonna have to do some higher level lightweight acceptance criteria. What's good, what's bad. But a lot of this should be back and forth, right? The developers should be going and you know, building things, showing it to you.
You should be working through it together. But if you build that context, they're gonna be very close to um, what you want in the end because they know where it's going, they know what you're doing. So they should be able to get really, really far on their own with some lightweight specs and lightweight user stories, um, to actually fill in those gaps cuz we worked on that. If you don't build that context before, that's where they're gonna come and ask you for all the different little details. Um, I've had a lot of teams tell me exactly what you're saying. My developers bother me like 24 7 asking me questions. So I can't actually go out and do discovery. And it's because they didn't build the context. They didn't tell them what should be expected, how people should move through the products. Um, you know what the end goals were.
And when you built that context, when we actually did these kickoffs, we built these docs. And I'm not talking about like 80 page docs, I'm talking about like a nice little presentation about you know, how this should work and what the goal is and use a lot of visuals and that type of stuff, right? That's how we build context. When we do that, a lot of the questions go down because we're empowering the engineers to be able to fill in the the information. Now there is also a cultural barrier. A lot of engineers have been burned before because uh, they didn't build exactly what was in the PM's mind that was not specked down in highly great detail and they got in trouble for it, right? So what did they do? They asked for heavily detailed specs. That's a trust issue for the engineers. It's not that they don't want to think for themselves, it's that they have never been rewarded for doing so.
The company saw them as code jockeys. So what did they become? Code jockeys, right? Gimme what you want me to build and I'll build it. They didn't reward them for thinking, nobody rewarded them for thinking. And if they did think or do something slightly different, they probably got punished for it. So think about that. How do you shift your reward system for the development team as a whole and for product managers as a whole for everybody, right? Which is how do we get to outcomes? How do we all focus on the outcomes of where we wanna go? I had a great relationship with my developers where we could do these high level specs and they might see something and be like, Hey, this was really confusing. So I decided to change it and I'd be like, great, fantastic. I I'm so happy you took that initiative.
That works so much better. And now I don't have to like get involved every little detail on here. I can go and do the higher level work that I need to do. That's where you should get to. So reward your developers for thinking outside the box. Reward them for bringing up issues with product or ux. Don't be like this is territorial, this is my area. And then you'll start to see them get a little more comfortable With ambiguity. We really need to shift how we're all focusing on the outcomes and not just building exactly what somebody saw. So that's kind of the difference between a product owner mindset and a product manager mindset is we are not just about specking every little detail into stories. We're about bringing the team along with this journey and encouraging people to fill in the gaps where needed. And I'm not saying go in there and just drop like three stories and tell your developer to figure it out on a big product. No, you do need to get to a level of breaking down what we're going to build. But the more you have good wire frames, the more you have good context, the more the developers can fill in the gaps for themselves.
All right, last question. Dear Melissa, in my whole career as a product manager, I've always worked with new products button well established companies. Recently I was learned to leave a job where I really liked to work in a very young startup as I head of product. So I learned about the company vision, I worked on the new product strategy, I researched customers and competitors, I suggested a pricing plan and then I prepared the full backlog for the MVP with the hypothesis we had in mind to start testing the product with some beta customers in an early adopter plan, just before starting to put this in place, I learned that I was being let go because they realized they made a mistake in hiring a product manager in such an early stage and they couldn't justify my salary at this time. Is there a good timing for joining a startup? Were they right in saying that the company was too young to have a product manager?
Well first off, I think you had a bad break. I don't think you did anything wrong, but this company clearly didn't know what they wanted out of a head of product and probably were expecting you to do more of like the dirty work in the nitty gritty specking for developers. Um, and the CEO saw themselves instead being the one who did all the things that you just did. This happens a lot. They didn't want really a head of product. It sounded like they may have wanted a lacky, somebody to do like the lower level stuff. And there is a point in a startup where it is too early for a head of product because when you start off really, really early, the founder is usually the head of product. Now this person has got the vision, they know what they wanna build, they can see the roadmaps, all of those things.
And what they're really looking for at this stage, once they realize that's too much for them is somebody to like get into the nitty gritty and sit with the developers, break down the stories, do the wire frames, like output type work because they're the person doing the strategy. So what you need to look for when you're looking at when is the right time to join a startup is when it, and especially as a head of product, let me start there. So there's a difference between joining as a PM and then joining as a head of product. If you're joining as a product manager at an early stage startup, you have to recognize that you're probably gonna be doing a lot of lower level work that is output driven to get things out the door, especially after post-product market fit. Pre-product market fit is characterized by high experimentation.
Usually teams, uh, startups at this stage they're not hiring product managers because the CEO or the founder is the person doing that work with the developers. And that's okay, let them do that. Let them highly experiment until they fi get to post-product market fit. When you get to some traction post product market fit, you've nailed what you wanted to in a, in a sense where you got some customers, right? And you're now thinking about how do I add, how do I grow this and how do I scale to meet needs? Cuz we have a ton of feedback from our customers that this is good and we wanna keep going. That's when they're gonna hire their first product manager. Why? Because the CEO needs to raise themselves up and start looking for more customers, bring in more, you know, work with the customers a little more closely, um, start thinking about fundraising, all of these things that a CEO should be doing.
That means that a product manager is gonna be the one who's internal to the company working with the teams to break down that feedback from the customers and figure out what to build next with a lot of guidance from the ceo. So you look at your CEO as the head of product at this point and I keep saying CEO might be the CTO but like the founder person, right? Like the founder person who is the the product person and there's always one of them. So in this instance too, it's too early for a head of product because the founder usually likes doing this work and they don't usually have a ton of product managers to manage. So this person is still getting the the feedback still going through that. Now maybe they hire another product manager, maybe they get another product manager, they're gonna start to scale when the team starts to scale and they realize we have way more feedback, way more customer comments, way more things we wanna build than we could possibly keep up with, that's when they're gonna start hiring.
So they're gonna first start with hiring a bunch of engineers cuz that's what everybody does even though they won't have anybody to break down the work <laugh> to give to the engineers, which is what the product managers are. So then they go back and hire product managers and then one day the CEO wakes up and goes, oh my god, who's gonna manage all these people? And that's where the head of product comes in. So you need to join when you're thinking about being a head of product, a place where there's at least a couple different product managers working. The CEO has come to the realization that they wanna be a CEO and not a head of product, but they're gonna be the visionary. And this is a big part too. You wanna make sure that this person is ready to give up the reins for you to be a head of product, to have good product strategy decisions with them.
And then you have to learn how to work with the founder. So visionary founders who enjoyed the product process, they don't wanna be completely cut out of this. And I think that's the wrong mentality to think of when you're joining a startup as a head of product where a founder has done this before, it's like they want to have a partner there to help synthesize what they're seeing into direction for the team. So you need to look at this as a partnership, not just I'm just doing the product strategy and this person shouldn't be involved. Think of it as providing the structure for the founder that they never had because they probably weren't a product person before, to help them manifest what they wanna do with the company vision. And once you build the trust with the founder, you push back in places where you don't agree with but in you know, respectful ways.
At the end of the day though, you have to remember like this is their baby and what they say goes. So if you have somebody where you fundamentally disagree with the vision of the company from the start, do not join that company. If you really believe in the vision of the company the founder has laid out and you look at it and you say, I can manifest this through product, we're kind of on the same page, maybe it's just like a little bit of tweaking here and there, that's gonna be a successful partnership. But if you fundamentally disagree with where the company's going, don't join it thinking you're going to change it, you won't. This is the founder's company, they probably own more equity than anybody so they can choose what it does. So that's just setting you up for a bad time. Now was this company right in saying that the company was too young to have a pm?
It might have been, it depends on who was at that company if you did all of this work and they just said we made a mistake in hiring a PM in such an early stage. I think they made a mistake in hiring a head of product. So early stage and it is a lot of money to pay a head of product in an early stage company, especially when you don't have a lot of people underneath you to lead and to execute and to um, you know, take all the things that you're actually doing and put into practice. And that is maybe what happened to you. You did a ton of really good high level strategy work. Was there anybody else in the company who could execute on that besides you? That might be what the company was looking at. Like this is fantastic work but we need people to actually do the work.
And heads of product typically are not in the weeds doing the work and it may have been too early for a head of product in that case they may have had a bunch of, you know, other stuff that they needed to execute on and that's what they were looking for. So they hired at the wrong level. Did you do anything wrong? I don't think so. They just hired the wrong level for this company. So that's what I would really look at when you're trying to join another startup. The time for a head of product, especially if you wanna join that, you have to have people who are gonna execute. Do they have a full team that can execute? And what they're lacking is somebody to bring it in and build that roadmap, build that strategy around what to execute. That's the perfect time for ahead of product.
But anytime before that, if you don't have a lot of people to take what you are, you know, strategizing and run with it, that's too early. So that's what I would really look at when you're trying to join a startup. Startups can be really, really fun, but they're also extremely challenging. So that's it for dear Melissa this week. Hopefully those answers help your questions. And again, I wanna remind you, if you have a question for me, please go to dear melissa.com and let me know. We'll be back next week with another guest and I hope you have a great week in the meantime and we'll see you next Wednesday.