Melissa Appel: The Founders’ Guide to What Product Teams Need

• Slides
• Transcript
• About the Speaker
• Join the BoS community

Indigestion, not starvation, is the most common cause of startup failure. There are so many good ideas that product teams can get into a vicious cycle where they can’t plan ahead because they’re always scrambling to execute on today’s stuff… because they didn’t plan ahead because they were scrambling to execute on yesterday’s stuff… and on and on. The CEO can help, but not in the way you might think. 

Rather than rolling up your sleeves and brute forcing solutions, take a step back and collaborate with your CPO to improve the foundation on which the product team is operating. In software, having a solid platform can make feature delivery faster. For product teams, having a solid foundation will enable the product team to deliver value better and faster than scrambling (and with less attrition).

There are five key things that CEOs can do to build the foundation that sets the product team up for efficient and successful value delivery: enable your team, align on goals, define your customer, measure success, and determine criteria for change. Melissa shares tools and approaches that keep you and your team focused and aligned on the success of your business. You will learn how to be the leader your product team needs to flourish and deliver results that make your investors happy.

Slides

Find out more about BoS

Get details about our next conference, subscribe to our newsletter, and watch more of the great BoS Talks you hear so much about.

Transcript

Melissa Appel 

Hello, I am Melissa, and I’m going to be talking to you about how Founders/CEOs can have successful product teams. So there’s an Aesop’s fable about two goats, and they show up on a bridge and they butt heads and neither of them will let the other one pass, and they like fall into the ravine. So sometimes CEO or a founder and a CPO or a Head of Product can sort of feel like those two goats butting heads.

The CEO–CPO Conflict Example

I worked with a client. The CEO brought me in and said, I think my CPO is no good. He keeps launching products that no one buys, should I fire him? So I talked to the CPO, and he’s like, my CEO comes into the last minute insisting on new ideas so we don’t have time to validate them. Well, that also sounds right, so maybe they’re both at fault. So I go back to the CEO, he says, My CPO shows me the roadmap the day before engineering starts, so we never have time for discussion. And then I go back to the CEO, and he’s like, I try to get time with the CEO to talk about future work, but all he wants to talk about is current work. So clearly there are some problems here, and clearly it’s kind of more than one person’s fault.

Founder Expectations vs Reality

So when you are a founder, when you hire your first Head of Product, you might think it’s going to be like this – Everybody’s fine. We’re working together. Everything’s cool, but it might be more like that. You might butt heads. There might be too many cooks in the kitchen. Maybe this is more accurate. There are a lot of things that a Founder can hand off more easily than product – finances, even engineering. There’s a lot of disciplines where they’re like, Okay, somebody else can do this. But if you’re talking about the strategy, the product, the vision, that’s your baby, that’s hard to hand off.

When You Need a Product Manager

So a brief detour, when might you need a product manager? There’s a difference between a Product Manager and a Project Manager. Ryan talked about this a little bit in the talk this morning. If you want engineering to move faster, you probably don’t need a product manager. They don’t live in that sort of build space project manager. They want a successful completion of the project.

A Product Manager is looking a little bit more at impact and value and context. A Project Manager manages execution, ‘Let’s get this thing done’. A Product Manager defines vision and strategy, maybe not corporate vision and strategy, but vision strategy defines the product defines the problem for the product. Project Manager is often thinking about short term focus. What are we doing right now? How can we get it done? Whereas, a Product Manager might do a little bit more balancing short and long term. I don’t want to take those shortcuts, because this is going to affect us down the line. Project Manager really wants to stick to the plan, ‘This is what we want to do. Let’s figure out how to get it done’. A Product Manager might say, I think maybe we need a different plan.

Missing Components: Communication, Trust, Process

So let’s assume you want a product manager, back to our story. So there were a few things missing. The CEO and the CPO arguing back and forth. One thing that was missing was communication. They just weren’t talking to each other. I had to mediate this conversation between them. Another thing that was missing was trust. They were blaming each other. Nobody was sort of taking responsibility, and they didn’t trust each other enough to have those conversations. And then last process. Process is not a four letter word, it’s simply something you can repeat that drives success. There was no process because if the CPO was constantly showing the CEO the roadmap the day before engineering started, that wasn’t working for anybody, but they weren’t having the conversation about, how can we change this?

FOCUS Framework Introduction

So I’m going to talk about FOCUS. Of course, this is going to be an acronym. And we’re going to talk about what it means.

