The product manager working on an incubator or an accelerator or something internal corporate innovation initiative, you end up working very differently from the rest of the org generally, and you have a different charter. You have a different mission. You're not looking at, hey, we have this 20-year old product and we're trying to fight gravity and keep it going and add a feature through to it. You're really trying to re-imagine usually a capability that your company already has, but in a different way and disruptive way. You might leverage exponential tech, like AI, or something, but you're trying to re-imagine what you're already good at. Well, what is it going to look like in the future? Can you build a business off that? Almost every innovation group I worked with in enterprises, that's what they're focused on. They're focused on, what's the new technology adoption curve? How do we jump on that? And then, can we re-imagine what we're already good at doing in a different way to deliver our value? And that's the challenge really, as a product manager because you don't really focus on the product as much, you're focused on the value proposition. And then, can we leverage a new tact to deliver that in a way that's unique and that's defensible? And so, what happens is you're usually on a cross-functional team. So as a product manager, you're going to need design help, you're going to need engineering help, whether that's software or hardware, and you need to be dedicated. And that's really important. Almost every team I worked with is cross-functional and they're dedicated to the work. This work is hard enough when you're dedicated. If you're not, it's almost impossible to do it well. So the reason I really like cross-functional teams here is because when you're going through this ambiguity and you're going into the market and testing these new ideas, how to deliver this value proposition in a different way, you need to be able to address different kinds of risks. Like, are you solving a real problem? Is this viable to the business? Can you actually do this? Can you build something that actually deliver this value? So, having those three kind of functions and roles on the team is really important to address all those risks. Otherwise, it's kind of like you and you're doing solo, you may not have the engineering expertise to really address feasibility, or you may not have the design expertise to really understand. Are we solving a painful problem and does this fit in the customers' lives in some way? So, the team is really, really important here. And then, how you work is a little differently from maybe a big waterfall project or a big agile project, where you're typically running at a really fast pace, almost like a startup, and you're meeting daily with your team. So, you're having daily stand-ups, you're talking about, hey, what kind of experiments are we trying to run today to learn of the market? And then, how can we help each other? It's kind of like your daily goal. And then, weekly you're planning. You're planning about, "Okay, what do we learn this week? And then, what do we want to learn next week?" And a lot of other teams I work with them on the traditional side, their planning cycles are much longer than that. But when you're working in innovation, you really need to go quickly, and you need to test in the market with real customers. So, planning about every week, works really well. And then, you're still reflecting bi-weekly, every two weeks about, okay, well, let's have a retrospective. What's going well? What do we need to improve? What do we want to try, with how we're working. Because with this experimentation work, you're dealing with extreme uncertainty, and you as a team need to be able to pause and reflect on, Hey, that experiment didn't go so well. What can we learn from that? How do we improve upon that? What are some things we'd like to try differently? Is this working or not working?. And so, that moment of reflection is really important for these teams to keep growing over the 90 to 120-day runway they have. And then at the end, you have this stakeholder session where you've tested it in the market. And the way you've tested in the market is usually a combination of, we've done customer interviews, problem interviews, solution interviews with customers. We've actually maybe done some landing pages or some acquisition to drive people to that value prop to see if they're there. Do people even care about the idea of this solution before you go build it? I see paper prototyping. I see concierge's minimum viable products, where people fake the experience before building all the stuff around it. To see, hey, if we deliver this value in a real way, do people care? Will they actually do something versus what they said they were going to do in an interview? And so, you're almost like trying to gradually build confidence in your investment decision, which leads up to that meeting with stakeholders. So in that meeting, you really bring all your data. You bring qualitative, quantitative. Here are the hypothesis. We heard about this. Here's what we did. Here's what we learned from them, and this is what we recommend. And it's really checking that against the vision, your charter which you had in the beginning with stakeholders. And if they're really empowering you, they should be open to looking at this data. You can't control how they respond to the data but you can show them the data and say, "Look, you asked us to work a different way. You gave us this ambitious charter. This is what we did by testing with real customers in the market, and this is the data. So based on this data and our vision in our charter, this is what we recommend." And your recommendation comes usually across, it's like a pivot, persevere, or a kill decision. So if there's nothing there, you ran so many different tests, and you tried so many different things, and just nobody cared. Then, you might make the decision, "Look, we should just kill this for now, or park it on the side. You can always come back to it later if the market shifts. But nobody gets fired. And we might come back to that later." The persevere is, you know what? We think there's a signal here. There's some bright spots. But we don't know, we don't have confidence yet to say, yes, let's go with this. So, we need some more time or some more resources. Some more team members. And that happens too. So you might go another 90 days or 120 days and say, "Look, we're recommending this because we just need more time." Especially in different markets, it takes sometimes it takes longer especially, depending on your customer segments you're going after and the type of regulated industry you're going after. Sometimes it just takes longer. And then, pivot. Do we pivot? I know pivot is so overused. But it basically comes down to customer problem or solution. So, we were after a customer segment and we decided, look, there's nothing there. But this other segment, we realized during our testing, they actually have this problem and we want to go after them instead, or the problem. We're really passionate about this segment. But you know what? We were interviewing them and testing with them, they had a different problem, that is more painful that we think still aligns to our company's vision. So, we want to go back to that problem. And then finally the solution. So, if you're testing things and you're on the right customer's problem but the solution isn't resonating. Just having that solution loosely held and being open to doing different things with the solution. So, usually the meetings are, they're kind of intense but at the same time, they're not defensive, right? It's not like, you've been testing too long. Let's all have an all-hands and then make a emotional decision, under anxiety of where you should go next with this. This is set in advance. You know your runway. You have a sense of momentum and urgency, which is so hard to create in enterprises because some projects just go on forever, right? And then, it's like what do you do with this? Where does it go? And I'm a big believer in people self selecting in-and-out. So, if you believe in this initiative and you want to scale it and stay with it, then you almost become the CEO in a way of it as a Product Manager. You can take it and go write it and scale it. But if you're not committed to it, don't stay with it. Self select out and say, "Look, I'd like someone else to step in here. There's some other ideas we have in the hopper that I'd like to take in and test. Let's form a team around those and go." So I try not to do these mandates because I feel like if people are really passionate about the work, they're not going to reach good work. If your product managers don't believe in the work, they're not going to create an amazing product. So, you have to believe in it. And so, I'm seeing less of the hand-offs now. I'm seeing product managers to stay with the work and scale it and really own it. All I'm seeing them self-select out and say, "You know what? Someone else should step in on this one. I'm going to pull something else from this idea. Let's form a team around that and then start over."
