Arguing Agile

AA207 - Innovation: It's Someone Else's Job?

• Brian Orlando • Season 1 • Episode 207

Share episode

Should innovation be outsourced to specialized teams, or integrated into your existing product teams? 

That's what Enterprise Business Agility Coach Om Patel and Product Manager Brian Orlando are debating today! 

Listen as we debate the pros and cons of separating innovation from implementation, exploring why "if you build it, you own it" should extend to innovation as well. 

Join us to learn about the pitfalls of innovation theater, the challenges of knowledge transfer, and how to truly empower your teams to innovate!

#Agile #ProductManagement #TeamEmpowerment

agile, product management, innovation, team empowerment, product leadership, agile coaching, product discovery, innovation teams, product development, team collaboration, organizational silos, knowledge transfer, MVP development

= = = = = = = = = = = =

YouTube

https://youtu.be/Sn7B8zqNlnk

Subscribe on YouTube

https://www.youtube.com/channel/UC8XUSoJPxGPI8EtuUAHOb6g?sub_confirmation=1

Apple

https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596

Spotify

https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3

= = = = = = = = = = = =

Toronto Is My Beat (Music Sample)

By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)

CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

who do you think should be innovating and moving us forward into the future? Innovation? Leave it to somebody else. Oh, we don't have time for that. I didn't expect you to say that. We're talking today about R&D type of work, new, new development features, breaking into new markets. Some people call it zero to one. Yeah, some people believe in letting someone else do all of that innovation, and they believe that doing this will free them up to do other things, or maybe they can rely on specialist expertise that these other people bring to inject innovation into their teams. we probably could find some benefit outta both sides of the equation again, I believe in you build it, you own it. So why would you spend a bunch of time with your developers and your development team, learning the customers and the customer pain points, and then say, yeah, but all the new features are gonna be built by this other team. Yeah, that doesn't seem right to me. just the cognitive dissonance of trying to square that statement in my head. There seems to be a gap there, but it might be contextual if we're arguing the other side Maybe innovation into newer things, new technologies perhaps. Requires skill sets that we don't possess currently. So we're hiring that, bringing other people in to do this work for us, the ideation, the innovation, and so forth. I do agree there are pros and cons. let's start with that category., in order to innovate, we have product teams, maintaining our current products, right? And we want to bring in people with very specialized skillset. To take our current products or, or pieces of our current products and launch us ahead. the immediate one everyone would think of here is ai, But also data science, Like mathematical algorithms and stuff like that to work inside of our data sets, how we can change things to make a little more sense. Out of the data that we have. that's a good one here. Back when big data was the meaningless term that everyone used to used data. Yeah. Hadoop. Like I, I worked on a, Hey, hey, you keep your Hadoop to yourself. Thank you very much. I worked on a big data platform where they were trying to basically build a catalog when you went to build dashboards and stuff, all the big data is in the catalog. You just grabbed the fields from the catalog that you want. And that was a dream. They never did that, of course, but that was a dream. And, we certainly had like people on the team that said like, whoa, they have a very special skillset. No one else has a, that skillset. So we need to have them be, we needed to have them do all their work up front. Yeah. That, that, I mean, that was, that point was used in that instance. So I like, I'm pitching it as I'm about to defend it. But, but also I lived through it, so it was a train wreck. it created that dependency, right? you couldn't move ahead unless your dependency was met as a kind of predecessor. So emerging technologies that you don't have skills for, that's a case, right? Yeah. ideally you would want your team skilled up in that, right? Yeah. I mean, that was the first thing I thought of is like, well, I need to bring in data sciences to do whatever. Like, how is that any different from well, my team has to go out and pound the pavement and bring in leads and get sales across the finish line. So can I get a sales person to sit with my team and bring my team in when the account management calls are happening or when the new sales demos are happening. Like, can you bring. My team members in to those demos so we actually can pitch and talk about our product that you're trying to sell for us, the typical sales organization is completely divorced. Oh yeah. From like, that's not, that's not like the, the more effective ones where you are going. It's funny, it's not even in our notes. I'm sure it's not in our notes the same thing we're talking about now, we're talking about adding specialist skill sets to your team. nobody on the team knows Kubernetes or Docker deployments Nobody knows how to deploy via whatever, GitHub actions. Okay, cool. Then you break somebody off for a sprint and they learn how to do it, now we know how to do it this is an odd arguing point of like, we gotta go out and hire someone specific, this specialist to do this specialist thing. Because from my perspective, like corporate finance, HR for hiring people, recruiting and hiring people, posting jobs, marketing, when it's time to hit the street with marketing materials we have a dozen in-house specialties and we somehow mesh those and make those part of our normal workday. How is this any different? the only argument against that would be that, team members can't be left alone for a sprint to learn this stuff maybe you need to send them to a class. or bring someone in to train you. But that's , very short-lived.. Once they learn this stuff, they practice it on their own time, But to actually have someone do it on a sustainable level, that is definitely an argument I cannot get behind. I mean, look, , let's say you are a founder at a tech startup or any startup, maybe you pay a product coach to come in every week Spend half a day to help you get your roadmaps ready stand in front of customers, double check that what you're doing with like MVPs to make sure you're not building too much, not wasting money. Like just paying a consultant is what I'm saying. Yeah. But that's not innovation. That's simply getting the help you need in your practices, right? Right. But you apply that technique of like, I'm hiring a product coach.'cause I know I'm not great at product to this other technology of oh, I think we should have AI agents at the heart of all of our software now. maybe we need to get somebody in who knows a lot about AI agents and then embed them with my team for the next four sprints they and my team together kind of cross-pollinate the skill maybe they need to stay around longer than that six months, whatever. It doesn't matter, right? It doesn't matter what skill it is and what timeframe we're talking about, the structure is the same. you have found a critical skill that your team has not had before. You need to add it to your team somehow. So make that process happen. Don't say, my team doesn't have this skill, so I'm going to take this thing that I need and I'm gonna have the adults create it. And then I'm gonna give it back to you kids. To play it back, what I'm hearing is you don't outsource that innovation completely. You enable your teams over time to learn those skills so that when you outsource, what happens is when those people go away, whether it's a company or individuals,, they take the knowledge with them. that leaves a void in your team that at that point you're scrambling you may have your product out in the wild. you have paying customers. You cannot afford to not have that. In your team. So don't outsource it on any kind of sustainable level, get your teams to learn it. They can come in, work with you and maybe explicitly have some of those knowledge sharing sessions so that your team can be enabled and learn. So I think, both of us , with the, Hey, we have to have specialist knowledge and bring them into, accelerate the integration of specialist technologies into our products. Yep. So you may need to bring in special talent. So I'm gonna award 10 points for that on this side. But also we both sort of naturally gravitated to the other side of like, yeah, you should bring in knowledge, but also like you're bringing back into the team that has to maintain and build this stuff. Yeah. Enable your team. why wouldn't you enable your team in the first place? You don't need a different team to do this. It's just your team. Correct. So a thousand points for against jackpot. Yeah. Alright. Alright, so let's move on to the next category which we already have been sort of talking about and I want to pitch this one to you and I'll actually try to defend this one. Okay. So if we have a special team that just does MVP development. And launching with customers to try new ideas. That's all they do. We take that away from the teams. We just have the special team do it., maybe the team still can do it if they want, but the purpose of this other team is just to try to launch MVP IDs and see what hits. They can run around all the products in my portfolio and be constantly probing for what's gonna hit with customers. And basically they can accelerate any one product by just doing this full time. You have to assume that , the team, you've hired people and you've honed the team where the people you have on the team are very good at doing stuff from the ground up. Like, like clickable wire frames that connect to real data. Because like for example, a lot of people don't know. people are surprised when I tell 'em Figma, you can connect Figma to a real data source.. You can connect to a database or a spreadsheet . So the data can be dynamic. You can be on the backend. Remember the old, the old, like the man behind, the man behind the curtain? Yeah. The old demos where somebody was behind the thing, like changing the data or whatever. you can do that kind of demo. And the customer. They would never know. It's not a real product. unless there's a certain level of savvy with software development or if they right click.'cause in figure, you right click it shows you all the clickable elements anyway I don't dunno if I'm giving away secrets, don't right click Yeah. People. it allows you to test the diversity of your portfolio. Constantly testing the outside bounds of your portfolio. otherwise teams sometimes get caught up in feature development or infrastructure stuff that they're told to do, and they don't always reserve time to break out and do something radically different. It's the whole, everyone's riding horses. You can't iterate your way into like creating a car. You need a big leap. Yeah. So what would you say to the concept of like, if you have a team that's constantly probing the edges of your business. They can make these breakthroughs and then when they prove an idea a true MVP they can bring it back to your team, lay it out and help your team and your product manager adjust their roadmap and quarterly goals Yeah, it's workable, I think as a model, but here's what I think might be a challenge with that, right? If you've got that specialist team doing this work with the client and your development teams over here, aren't they divorced from the client a little bit so they don't hear firsthand and have the opportunity to ask questions firsthand, get that feedback they're hearing secondhand so there is that issue that you have to get around. I think if I'm gonna push back against that, that is valid. I think a way to nullify what you just pointed out was you bring the product manager or product managers, you bring them with you. and you rely on them to get you meaning the person on the innovation team in front of their customers. You're sort of hijacking good working processes To try your new stuff. It's fine, it's fine, this is the first time I'm working through this talking point. So trust me, it's a better idea in my head than it came out of my mouth, said Brian. Never in his life. But you're basically using all the customer connections to probe new ideas. That actually seems like a benefit to me. it seems like a counterbalance to this because the product manager or whoever has these customer contacts, they would probably be. Very standoffish about letting you go in front of their customers. If your idea is not great, cannibalizing features or dangerous they probably would push back. And that is probably your signal if you are the person on this innovation team, these guys away. Yeah. yeah I don't really have a great idea or whatever. What do you think about that? No, I think that's legit. I I, I think you can, you can adopt this model suit your purpose, so maybe even have your salespeople in on that, right? So they're aware of what is actually being talked about, quote, unquote, under the hood. oftentimes they don't really know what's going on under the hood, so yeah, you could adopt this model. In any way you want. Right? And the way you've described it, there's probably a happy medium there, right? you could say, well, maybe have your tech lead present. Right. Have your product people present as well. Do a dry run first with your internal product people, and then go in front of a customer. there's different ways of doing this. I don't think there's a black and white here. I like this idea. I think this is probably one of the strongest points we will present today of the idea of Hey, this one team can always be pushing the boundaries to launch you ahead. The issue with this at some point in poker, we have to put our cards down on the table. And you will see, Michael I have four of a kind, but that fifth card. That fifth card, that fifth card is corporate finance is gonna look at this team and be like, this team makes me no money. So I understand you're pushing the edges of my portfolio, , what is the ROI of pushing the edges of my portfolio given that the revenue never goes back to this innovation team. It goes back to the product team that implements the if you actually push an edge of your portfolio and think there's a real market for this particular thing that we developed, like a tiny widget that's not automated at all. You guys should take it into your roadmap, do three months of work on it, push it out, and now you've got plus 15% revenue year over year it's like how many companies are willing to staff a team. To do something like this where the revenue can only be measured months and months in the future, if not years in the future, and then cannot be directly tied back permanently to the other team. I concur with that. I think from a being conscious point of view, this is hard. But if your innovation team's not very large, You might be able to do it. it should not be very large. Agreed. You could have, you could have like a conglomerate for example, right? Say, say your Unilever and you have a whole series of product portfolios every portfolio could have a team of one or two potentially. And that's still absorbable. it's like the cost of doing business. It's the internal people. Mm-hmm. Like those those bean encounters themselves aren't making any money directly, so. There's an argument we made there, but also the counterpoint is if you have too many people there. You're gonna stick out like a sore thumb. Yeah. On their spreadsheet. Yeah. So, yeah, I think there's a balance to be had. Well, this was a good category. I feel like it's probably the best, the best point we're gonna make. Four. Four. Yeah. So on that, I think I'll award a hundred points four. and on the against category, I'll award it. One monkey Three monkeys With bananas. That's right. I don't know how to draw a banana. You know how to draw a monkey. Yeah. It's a stick figure with big arms. Ah, right. Three monkeys and three bananas. There you go. Be against we're all equal opportunity. Ape. that's exactly right. Let's go down to what I think is another strong candidate for this one, another one that should be for the innovation team is that it creates strategic level initiatives, Because like what I was talking about you're pushing the boundaries of what your products can do. And you're going for a breakthrough. And at the leadership team, they'll say, well, this effort is strategic. And what they really mean by the words quote, strategic is, I don't care how much money it costs. I've gotta have it, right. I've gotta have this breakthrough. And the breakthrough doesn't have to pay for itself right now, or quarter to quarter or whatever, if you're a quarterly capitalism yeah. However, you're saying that having a separate team outside of the normal teams somehow encourages alignment with strategic goals, strategic initiatives. That's, that's a tough one for me to, I, I understand the concept. like think about a typical product if I'm gonna defend this one, I guess that's what I'm doing. This this podcast. I'm defending all these, if you have this innovation team and they're separate from your product teams, their roadmap gets populated just like a normal product manager's roadmap gets populated. they're talking to like the head of the business the C-level people probably Yeah. Or maybe like director level people in a larger organization to say what boundaries should we test? What new markets should we probe? So you're saying this team is trying to innovate, but they're restricting themselves only to the strategic level of the organization. Yeah. So their roadmap is directly contributing to figuring out our strategic direction. They're almost like a test team. Oh, there, you're not allowed to say test team. Ooh. Test testers are like, Ooh, that's, that's an offshore thing. we want to fire all of the testers. It's almost like people whose job it is to test, but the thing that they're testing is strategic initiatives viability, business viability. Yeah. Against a certain market. Yeah. They're trying to scope out potentially viable products their roadmap nicely fulfills the organizational strategic roadmap. Right, That's all good. The executives feel good about that because they can see that, oh yeah, look at this team. They're doing exactly what we, our vision is being fulfilled. Right? The problem is how do you justify that team, because there is no ROI on that it's not that it's hard to measure. there is nothing because whatever they're doing, to your point about doing tests and these aren't even hard tests often, right? in that sense of the word, they're basically just surveys, polls maybe some vaporware that's being produced to kind of fill out the customers. There's no ROI there. The difficulty is how long are they funded before someone says, Hey, we're wasting money here. I think that's the problem you have to solve first though. Your financial model needs to be corrected where you can, you can tie ROI to this team. if a team is picking up ideas and concepts that were first vetted and given the go ahead from this team, as the development process moves on and revenue starts getting tied to that feature the money needs to flow back. Yeah. They need to accrue some kind of ro i is what you're saying? I agree with that. even just like Disney points on paper, like Mickey Mouse points on paper. It'll be that something. But still you're right. there's justification at the end of the day. Five ideas went through and they're actually now in our product. What does that mean? What's the uptake with our customers, et cetera. There's a way to do that. I imagine, right? But I don't know if it's being done out there. Well, it's not, yeah, that pretty much settles it. All right. so as far as being strategic, there's another side to leadership, the visibility of seeing that you're putting effort into a thing. without, quarterly ROI that in and of itself could be valuable to leadership. There still is something in this that is valuable. Tangible, Definitely with a promise, this will, one day this will become real. So it's like almost making paper airplanes, but that's fine. The danger again, I'm gonna go to the other side, right. The danger is with these executives this leaves a back door clearly open for them to push through their pet projects. Of course. So all that stuff about getting positive signals from the market goes out the window. The risk here is you will develop something that is disconnected from reality. Reality. Yeah. To be honest. This is why I hate the acronym MVP. Because like MVP should be helping you in the case where you wanna make sure that an something that you're about to build has business viability, meaning the business can sell it, the business can receive money from it. The business knows how to communicate its value, right? It fits well into like sales process and all that kind of stuff. And if you're building things completely disconnected from your current business model what are you doing? why are you even working on that? Mm-hmm. There's not, there's literally no other important things you could be working on. This is a big danger of farming off your innovation to another team, is they're gonna go off and build you a bunch of cool tech stuff and put it on a shelf. well, who pays those people's salaries? Building cool tech stuff. We did an episode on remember we did an episode on, shared services versus like, that was quite early on. Yeah, it was. Yeah, it was a while ago. Arguing Agile 1 76, why shared services fail in Agile organizations. It should just be why shared services fail. Period. That was the one we were talking about. Keep all my specialists outside the team, which is very similar to this topic of I'll keep all my innovation people, all my very special chosen children outside of the teams, outside of the unwashed masses of the teams. Yeah. they'll do my special work. It's not an uncommon model though, right? We've seen that in some organizations where they have. Things like innovation works, skunk works product labs or digital labs That's the specialist niche, right? they're the ones pushing the boundaries, But the problem with that is money aside, you're building a fully cross-functional team that doesn't actually work in any product, that's kind of ludicrous Are they talking to customers on a regular basis or are they just doing internal facing work? They think is cool, like cool tech developments?'cause again, how long are you gonna do that until the money runs out? normal development teams doing product development, they have to deal with how long can we do this until the money runs out. Yeah. And this team doesn't I know it makes no sense, but I'd say a majority of the teams out there that are doing this are doing stuff because it's cool tech. It's the latest thing. So we're gonna do it. But you'll end up with a non-viable product Either because the business case isn't around it, or it's not what customers need. Or you just haven't done any actual testing in the field. You know, you're just building things that you think are cool. Even if there was a little traction beyond that, these specialist teams will then end up passing that tech to the development teams to integrate. And now you've got a situation where the dev teams are trying to fit a square peg in a round hole, right? Because the integration challenges don't come until then, right? So you may as well just discover and integrate. As and when needed. Yeah. Well, I'm pretty sure we just talked about two categories without giving points. I want to jump us over to, I think that this innovation team being separate is gonna end up complicating your product roadmap and prioritization decisions, and also your ability to communicate your product roadmap. Your goal setting apparatus in the business is gonna complicate that. So if you do quarterly planning and stuff to say , oh, we're gonna refocus our roadmap and decide what new goals we're gonna attack. And then, then as we decide them, we're gonna do some tests and then the, the results of those tests land on the roadmap. Now you've got this other team saying, we did the thing. And it was successful, I don't understand what you're doing. We did a thing for you. It was successful. Why are you sleeping on this? I, as a product manager, don't want to be in that position where I'm dealing with this other team that seems to be proceeding squarely from ego saying oh, I developed a thing in house. It's so great. What customers did you test that with? Why would I test with customers? How dare you questioning me or whatever. Get outta my office. Yeah. We don't want reality here. For the sake of the podcast, I can argue the other side of it, even though I don't agree with it. the other side of it is by having this specialist team do innovation, I'm removing the load from your dev teams to have to do that. Right. And I'm in their sprint reviews, so I'm plugged in with them. Yeah. So that's the other side is like, well, I'm reducing that load so they can develop and we're constantly feeding them what to work on so they don't have to figure that stuff out. We're already doing that. So there's a lot. That's a fallacy. I hear that from executives all the time. It's like, course, I'll just tell you what you don't have to do. Customer discovery and all that. Marty Cagan and stuff. I'll just tell you what to do. Also, why don't we just let this innovation team talk to all the customers and then they can do all the discovery for us and they can be the discovery team and we'll be the delivery team and we can divide the two sides of that diamond. Yeah, I know. Disaster. you see how slippery, like that slope. I understand that slope wasn't even slippery. it took one step To get to that slope straight down.. It was an academic kind of argument against, but a lot of what we're talking about today, the academic sanitized version of it, the run by accountants version of it. It does like that step makes a lot of sense to those people. Sure thing. Also. It's terrible. So there's that too. All right. let's hit all of our points here. We talked about disconnecting the development with the reality of what customers need and the customer discovery process even if you have good customer discovery chops, now we're gonna fight about it. When you try to jam it into my roadmap or force it into my roadmap because if I am a real product management, a self-contained team that uses product discovery. I am leading my own efforts as well. now you're doing discovery efforts and I'm doing discovery efforts, and we're both working outta my backlog. So now we got two different teams saying, we think this should be the next highest priority. So I want to cap the disconnected from customer needs category. I give no points because nobody deserves 'em in this category. Agreed. Absolutely. Because we didn't accomplish anything. and I want to deal with a much scarier category to me, which is we're setting up this innovation team so that they can test the boundaries and help us accelerate into the future. And we are claiming that it actually helps reduce organizational politics around innovation, right? because sometimes when you innovate, you're like, well, whose job is. X, Y, z oh, well, is it the engineer's job to do whatever? Is it the product manager to do whatever? Sometimes the product manager says that the developers aren't doing enough yeah. Or sometimes you have development organization where the developers don't wanna talk to customers or I'll give you a great example. You ever been in an organization where you hear this term hands on keyboards. They're like, why? Why am I gonna break away the developers to do this thing when they're not turning in productive coding time, they're just playing with new technologies that's not counted against their utilization. So like on paper, they suffer for bad metrics they're being judged on, Right. I agree. people are like. Brian, that's, that's a bad faith argument.'cause it's, there are bad metrics in the first place. Absolutely. Yeah, I agree. But also , in order to get around all of the politics involved in like, well I'd like to use your developers to talk to customers. I know they'll take a hit to the utilization. I don't care. I prefer them to do that. Brian you can do that, but make sure they're above a certain percentage , these games Yeah. I'm talking large businesses. I'm gonna create this other team and they don't have to, they're not judged by these metrics. Right. They're kept away from these metrics so , again, we go back to the Deming. Oh boy. We're going back to the Deming podcast, arguing Agile 1 99. Because you've set up a system and the system is just bad. It's a bad system. You should change that system. But also you're saying , well, we can set up this team. It's outside the system and we don't have to deal with all this politics. The reality though, is we just outlined in the previous category you don't have to deal with these politics, but also you just said, I'm going to test my innovations and your team is gonna test your innovations. And then when we look at them together, we're gonna say, I don't understand why you're not bringing my innovations into your roadmap and dealing with it as a high priority or worse. When it fails, it's your stuff that failed not mine so yeah. I implement, your changes and then I don't see any advantage no spike in customer usage. No extra money, no contract sold, no nothing Hey, I thought you tested this Now we're playing the blame game. Now we're fighting. Now saying, but pry if your development team did a good job of product in the first place. Yeah, yeah, yeah, yeah, yeah. This, this is horrible. but this is actually, quite prevalent out there. If you are working in this way with an innovation team, well, this is supposed to be lobbying for innovation teams to reduce organizational politics around innovation. Yeah. I don't, I don't know how you do that, but I think actually I'm gonna award a negative 110 points because I just don't like the case It's terrible. It actually goes in the opposite direction. Negative 110 points for outsourcing innovation and plus three Scooby points. Scooby Doo eating Scooby snack plus three Scooby snacks. Nice. so another good point is probably the last point for the innovation outsourcing that we'll talk about today. They will say it bridges a gap between r and d and. Like traditional product development. Okay. Like if you think about r and d, like meaning like, I've gotta have a specific pool of money and it's, and like I've gotta dedicate it to spin up something, right? Like government for example, or finance for example, has specific terminology around what, what is considered R&D activity. Because the government can like, spend money on R&D activities Hey, I want to go create a new fighter aircraft or something like that. So the government is willing to, to give a certain amount of money. They do the same thing with, with like, not obviously not military technology. Other things. And companies do the same thing, right? I'm gonna break off this much money. to develop this new, maybe a new product line or a new innovation or something, right? New technology, doesn't matter what it is. So they'll say, well this bridges the gap between building this completely new line of business. Right. Disconnected from any of our other line of businesses, in reality, we can argue about how disconnected it really is you're not gonna jump into like, I'm a FinTech company and I'm gonna go start producing Hollywood movies, I don't think that's realistic. I think it's probably like a FinTech company that also does something else adjacent To the FinTech space. Yeah. and probably leveraging a lot of what they already do. Probably. Yeah. the idea here is like, we have these concepts and they're, they're, they're born out of true r and d. Like, I break some people off for a period of time with a run rate, basically I break off a subset of my company as a startup and I fund them to go figure something out. You know that. So like true r and d, and then at the end of that process. They will help advise me how to roll it into my current portfolio offerings. So they're completely disconnected. they might be trying to break into a different market. They might not be cannibalizing features from other products or services They might truly be exploring new boundaries. in that case, that makes a lot of sense to me. I agree with that. It does make a lot of sense. I think again, it's how you implement this structure, right? You've got R&D, they're doing things, but are they also vetting the signals from the customer on what they're building? Or are they just building it internally and then passing it to the dev team and say, see how you can use this? You just identified the clear issue of this team is not staffed. Or, or, or potentially skilled to be maintaining production code, right? In production. So probably the weakest part of this argument, which sounds great on paper, by the way. Right? Of course. Like if I'm an accountant, this sounds great. Easy budgeting, right? Yeah. Put, and the R&D is this in a line item? I put money in a bucket. This team takes it away, figures it out. They do amazing things. I can go to my tea parties or whatever at the end of the year. I don't know why I go to tea parties. But in reality, , at some point, this innovation team has to hand off to a real team of engineers to build it maintain it and scale it right? Unless your organization is saying, all my teams that start outside of a existing product line start as like seed funding teams, right? And then when they launch and hit new products. they break off and they go and maintain that product and they come outta the seed pool and then they become a fully formed product team. then I staff them with more engineers and the seed accelerator type of organization hires more people to launch more products. That, that, that it's, it's not quite the situation we're talking about today. No, but that could work. And often it works in the guise of establishing JDAs with other companies. Yeah. Who potentially are maybe your customers that makes a lot of sense. so you are actually working together in the same room as reps from the customer. But again, that's not a model that's very widely used today, I would say. I don't know anybody that does that to be honest. there could even be a bidding process at the end Yeah. The creation of technology where you bid it out to sell it to companies like, Hey, we did this innovation, it works. Here's the way it works. we have no intention of maintaining it. We're gonna sell it to somebody else., your incubation business unit could basically auction off That product. Yeah. they're auctioning off nascent technology. but at the point where I would come in as a product manager with a team do I have to re-architect the whole thing to scale it to forget like 10 users, like a thousand users. Like I, I at the point where I have to rebuild the whole architecture it's almost not even worth my time. Yeah. Maybe it is, maybe it isn't you. There's a lot of, it depends in this category. Yeah, there is. So does it really bridge the gap between true r and d and. Product development. I, I don't, I don't know if any, like the foreign against seeing the balance out here. A single point in each category. There we go. one point. Okay. One point. Yeah. Well, my pen doesn't work anymore. it's one point if my pen actually wrote it. we'll figure that out later a smudge for every team. A single smudge a pox against your house. let's see, what else? another category is the claim that this team being separate and only doing innovation, actually accelerates time to market for new concepts. in the idea that the team doing innovation can launch ideas into production and have people using it pretend for a second that this innovation team has good knowledge of scaling practices and deployment technology and they can create a vertical slice. maybe their vertical slices all start with it's gotta be integrated with our authentication and deployment technology. Right? If we're really using Azure for authentication, you log with your Microsoft account for everything, that's the backbone of all our technology. Log in with Microsoft and then we deploy you to the Azure Cloud services, . I don't know what they use Kubernetes. I don't know what they use. And whatever containers as you use this. I have no idea. So like there's a bedrock of technology that my innovation team is required by my engineering leads to use, So they are launching full stack, vertical slice working applications. the functionality is tiny, right? Yeah. So they're launching things. They're still valuable. Yeah. they're valuable. They have customers that sign up for the trial. The way I think about this is like they're launching things into an alpha slice it is working, it's in your app it's part of your package And if you want to expand on the features outside of the alpha or the beta, then a real product team has to take it over or maybe the company has to hire a whole team around it but that, that initial go to market of like, how are we gonna find the right customers? How are we gonna launch, what order are we gonna do things in This team could become experts at that specialty of go to market a lot of people fumble go to market. Sure. When you say go to market, like in the agile space specifically, and you say go to market, most people have no idea what you're talking about. So in this structure where you have an innovation team, because they're not doing anything but innovation, Then the go to market, essentially a time to market is as low as it can be. That's a good thing As long as they're speaking with customers, et cetera. So they're not building things that nobody wants. if you're actually going to market. You absolutely would have to. you'd have to partner with 'em. that makes sense. This is I think, the strongest point so far. I think a hundred points here and no points against 'cause I think if you do this right, I probably could think of ways to mess this up, but the constraints that we put on this innovation team already was like, you gotta use our deployment technology. Basically the, like the engineering lead or VP or something. Yeah. Came to the innovation team and is like, you, you guys are cute. I love what you're doing. One day you'll be real product people. but until then, you gotta use our authentication. You gotta use our deployment technology. These are our in-house standards. Our standards are non-negotiable. whatever you do, it's gotta be a certain level of quality. You can't be launching garbage and, and that's non-negotiable. adherence to internal standards is a prerequisite here for this team, because they could develop something in a completely different stack, for example. it won't fit when they turn around and say, Hey look, this is fantastic. Go put new products. Like yeah, no, it doesn't work that way. yeah, I agree. They have to adhere to internal standards for sure. it would help them to be honest. Yeah. Alright. Well, that was a little gem we found I didn't expect to agree with that one as much as I did. I assume whoever's on these innovation teams, like they should be senior developers compared to most of the other program developers. Yeah there's some assumptions in this podcast, but you could also rotate people in and out of this team. Absolutely from your dev team. So they grow. And you probably should, you should, you probably should. You probably shouldn't build a scene completely from outside because this is a great short term. Short, short meaning like six months, right? Media. Yeah, yeah, yeah. This is a great short term thing to reinvigorate your developers to let them remember why they got into development in the first place. To play with cool technology and to do cool things, to talk to people and to figure out oh, I can solve that. We have a couple points that we need to specifically talk about that are like pushback on this. One of which is it perpetuates building flashy demos like an innovation theater like the old Marty Cagan product theater. Except in the bad form of it Sure is. Like, it's the illusion of innovation, but in actuality no customers have ever said they wanted to use it. Nobody ever said that was their pain point. You don't know if you can sell it. You don't know if it'll scale. all of these things Fit in this category. Absolutely agree. Oh. is that the end of the category? Okay. Well, there's only that one we talked about., the scale we touched on earlier, right? We did, yeah. Struggling to transition to scale. So it's the same thing. It's like someone's gonna bring me and be like, oh, I think when I use the same data that's in your application, but I use it in this other way, it looks , more attractive. Well, why don't we just do that in a normal application? Like why don't we need to, exactly. Yeah. Separate that out like that. if it doesn't get us any more additional money from customers, I don't know, There's still, in the back of my head in this whole conversation, there's a need to justify the cost of this innovation team. In the back of my head, maybe some companies that's not necessary. Maybe some companies like the need to. Identify new and interesting, different ways to potentially monetize the application that maybe we're not thinking of. Maybe that in and of itself is strategic enough where they're willing to spend the money of whatever the salaries of this team costs. Yeah. To do that. Like it is, it is like rolling the dice. It's like, listen you know, if you go to Vegas how much money to roll the dice to get a million dollars, like how much money are you willing to bet for each roll of the dice to get that million dollar chance? That's this category right now to take that analogy further, you know who wins there, right? Look at all those big buildings, the casinos, so I think the same thing applies here, with businesses over the longer term, the number of times you rolled that dice. It's gonna come up seven at at least once. whatever that financial impact could be leveraged over a longer period of time. Sure. It's just like capitalizing assets there's a certain number of roles that you will make that, that, that, that you will budget to make and the cost of this team, or more than one team over a period of time fills in this number. So how much money do you wanna spend to try to get ahead? Right? And then that's one side of the equation. The other side of the equation is can you show me that you actually did get ahead and that's not necessarily ROI that I'm asking for where are the breakthroughs that, the normal product teams couldn't have made by themselves, show me the places that the product teams just move forward on their own I want to see both of them every team should be saying, this is where we move forward with our own kind of BFI ability, product discovery type efforts. Every team should have that anyway. show me where another team handed me the innovation opportunity that they had pre-vetted for me, that I couldn't have done myself. Maybe like that. that's the part where I was hoping you wouldn't break that out. Because, you could have done that yourself if corporate, rather than going to this other team would've just come to the team doing the work in the first place. All my arguments break down when let's say the innovation team, each individual fully loaded with benefits and everything let's say they cost like $250,000 per person. Yeah. So you got four people on the team, right? Product manager, three developer, product manager, ui, ux, person, two developers, right? A senior developer and a normal developer each fully loaded with benefits and everything. Let's call it $250,000 per person, a million dollars. Four people, a million dollars. You're spending a million dollars a year to push the boundaries of innovation, right? and what you just pointed out, like I don't think I'm gonna get away from it in any category we've talked about is like, why don't you just take that money and give it to the individual teams to say, Hey, I'm giving you additional money. You have your margin that you run your business or your product on. the business is gonna inject some money into your margin. Make your margin look a little bit better. And what I want from giving you this money, is when you come back to the corporate strategy, the quarterly planning type of events, show me which innovation strategy you're picking over another, show me which exploratory technology you've tried and which one you've picked over another. Yeah. And that's what I'm funding.. I'm buying some time on your roadmap to figure out what the next innovation is. that's it, that's what I'm buying. And, the most impactful pushback against that is like we got enough features and enough new innovations that we've already baked in the roadmap where we're like, we don't need the extra money. We're too busy to do exactly what we need to do now that sounds to me like we're too busy to improve. That's what it sounds like. It sounds like that. It can actually come down like that, but if you're giving me a million dollars, I can hire a couple of people maybe. So in the other scenario where you are funding a separate innovation team that you get away with for a bit until there's a change in leadership, which let's face it, it's quite frequent. Sure. And then you get somebody new and they form a Department of Corporate Efficiency. And then they send a memo out saying list 10 things you've done last week. And off goes this innovation team. when that happens you lose all that domain knowledge that these people have acquired, pushing the boundaries. It's suddenly gone. Right? Yeah. And, well, the organization will suffer badly. I feel that like the, the four outsourcing to innovation I, I don't feel they've picked up any points in this category at this point, sadly. And I feel the against has picked up 25 apples. Exactly. 25 apples. I wanted to award that one a a bit more fairly, it sounds like it's too easy to do it wrong. Like a lot of points we talked about in that category, they sound like they would be really cool especially the idea of funding as a vehicle to punch you ahead. That's really what all everything we're talking about here comes back down if you strip it all away. It's about I need an investment, right? To punch me ahead so you can give that investment and coordinate it off to this other team and make it somebody else's job. Or you just give it to the team and be like, oh, you know what? How about we'll hire a data scientist or we'll hire another ui ux person or whatever to conduct more user interviews. So one thing it does, if you do that is it makes it easy to attribute the success that results from that to the team. Whereas in the other scenario where you have an innovation team, how do you attribute a portion of the success to them that doesn't make sense? there's no easy equation that says we went to market with this, led by this team. So , how do you attribute that to them? Because the DEV teams will say, well, we did the work, right? So yeah. It's easier if the DEV team's doing everything. Let's cut straight to the spiciest. argument. I want to make, which is, it sounds like you've introduced a handoff in between when the innovation is done and when the product development begins. it sounds like you're like, oh, I did all of the innovation over here on this side of the diamond, and then I did all the development. The discovery was all done over here, and development was all done over here. We talked about this earlier in the podcast. But I wanna make a point in this category to say you're transferring knowledge and ownership of the feature and all the learnings and everything. Theoretically, you're transferring them. In reality, you don't really transfer them the people that are implementing it should be the ones who have the learning and should be the ones who've been involved the whole time. But with this setup, I doubt that very much. And also. And also also also double also, this is my second also with a handoff, like the team that implemented the original like, oh, I think this is viable for the business. And they put together this prototype or click clickable wire frames where they put together, like they don't have to maintain it full time forever. they don't have to be up in the middle of the night at all. their decision that this was a good idea is completely divorced from Reality I believe in, if you build it. You should own it. You are not gonna get any argument from me against that, unfortunately, because that is exactly the issue. People that are creating these prototypes aren't necessarily considering some of those ilities like scalability, et cetera, right? they don't care about that because they focus is on just getting it to work, and do those flashy demos. So yeah, absolutely. They also don't build in considerations for maintenance, right? Long-term maintenance of the product. It's longevity. They don't consider that the dev team has to live with it. Well, . Because of that, I'm gonna award outsourcing innovation to another team. I'm gonna award it a negative 10 ilities and against uh, outsourcing. Plus 10 ilities cool. So there's a mix of ilities happening right now. Awesome! There's a silos discussion that's happening here that we are not talking about. Like, because we probably talk about silos too often, but that's kind of what's happening here you're building silos, but all the innovation happens over here in this side of the diamond. Yeah. And all the development happens, like all the grunt work happens. I'll just tell you what to build how long until that innovation team devolves into just one VP who just tells us, oh, I talked to the customer once. who doesn't have any interviewing skills? Who doesn't have any business analysis skills? you're on a super slippery slope here. that's aside from the categories we didn't talk about today like, what if your innovation team is suggesting things that are completely duplicative of features you have already? that is a real danger if they're not communicating well. Right? Right. So you're gonna have two separate solutions being built in parallel or their level of expertise, Because they might just not know. there's domain expertise and there's technical expertise. So unless they're gonna become technical experts in your software and your infrastructure and also in your business, they could be missing some stuff when they're building. Oh, we'll build this new product. it's like if you could have all of your CSV material, but in a grid, I'm like, guys, that's, Microsoft Excel. What? We didn't know that. We just spent six months. Creating this grid-based editor, come on. Right, right, right. Well this is another argument for having your team members circulate between those two teams, right? Yeah, that would make sense. I mean, it's a solid against argument though. It is. well, it's a solid against argument, so I'll award another 10 points in against, and zero points for. So let's do a quick tallying of all the points for this podcast. Come Mr. Talley, man telling me bananas. It's complicated. Actually, the four outsourcing side actually had a bunch of points, believe it or not. Alright, I calculated, all the points. It looks like the four outsourcing innovation got 190 points, but it got minus 10 ilities. So that's a serious condemnation. Yes, it is. Big penalty there. And then the against outsourcing, which I don't know about my record keeping, but it got 121 points, significantly less points, but then it also got a plus 10 iiti. Oh, they clearly win. So that's enough to clench the category alone, even if it wasn't for the monkeys or the bananas. Yeah, I agree. Hey I think , the points are clear. You should do innovation as part of your normal product management teams. it shouldn't be someone else's job. It's your job. If you build it, you own it, and You innovate it, you build it, and you run it. Thank you for staying with us and let us know what you think about the content today and what else you'd like us to tackle. And don't forget like, and subscribe down below.