• F is for foundational enablement, because I couldn’t find a word that meant team that started with F.
• Objectives – we want to talk about goals, how to set the team up for success.
• Customers – what do they actually want?
• Understanding what works that’s essentially measuring stuff.
• Switching, if needed. And we’re going to talk a little bit more about that.

F – Foundational Enablement

So, foundational enablement. This is your team. Hold the team to high standards. Wait a minute, what? Why are we not holding the team to high standards? This doesn’t make sense. Of course, you want successful teams, but if you hold the team to high standards in certain ways, it doesn’t work out well. So strictly enforcing performance, I’ve seen this many times, it doesn’t work out very well.

So there’s a client that that I worked with, and they said, we have a delivery problem. Our teams can’t deliver. They say they’re going to deliver, and then they just don’t. We keep missing these deadlines. So talk to the team and they say, Well, I mean, we said how much time it was going to take, but then the CEO said, I don’t like that estimate, give me a shorter one. So we gave him a shorter one, but we knew we weren’t going to hit it. So if you say, Well, you know it needs to move faster, I’m going to tell you it needs to move faster, but I’m not going to tell you the truth. And eventually they became kind of afraid to say how long it would really take because they said, No, that’s not good enough. But so of course, they missed the deadlines.

There was another company that I worked with where the CEO would publicly reprimand people for making mistakes. And so if you’re blamed for making mistakes, you’re blamed for the decision that got you to the project that failed. So people are afraid to make decisions. And if nobody’s making any decisions, things just stop. So that’s the problem, that people wouldn’t make decisions, and things would go on forever. And the junior people, they don’t want to make the decisions, they don’t want to get blamed, so they’re waiting for the executives to make the decisions. The executives are asking for more and more and more information, and things just sort of grind to a halt.

And then, if you hold teams to 100% of goals, that could be a problem too. Because not only do they end up measuring like number of features shipped, but they end up aiming low. If they’re gonna keep me to 100% of what I promise, I’m gonna sort of probably promise a little less than maybe I could deliver. And then if I have extra time, like bonus, I get a vacation. So you don’t necessarily want to enforce 100% goal completion, then you don’t get stretch goals and you get teams that are sort of aiming low.

Psychological Safety

So what do we do instead? Anybody want to throw out a definition for psychological safety? A lot of people say, Well, psychological safety isn’t that thing where you get in the room and everybody talks about their emotions and like that’s just silly. Psychological safety is basically removing the fear of repercussions for stating an opinion, sharing how you feel, or making a mistake. This is what we’re talking about before you want people to tell you the truth. You want them to be able to make decisions without fear. You want them to be able to have reach goals and aim high. So how do you do that?

One way is just how you talk to people. Somebody makes a mistake. There’s a difference between, why did you do that? And talk me through that decision. You know what I mean? And it’s not like passive-aggressive, it’s there are ways of asking questions that make people defensive, and there are ways of asking questions that actually get you the answer.

Retrospective, engineering teams do this all the time, and I usually don’t read slides, but this is, like, super important. This is like a mindset from Norman Kirk, from his book on Retrospectives, ‘Regardless of what we discover, we understand and truly believe that everyone did the best job they could given what they knew at the time, their skills and abilities, the resources available and the situation at hand’. And this mindset will help you set up your team for success, because they won’t be afraid of telling you what they really think. They won’t be afraid of making mistake. And this is how you drive innovation, and scientific experiments and things like that, and that’s how you get ahead.

O – Objectives

So the O is for objectives. Be ambitious! This woman is very ambitious. She’s climbing a mountain in heels and a mini skirt. That is ambitious. We can’t be ambitious either? What is going on here? There’s a point to which ambition goes too far, trying to do too much. There was a company that I’m working with that has 200 people, and they have a set of must win battles. Any guess at how many must win battles this company of 200 people has? 57! I cannot make this up. I’ve seen the spreadsheet, 57 must win battles.

One of so the must win battles are like delivering features and solving problems. One of the must win battles was, don’t display The Five Dysfunctions of a Team. I mean, that’s at least four extras, right? That’s like five in one. So I don’t know. But when you have that many objectives, you have divided attention. The whole team, they’re like, I can pick any of these to work on. People work on different things, or you do a little bit of this and a little bit of that, and sort of nothing really gets done because you’re dibble dabbling here and there. And it also means that there are misaligned priorities among the executives. Because if you if you can’t decide on a like, 57 is ridiculous. It means that people aren’t on the same page. People aren’t agreeing as to what the outcomes are that you’re desiring, or even potentially what the vision is, and you need that context in order for the teams to be successful.

