David Bland on new ventures inside the corporation

As a product manager working on an incubator or an accelerator, or some internal corporate innovation initiative. You end up working it very differently from the rest of the org generally. And you have a different charter, you have a different mission, right? 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 or two to it. You’re really trying to reimagine, usually, a capability that your company already has, but in a different way. And endorse a disruptive way. You might leverage exponential tech, like AI or something. But you’re trying to reimagine what you’re already good at.

What’s it going to look like in the future, can you build a business off that? Almost every innovation group I work with in enterprise, that’s what they’re focused on. You’re focused on what’s the new technology adoption curve, how do we jump on that, and can we reimagine what we’re already good at doing in a different way to deliver our value? And I think that’s the challenge, really, as a product manager, because you’re not really focused on the product as much. You’re focused on the value proposition, and then can we leverage a new tech to deliver that in a way that’s unique and it’s defensible? And so what happens is, you’re usually on a cross-functional team.

So as product manager, you’re going to need design help, you’re going to need engineering help, whether that software or hardware. And you’re going to need to be dedicated, and that’s really important. Almost every team I work with is cross-functional, and they’re dedicated to the work. This works hard enough when you’re dedicated, if you’re not, it’s almost impossible to do 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 delivers this value? So, having those three kind of functions and rules on a 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 into customers’ lives in some way. So the team is really, really important here. And then how you work’s a little differently from maybe a big waterfall project or a big project.

Where you’re typically running at a really fast pace almost like a start up. And you’re meeting daily with your team. So you’re having daily stand ups, you’re talking about what kind of experiments are we trying to run today to learn in the market. And then how can we help each other? It’s kind of like your daily goal. And then weekly, your planning. You’re planning about okay, what do we learn this week, and then what do we want to try to learn next week? And a lot of other teams I work with 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 biweekly, 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 did we learn from that? How do we improve upon that? What are some things we would 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 kind of stakeholder session where you test it in the market and the way you test it 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 there is a there there. Do people even care about the idea of this solution before you go and build it? I see paper prototyping.

I see concierge 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? Well they actually do something versus what they said they’re 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 hypotheses we had about this. Here’s what we did. Here’s what we’ve 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 and our charter, this is what we recommend. And your recommendation comes usually across a pivot, persevere, or a kill decision. So if there’s nothing there, you run 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 could 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 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 to.

So you might go another 90 days or a 120 days and say look, we’re recommending this because we just need more time especially in different markets, sometimes it takes longer, especially depending on your customer segment 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 basically it 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, does seem that 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, when 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 after that problem. And then finally the solution, right? So If you’re testing things and you’re on the right customer and 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 an 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 a near-crisis 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’s self-selecting in and outs. So if you’re a real big, 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 run 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 are 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 their work, they’re not going to produce group work. The product managers that don’t believe in the work, they’re not going to create amazing products so you have to believe it. So I’m seeing less of the hand offs now.

I’m seeing product managers stay with the work and scale it and really own it, or in seeing them self-select out, and say, you know what, someone else should step in on this one. I’m going to go pull something else from this idea. Let’s form a team around that, and then start over.