So we may actually need to get everybody in a room and talk about what we all think are the most important things to work on, you may need to choose 1/2/3 key objectives for the company instead of 57 and you may have to make some tough decisions. So these are conversations that are difficult to have, but that are absolutely critical in order to set up the team for success.

Mining for Conflict

One thing that I like with workshops and getting stakeholder alignment, executive alignment, is mining for conflict. It’s better to find out now, rather than later, that people disagree. These are some tools that you can use in a meeting. So for example, the challenge round is, okay, we’re gonna go around and everybody’s going to say one reason why this thing won’t work, or everybody’s going to say one reason why this should not be the top priority. And that’s helpful, because you get people saying like you give them permission to disagree, and a lot of times, these conversations have to be had one on one, because people don’t always want to say what they’re thinking in public, especially if you have a psychological safety problem, that a lot of times you have to have these conversations one on one. You say, I noticed you were hesitant in that meeting, like, what’s going on, tell me what you’re thinking.

C – Customers

C, customers. The customer is always right. I think you know where this is going. At this point, we want to support our customers, but they don’t necessarily know what they want. So we shouldn’t build exactly what customers are asking for it like in the previous presentation, right? They don’t necessarily know what they want. They don’t necessarily know how to ask for it. They can talk about their problems, but only if you kind of solicit it out of them. Customers aren’t designers, even if they tell you exactly I want this feature, I wanted to have these things. You build it, you launch it, they’re not going to use it, because it doesn’t necessarily solve their problem in the right. Maybe they’ll use it, but a lot of times they don’t because they’re like, well, that’s not exactly what I had in mind. Or this is great, it’s exactly what I asked for. It doesn’t work, can you make it work?

And then I worked with a company that had sales. This is common situation. Sales says we need to sell this customer. They want this thing. Great, we’re going to build it, but then you end up building something custom for every customer. When you have a few customers, you’re just getting started. That makes sense, like you need to go and take off, but it doesn’t scale. You don’t want to be building new stuff for every customer. What you want to be doing is figuring out, okay, Customer A wants this, Customer B wants this, Customer C wants this. They might actually be solving the same problem, even though they’re not the same solution. And if you can figure that out, then you can build one thing for three customers, but you have to ask those questions. And the problem with building custom for every new client is you can sell things fast. Oh, I only buy it if we have this. Yeah, we’re going to have that. Don’t worry. But then you actually have to build it. So it takes them a while to be able to use the product, and then they get frustrated.

So, finding scalable problems, asking ‘why?’ Back to the kind of judgmental, non judgmental questions you probably don’t want to be ‘Why? Why do you want that?’ You ask the kind of follow up questions, what are you doing now? What’s not working? Does anyone know what Nihito stands for? Well, it’s actually nothing important happens in the office. You need to get out of the office. You need to talk to your customers, even just talking to them on the phone, sometimes, is not super effective. You go into their office, you watch them do their do their work, and you realize, like somebody’s coming by their desk. They’re getting a phone call. They’re checking slack. You’re like, oh, actually, their problem is they’re distracted all the time. They can’t tell you that over the phone, right? So a lot of times you just need to get out there and meet with people.

Using Customer Insights for Objectives

So we have these objectives that we came up with by getting in a room and making some hard decisions, and we have a few of them. Instead of just building whatever your customers are asking for, you should use that information to create objectives and build to the objectives. And that’s going to cover more people, right? You have organizational objectives. You have product objectives, come up with some metrics, like, you should base this on the goals of the company, not just, oh well, this customer wants this. Is it actually aligned with our objectives? Should we change our objectives? Maybe, but if we’re keeping our objectives, let’s take this with a grain of salt.

Metrics, Guardrails, and Measuring Value

Good arts law. When a measure becomes a target, it ceases to be a good measure, right? So, if you measure on number of nails, made, you get 1000s of tiny nails. If you measure on the weight of nails, you get a few giant, heavy nails. So even the metrics that you come up with, should you should make sure to have guard rail metrics so you don’t go to one extreme or another. For example, say the company metric is customer churn. You want to reduce churn. The product metric is number of sessions per user per month, because you’ve seen that customers who use the product more often are more likely to renew. But one way of solving this is to just make them log into the product all the time, even though their work is happening outside. Or you can even just kick them out all the time and have like, a bunch of new sessions. So maybe you want a guard rail metric of length of sessions, right? Maybe it’s kind of product where you want them in there. You want them engaged. You want them using it all day long. And so you would want a longer session. Or maybe it’s the kind of product where you want them just in out, get what they need, and then you might want a shorter session. So thinking around, how do I think about the customer experience and what the customer is trying to do, the problems they’re trying to solve, as it relates to my metrics?

Another example, this is a supply chain example, e-commerce supply chain. So maybe you want to increase customer lifetime value. That’s how much customers will spend with you over time. And maybe you’ve determined that people will buy more if their products show up on time than they will if they show up late. So you want to improve the on time rate, but you might need a guardrail metric, because maybe your way of getting things out the door on time is just like, jam them in the truck or whatever, but you want to reduce damage to like, and just stuff in the in the truck, because it’s gonna get broken. I can throw a light bulb across the room. It’ll get there really fast. It’s gonna be broken.

U – Understand What Works

U, understand what works. So always be shipping. Yes and no. We do want to keep putting things out there, but we don’t want to just ship stuff. We want to make sure we’re delivering value. So if we just launch stuff without measuring value, then we’re who knows, right? I don’t know if people are going to use it. I don’t know whether or not it was successful. I’m not sure when I was done. So just, you know, that’s okay. Just put it out there. It’s good to test some things, but you want to at least have an idea of what you might get. If you just throw things out there, you don’t know what people are going to buy, right? It’s helpful to at least have a hypothesis of what people might buy before you get out there, and that does require some amount of research, some amount of validation

I was working so that back to kind of the original story. You know, the CPO keeps putting stuff out there, and people aren’t buying it. You know, they didn’t have enough time to do the validation. It’s not that we need tons and tons of research all the time, but it’s worth proof of concepts. You know, testing hypotheses. You can’t necessarily recognize success. How do we know when we’re done if we don’t measure anything, right? You can’t improve what you can’t measure. And that just means that if you’re not measuring things, it’s just one big question mark, right? So you can be shipping lots of things, but are you actually delivering lots of value if you’re not measuring it? Who knows.

Outputs vs Outcomes

Outputs versus outcomes. Don’t just deliver stuff the amount of times you say, boo, is the output. But what we really want is striking fear in the hearts of the living. That’s the outcome of all our booing efforts. So I recommend measuring throughout – before, during, after. So at the beginning, you can estimate value. This helps with prioritization, right? If you are estimating the value that something will bring, then you can say, Okay, this is going to bring a lot of value. This is not going to bring a lot of value in combination with other criteria. Notice that I’m talking not about estimating the value of delivering a feature. I’m talking about estimating the value of solving a problem, because that’s a lot easier to do. And if you don’t know whether or not your feature is going to solve a problem, we need to take a step back on that one too.

Instrument dashboards. If you’re trying to improve a metric, you should probably figure out what that metric is now, so that you know whether or not you improved it. A lot of people get to the end of a project, they’re like, great, we improved the metric you’re like by how much they’re like, Oh, well, we know what it is now. Like, you probably should have figured out what it was at the beginning, so you know whether or not you did anything.

I worked with a company where a big problem they were trying to solve is that they always put measure the outcomes on their list of like to do items on each feature. They never got to it. They’re like, Oh, well, you know, whatever it’s out there. Let’s just move on to the next one. But if you don’t actually measure the result. How do you know if it was any? How do you even know what to do next if you don’t know what what this thing did? And then making metrics visible. If you have these dashboards, make them accessible. You want to share the metrics with the entire team. Create a culture at the company of measuring success, because if you know the impact you’re delivering, it increases team morale, right? People are like, Yay, we’re getting stuff done, as opposed to just like we launched 17 features, yay. It’s like, okay, but like, why is our company failing?

S – Switch If Needed

Switch, if needed. Adapt to new information, not every day. Constantly changing your mind on what we’re going after. It may feel like you’re adapting to the market and changing and moving. But if it’s too frequent, it can cause a lot of problems.

I was working at a company where the CEO kept changing his mind every other day, and so we were working on stuff. They’re like, nope, do this other thing. Working on the other thing, nope, do this other thing. So you have, like, a bunch of half finished projects. That’s a huge waste of time. You get kind of whiplash, right? People are like, am I working on this? Am I working on this? I don’t know. I’m going to take a break while somebody else figures it out. And then you’ve got low morale. Like, why should I bother working on this thing and getting invested if it’s just going to change next week. I’m just going to sit here until things sort of sort themselves out, and you don’t want any of that.

Prioritization, Dependencies, and Tradeoffs

So you can’t do everything. How do you choose? There’s another acronym in here, but we’ll go one at a time. You have limited resources, right? So you have to figure out time is money. What are we working on? We don’t want to work on stuff and throw it away and work on other stuff and throw it away. We want to figure out from the beginning and go through this process to determine what it is that we should work on, estimate the value, figure out what people might want to buy. If you add stuff, you might need to remove stuff, because you have limited resources, right? Unless you go and add people every time you add something. So when you take a new information, you’re like, Ah, now I think we should do this thing. You have to take something away. So think. About whether or not this new thing is of higher priority than what we’re already doing, and coming up with an estimated value for things helps immensely in that process.

Prioritize the highest impact. Again, if you know what the impact might be, then it’s easier to prioritize. We want to make sure that these things are technically feasible, right? Customer, I’d say, oh, it’s easy. You just like, add this button. People like, ah, yeah, but the back end on that button is has all these dependencies, and is actually the opposite of what we were working on before. And so it’s actually a big project. You want to do things in a logical order, right? Customer might want something, or you might think of a new idea, or some you went to a conference and got an idea, and you’re like, I need to do something different, but just making sure that it actually fits in with the with the scheme of what you’re working on.

And then some things can’t wait, right? A new regulation, a new customer, a new competitors come in. They’re eating your lunch. You need to pivot, fine, like, sometimes that needs to happen, but sometimes it can wait. If you’re thinking about, Okay, I have this new idea, should I switch? Should I pivot? Think about the cost of delay, right? What would happen if I don’t do this for like, six months? Let the team finish what they’re working on. Is it really the end of the world? Or, you know, maybe it is opportunity cost. What am I working on now? And if I stop doing that, to do this other thing, what do I lose?

Risks and mitigations, on both sides, maybe I do need to do this thing, because otherwise I’m I have this risk, there’s this new law or whatever, or maybe it’s hey, if I just drop this thing on the floor right now, all sorts of bad things could happen.

Dependencies. You can have a domino effect. If you say, Okay, this is the important thing now, don’t do this other thing, but that other thing was the baseline for all this stuff. And now you’ve sort of lost a whole tranche of things. So this was in summary, FOCUS.

Resolution of the CEO-CPO Story

Back to our story. The CEO and the CPO, who are butting heads. This story had an interesting ending. The CPO was going to quit because he got so frustrated with the CEO, and then the board fired the CEO. And so new CEO came on, but the CPO had already given his notice. But the CPO needed some help with the communication stuff. So the new CEO was working with the CPO, he’s like, You should stay. And because they had a better communication, they had better trust, they had better process that the CPO ended up staying on, and they were really successful together. Sometimes it’s just people can’t get along. Sometimes it is one person’s fault over the other. Hopefully we don’t need to change out any CEOs. But essentially, with working in this new process and with better communication, they were successful.

Shameless self promotion. This is my book. I co-wrote it with Bruce McCarthy, who is also a frequent BoS attendee.

Q&A

Audience Member 

That was a great talk, Melissa. So, a question on psychological safety. So how do you get the balance so you don’t paradoxically create a no criticism organization where we run with every idea, even if we think it’s completely useless, just because we’re actually now afraid to criticize that. What’s the balance there?

Melissa Appel 

I think the balance is process. So if you have a good process to say, here’s what our objectives are, here’s what the mission is for this initiative, and then you can go through and compare all of our ideas to that, then you at least have an agreed upon way to make those decisions. So you don’t just, like, let people run with whatever they want. There’s still some oversight, right? Like, I don’t know about that idea. Maybe we should think about these possible repercussions. So it’s not just letting everybody do whatever they want, but it’s, Hey, I think is going to be really, really good idea because of this, this and this. Here’s how it fits into our objectives. Here’s how it matches with the other things we’re doing. Great. Go try it. And having the freedom to even suggest that idea is what psychological safety enables.

Mark Littlewood 

It’s great question. And as this is the first time we’ve done questions in a session, welcome to questions BoS style. If you have question, wave, put your hand up. Who has a question? Wow. Okay, we’ll come back to that. And then we have two mic runners. So we have Jonathan there. It’s his first day,  bear with him. What I try to do is make sure that we’ve got the we’ve got the mic ready for the next question, so that we can have lots of questions. So just catch my eye. I’ll make sure there’s a mic.

Audience Member 

I don’t have a question, but I think in answer, the answer that you gave to Mark’s question just then, you had a superb definition of psychological safety on your slide, which I absolutely loved, which is which was, broadly, not being afraid of the implications of opening your mouth. And you know, it’s not about being afraid to criticize, right? It’s about not being worried that what you say will cause implications for you. There we go, the fear of repercussions, that brilliant framing of it, right? Similarly, if I’m getting concerned that we’re getting overloaded, that we’re not being focused enough, that we’re not having the difficult conversations. If there’s psychological safety in place, I’m not going to be scared of offending somebody, even if I’m the CEO or I’m the CPO. So it is about that culture, but I love this definition.

Melissa Appel 

Yeah, and a lot of times the CEO or whoever’s in charge executives, they don’t realize, but people are sort of afraid of them. And anything they say, they’re like, oh, I have this idea. People like, great. I’m gonna go do that right now. And so if you have this culture where you’re not afraid to speak up, right? You say, Oh, that’s a great idea, but we’re working on this other stuff right now. Did you want us to switch? Or should we keep working on this other stuff? Then you get the question, instead of people going off and doing stuff that wasn’t intended.

Audience Member 

That was a really good talk, though. Thank you. I’ve something I do with my team is like, force them to give me bad ideas on purpose, which I really enjoy, and it’s the worst idea possible. Basically, it goes really, really dark very quickly. But I do occasionally have team members who join who literally can’t do it. Like there was one particular girl she just could not give me a bad idea no matter what. Like it’s just the idea of giving her boss a bad idea was just horrendous to her. So, like, my problem is that I’m very bullish and like, extrovert and loud, so my answer is always, like, aggression, basically, just, like, just do it, like, get people to do these things. Like, what’s the healthy way of doing that instead?

Melissa Appel 

Yeah, I like the idea of asking for bad ideas, right? And as you know, some CEOs or founders say, Oh, my door is always open. You can come tell me anything, but then you go and tell them, and they’re like, No, that it’s wrong. And so I think that that’s a great start to make it open for people to, like, give bad ideas. Like, there are no wrong questions and things like that. I think sometimes it might be the phrasing, right? Like getting to know people. If they’re like, it’s okay. If you want to come tell me this, like one on one, that’s also fine. If you want to write me an email, that’s also fine, right? If you want to have time to think about it, because some people need some time to think, and they can’t necessarily say things right then and there. I could talk about whatever any time, but I know not everybody can do that.

Mark Littlewood 

Amazing. Thank you. I’ll come to you, Steven.

Audience Member 

If you remember Josh Linkner from a long time ago, he had the concept of, what would your anti hero do? So, what would Darth Vader do? If you can’t get your employee to give you a bad idea, ask them for their favorite anti hero and get ideas from them.

Melissa Appel 

Well, Darth Vader would change his mind and then make you pray he doesn’t change it again.

Audience Member 

So if you think about what you talked about, the CEO and CPO butting heads. And you’re, you’re sort of talking about when, the guide to when needing a product manager, or, I guess, a CPO in that example. Was it a situation where, actually a CPO was brought on too early, and the company perhaps could have survived without a CPO. And how do you make that decision as a CEO?

Melissa Appel 

Yeah, well, this particular situation, there were actually, like, five or six sprint teams, so it’s definitely there was enough going on that they need. And this person actually, he was a VP with this original CEO, and then the new CEO came on and they promoted him. But I think the difference between like needing a product manager. So somebody is doing the product management work. At the beginning, it’s the founder. Maybe there’s a CTO who comes on. Maybe they do some of that work. And the work from the previous presentations, like, what is the problem? What do we actually think we might build. How is that going to solve it? And so when you first get started, you might not need a product manager. If you just want engineering to run faster, you’re like, I don’t have time to like, be in the details. You might want a tech lead. You might want a project manager. It’s when you say, Okay, I have so many problems to solve. I know what the vision and strategy is. I have so many problems to solve. I need somebody to go dig into those. I need somebody to go talk to customers, figure out define the problem, figure out what’s going on, find patterns, and then figure out what kind of the baseline solution might look like. That’s when you need a product.

Audience Member 

Thank you. So if I paraphrase that back, what you’re saying is that when the CEO or equivalent has more operational things to do that they’re unable to do the assessment on the opportunities. That’s when you look for a product person.

Melissa Appel 

That’s what I say. Yeah, it’s so at the beginning they don’t have enough time to, like, get into details on engineering. But, like, that’s not really where a product manager is most successful.

Mark Littlewood 

Melissa, thank you. Thank you. Well done.

---

---

Upcoming Event

BoS Europe 2026 🇬🇧

13–14 April • Cambridge, UK

Price Increase on 27 Feb.

Get Tickets