E1 - Product vs Project Centricity

A conversation about "Product Centricity", or the idea of treating internally developed technology as a product rather than a series of projects, featuring William Oellermann and a discussion of his recent blog post on this subject https://blog.alixpartners.com/post/102huyz/are-you-a-product-centric-company-should-you-be

Transcript

Copy Transcript Copied

Michael Gilbert: 0:01

A lot of companies have started treating their internally developed technology as products, even when they don't sell it to anybody. In some cases that seems to have helped and other cases not so much. Are you curious about when it would be a good idea and when it might not be? Let's talk about it. Welcome to The Technology Sounding Board. I'm your host, Michael R. Gilbert. And in today's episode, we're going to talk about treating internally developed technology as a product. And today, I am lucky enough to be joined by an old colleague of mine, William Oellerman, who has been doing some thinking and some blogging on this exact subject. I recorded the conversation with William earlier. So let's just play that back here, sit back and listen and hear what he has

William Oellermann: 0:50

Yeah, knowing the difference between to say. And at the end, I will put together the thoughts that I've ha,d having had the chance to walk through it and digest it being good and being lucky. and give you the three big takeaways that I have. So

Michael Gilbert: 1:04

That was the idea. And the first one was without further ado, here's the chat that I had with with William Oellermann. William, you had a couple of interesting new additions to your blogs that you're putting out, right. And the first bit was, maybe in the right order. The second one was was better good than lucky, right? Better lucky than good.

William Oellermann: 1:25

The first one was on, "Are you a product centric company? And should you be?"

Michael Gilbert: 1:40

Right, right. So that was interesting, because you took a view on product centricity. Now, I remember you were talking about, that commerciality, I mean, "are you earning money directly from it", isn't a very good way of determining whether there's a product or not? And I think I agree with that. I don't know we'll explore that. But I think I agree with that. You then said okay, a better one would be to say, Okay, does it impact the customer experience at all? Right? They get there, right?

William Oellermann: 2:12

Yes.

Michael Gilbert: 2:13

And the rationale I think you gave was kiosk at a restaurant? Because if you if we bought it in from the outside, obviously, it's a product.

William Oellermann: 2:23

Right.

Michael Gilbert: 2:23

So why if we build it, is it not a product?

William Oellermann: 2:25

Correct?

Michael Gilbert: 2:27

Okay, cool. Why is it being a customer impact important?

William Oellermann: 2:34

The customer impact, I think, represents the value that you're bringing to the market. And you know, technology can be used for all sorts of things, you can use it to improve how your employees work. And it may make you more efficient, it may make you more productive, it doesn't necessarily translate to the customer. And so if we're, if we're really talking about growing your business, I think anything that impacts your customer really has that potential of affecting either positively or negatively your business. Whether it's you know, who your clients are, what kind of relationship you have with your clients. These are the things that I think come into play whenever you talk about growth, and talk about the ability to grow your company.

Michael Gilbert: 3:23

Right, right. So when I think that you're thinking about product centricity from a different angle from the one I was, and I'm not saying wrong or right, I'm just saying you're coming at it from from, from literally a different axis. So I think you're saying that product centricity, from from that perspective is about well, the things you're selling things you're dealing with, externally to the company, what I was thinking about it from, how how do you treat it in terms of a development point of view? How are you building it? How are you deciding what goes in it? What goes out of it? Was that was included in the way you were looking at it or not?

William Oellermann: 4:02

Yeah, is included, it's, I, I think it's important to think about the entire product lifecycle, and my background is in technology. And so I've historically thought much more about the development, you know, the engineering aspect of it. And what I think we've come to realize is that as technology plays such a critical part of the business, we have to get more connected to the strategy to the vision and to what the real objective of the organization is. And that's where I think this idea of product centricity is around how the business operates, as opposed to just how you manage technology even. It's really around. How do you get the right you know, buy in from stakeholders, how do you get the right alignment in the organization? How do you get the right focus and priorities? You know, because one of the things I think a lot of companies struggle with today is that technology is pervasive. It's in everything, and knowing you know, not only what to do and not what and what not to do is important, but also knowing the role it plays in your organization. I see so many companies invest so much in like an ERP migration. And at the end of the day, what's the impact to the business? I get that sometimes you have to update software, there's security concerns there, you know, things get out of date, there's compliance reasons that you have to update software. But you see companies spend millions of dollars updating technology just for the sake of technology. And to me, that's, that's a really missed opportunity, because there's so much opportunity for technology to improve your client relationship and the impact you have on your clients. That that really should take priority.

Michael Gilbert: 5:46

Right. So I think you're using this and you and I have spoken in the past about this idea. But I think you're using this as a bright line to separate what I would have called the "run the business", the "keep the lights on", from the from the "change the business" viewpoint, perhaps we could talk about infrastructure. And of course, I don't mean infrastructure in terms of boxes and wires. I mean, the set of technology, it simply takes to run the company, from the sort of technology that that actually embodies what the company delivers. Would that be an accurate way of restating it?

William Oellermann: 6:21

Yeah, absolutely. I think it's, I think, when I think what I'm trying to emphasize is a bit finer point on whether it's grow the business run the business versus bimodal, or, you know, this idea of two aspects of technology, it's really putting a finer point in saying it's not, there may be some ambiguity and what's actually, you know, impacting the business, you know, grow the business versus run the business, if we talk about what impacts your clients, I think that helps to put a finer point on, you know, what really matters and what doesn't, what could affect the bottom line.

Michael Gilbert: 6:56

So, I mean, and walk with me on this one, because I've been playing with the idea of product centricity being relevant, when there really is a market, right, and we could define a market is something that we could go and pay money for and buy from a vendor, this is kind of like you're buying a kiosk piece of software. And clearly there is a market there. And clearly, people executed a choice. But we could also have an internal market where a, an internal group could decide to invest in the development of piece of technology, or buy it or simply not, right? Not doing it is an investment choice. It's not quite the same thing as can we identify where this contributes to the customer output, because we could do the same thing into an ERP enhancement. Right? We could say, Okay, I have a choice of buying in a component from, insert ERP vendor of choice, I have the choice of building something specific to help me do that, or I have the choice simply not to do it, I'm just not going to invest in that. And that would pass the market test. But it wouldn't pass the customer impact test. Right? And where I was going with the idea was purely from a how do you decide what the right level of investment is, if you have the the idea of a market where people actually have a choice, it's not a fake choice, it's a real choice, they could spend it outside, if they want to, they could not spend it, if they want to, they could spend more, they could spend less, then you've got the idea of a feature set a value set that can be tested against a product owner who says okay, my, my market, my consumers, whether they're internal or external, are paying for this, they will pay more to get this. And I guess, maybe that's the same, same point you're making, but I'm extending the analogy of customer impact then to include internal customers.

William Oellermann: 9:08

Sure, yeah. It's certainly there. There's always the notion of internal customers. And, you know, I thought where you're going with that, and maybe maybe we're maybe you weren't, is you know, giving you know, overcoming starting inertia is always a different process from sustaining, you know, momentum. And, you know, you talk about how much should you invest in something, it's always tough when you're starting out. Because, you know, the, the whole notion of fail fast comes from the idea of, okay, learn what you need to learn, and make sure you're investing in the things that will have an impact as opposed to throwing bad money after good or good money after bad. And so it's, it's, you have to think about those things separately. And then the we get asked, I get asked by companies, how much should I spend on R&D? It's like, well, it's, it's a classic consulting answer of it depends. But getting something off the ground is always a lot more subjective than than sustaining something because thinking something where you already have some kind of value proposition, you have some kind of return, it's a little bit easier, you know, math and case to make for what's the impact of what you're investing? The the getting it off the ground is, you know, kind of, it's up to the threshold, the risk threshold, the tolerance of the organization, to figure out how much to invest. But yeah, both of those situations are about, you know, what, what is the value coming out of the company of impacting the client?

Michael Gilbert: 10:35

So it's good that you picked up on that, because if we get at what was what would I, what was I trying to get out of my definition of project centric, right? What is the problem I'm trying to solve by putting some kind of definition around it? The thing that concerns me is I see a lot of companies who take a product centric view of software development, they build product teams around things, which clearly clearly to me aren't products, right. And because they built this engine, this pipeline, they now find work to keep this pipeline going, because otherwise they're spending money on a pipeline is not doing anything. And that's bad news for everybody. Right? How does that happen? Why does it happen? And my my posit, my theory was, well, you've, you've termed it a product, but it isn't really a product, there isn't really a market driving it. And so there's no way the market can dry up on you and say, No, we're not paying for that anymore. You'll make all the enhancements you'd like because we're not not spending any more money. And that's the bit I think we're both trying to get at, you're doing it through the the true lens of customer end experience i.e., is somebody putting their hand in their pocket parting with cash, to buy the widget to buy the thing in the store, because of this technological enhancement. And that's what I'm getting at. That's the link that I see missing in people who claim that they're product centric, and have set up a product centric team structure, but don't have the internal mechanism to make it work.

William Oellermann: 12:09

Yeah, and that's really one of the dangers that I think companies fall into is it becoming product centric, brings a lens of all this technology as a product. And that's really a misstep. And, you know, I've seen it before with, you know, ERP, you know, migrations or transitions are consolidation efforts, where they set up entire engineering teams, and they set up product owners and backlogs and everything, and it's just it's a sell, it becomes a self fulfilling prophecy, which is, you know, we've seen it a lot, is that it's just a justification for their own existence. And maybe an initial idea that was really good, but it kind of, you know, took on a life of its own. And we that's definitely one of the things that I think is important to call out, and making sure that companies don't fall into that trap. Because the, you need that continuous validation that what you're doing is providing value. And I think if you focus on that customer that in value that provides the right lens for that, you know, continue retrospection of that value,

Michael Gilbert: 13:10

No, I think I think you're right on to it. And right. we're both trying to get it the same, same problem. And I think you're maybe maybe you're sidestepping it, maybe you're addressing it, I don't know. So, the problem of too many levels of indirection between you and the end customer, clearly, there are things that we invest in, in infrastructure, and I'm air quoting on a podcast, but we invest in infrastructure, and they do contribute value back, right. And when we sat there, and we did the deep analysis, we could figure out actually, we wouldn't have been able to do XYZ on the front end, if we hadn't have done this in the back end. But the further we get away from direct customer impact, the harder it is to actually keep that chain real and not made up because we let's face it, we're consultants, we're really good at justifying something if the customer wants it justified, we can find a way to justify it. But the point is, it should be justifiable quite easily, the focus you're taking is very much okay. It's easy to justify if you actually tie it directly to a customer experience. Is there a gray area in between? And can we provide a mechanism to bridge that?

William Oellermann: 14:25

Yeah, I mean, like everything, I think there's always the gray area in between, and it can become difficult. But it's it's again, it's that it's that idea. I think you've slipped into this a couple of times, you've interchanged the word project and product. And that's, I think, an important distinction. We got to draw a hard line and saying, you know, there's, there's a way that you justify IT projects. There's an ROI process that you go through and it should have a finite deliverable of finite value and you know, should be executed accordingly. The notion of product is kind of the this inert expectation of perpetual value and the opportunity to grow. Because one of the things about products is with a product mindset is that you actually never finished the product, because the product is so focused on the customer. And not even, I would say, not even the notion of the customer, but the customer problem domain you're trying to address, that's always going to be an evolving thing. And the notion is that this is an opportunity for you to evolve your solution and the value you're bringing to address that. And yeah, at some point, that may not be the case. But the assumption going in is okay, this is something we're going to invest in, over a long period of time. But we're going to continuously validate, we're doing the right thing to solve the problem to bring the value and getting that feedback that you're doing the right thing, being rewarded with, you know, growth, whether it's revenue or more customers, larger market, you know, whatever.

Michael Gilbert: 16:00

So great. Yeah, I think actually, we're, we're really hitting on the point there. And you're right, I mean, too many years of of doing it, projects, sort of slip in as a word. But there's a purpose for projects and projects have a beginning and they have an end, they have a purpose, and that purpose gets fulfilled, or they get canned right. Now, I think one of the problems is not enough projects get canned, because there's a stigma to that. And actually, I think that's a natural part of investing wisely. But put that aside for another conversation,

William Oellermann: 16:31

That'd be a different conversation.

Michael Gilbert: 16:33

Products have a lifestyle, lifestyle, a lifecycle. And that lifecycle isn't flat, right? They have different needs at the beginning, and very different needs at the end, I mean, the product can outlive its useful investment. But we now want to extract as much value out of something we've invested a lot of money in. And we'll be doing as many little tweaks as necessary to keep it alive to squeeze the juice out of something we've invested in long after it stopped growing. Because if we can make that tail stretch out, we can get a lot of return from a 'dead' product and get them using air quotes on a podcast. So how do we, and maybe that's not a problem that people have, But how do we, how do we focus on understanding where our product is, in its lifecycle? When we're talking about a digital product, or talking about something that isn't, isn't tangible isn't being sold, as we pointed out before, it doesn't have to be physically sold? If it contributes back to the customer experience?

William Oellermann: 17:41

Yeah, that's a great question. And you know, there's certainly a traditional model where you have this idea of a, you know, the beginning of life, middle of life, end of life kind of product, I actually think that's kind of antiquated thinking. And I think I kind of alluded to this before, if you think about not a product, but maybe the idea of a product line, solving a problem space, a domain of issues, then it opens you up to kind of detach yourself a bit from the product, and focus your investment and energy into maybe solving the same problem a little bit differently. And perhaps even going in a different direction. Because, again, what's what's fundamental here is you've got that connection to the customer, and you're getting feedback on, you know, what's working, what's not, but also, what's the new aspect of the problem that may need to be addressed, that your product doesn't address, and quite honestly, could never address because the way was originally designed and architected. You know, the, ideally, if you if you think about solving a problem domain and think of it as a product line, you'd start to shift your resources from one product to another, so that if your product does reach end of life, you've got another product coming along, that will displace it just from a growth and a business opportunity. But maybe, you know, solving the problem a little differently, or maybe even solving a different set of problems for the same customer.

Michael Gilbert: 19:07

Now, that's a very classic problem, actually. And something that enterprises have proven themselves not very good at, which is to set themselves up to to eat their own young as it were, eat their own old, I don't know, let's walk away from that. Because we have something which is providing lifeblood to the company, which providing the income in and to set something up that deliberately will address the same market well before that time is over. It is difficult, not just because you're investing in something that doesn't yet have a problem. But also there are powerful people in the organization whose jobs and welfare are based on the continued view of this. We've seen this internally from from companies that we've worked at. It's not easy to do. There's a question and I'm just gonna throw it out there. Is that even something a company should worry about? Companies come in companies go. And sometimes the new kid on the block arises to address a new issue. That's just the way it's supposed to go. You're supposed to take investments that you've made, and put them into new organizations that are designed to focus. And, of course, that doesn't mean that company A, can't invest in new company B, if new company. B gets off the blocks and looks like it should be doesn't, doesn't have to be a completely different set of investments. Often is for political reasons, and perhaps emotional reasons.

William Oellermann: 20:39

Yeah, sometimes we'll see. That's where acquisitions happen because they get behind. And I think that's the the key if it's going to be a mature company, who has the right perspective and mindset, will recognize early enough, that they have an opportunity to go in a little bit different direction, and start to lay the seeds for that. I think it's that companies get blindsided, you know, if they're getting, you know, what I called disrupted by another company that's solving their customers problem differently, or in a different way, where they may, you know, scramble panic, you know, what have you and then acquire, you know, maybe the company that's doing that, which then becomes a very politically challenging thing to do. But a lot of this goes back, I think, to product management and their mindset. And there's a difference between being product centric and product obsessed. And I think product obsess is the trap that, you know, people will fall into, because again, egos get in the way. And, you know, people get attached, you know, that that's been their job. That's what they've done. There's no reason they can't be I'll be a part of the change and move on to the new thing. Easier said than done. But I think what your point was that it's important for the company to separate themselves from those politics and what the other people involved if they can't make the transition, the company's got to find a way to make that work.

Michael Gilbert: 22:04

Yeah, I suppose what I'm, what I'm saying is, maybe it's okay for the company, to push the idea the product that they have, as far as they can push it, and allow the market to address that, if they push it too far, the market will tell them

William Oellermann: 22:18

Right, yeah, the market will sort that out, you know, for sure. And there, there are lots of companies and investment strategy out there of, you know, we're going to, you know, take these products, and we're going to, you know, basically cash cow them out until end of life. And there's no line of sight into what the next thing is. I would say that's more of an operating model. That's not really a strategy, and certainly isn't a product centric mindset, that's just an operating model.

Michael Gilbert: 22:45

So where you go with that idea? Right, so you've laid out the fact that there is a need to recognize the idea of product centricity, but there's a danger of taking it too far. And this has to be sort of managed and approached. But what are, what would people do with that?

William Oellermann: 23:06

Well, I think one thing is to recognize how it applies to them. And one of those is recognizing, okay, what if every company is investing a lot in technology, it's oftentimes it's thought of is IT and it's just, it's an IT spend, it is what it is, but if they are actually providing product, you know, which, again, is impacting client and client value and the potential growth of the business, I think it's important to recognize that because if they try to fund it, like they fund their IT projects, they're gonna be frustrated, and they're not really I think, maximizing the potential they have in the product. You know, conversely, if they're, you know, a little too far, the other way of treating all IT projects is product, then I think, you know, they're noticing inefficiencies and over investing in perhaps the wrong things, and again, limiting their potential to, to get the most return for what they're investing in the technology. So, you know, one thing is understanding how to fix their operating model and what it means and doesn't mean, so they can maximize that. The second thing is that making sure that organizations are, you know, building teams with people who have that perspective, because again, you're it's I've seen it, it's very difficult to get people who maybe are a traditional CIO and Director of Operations and get them to you know, run your product, they may be technology whizzes they may know everything about technology, but they're they're not the right people to be leading the product organization and help moving product forward. And so just recognizing there's a different kind of skill set different kinds of capabilities between this you know, this IT side of the house and the product side,

Michael Gilbert: 24:50

To me, you're definitely connecting with something I've been doing some thinking about, I say thinking I haven't actually necessarily got a concrete answer to yet, but I do think that there is a shift necessary in the way we're structuring IT and digital thinking. And I think some of that's coming around already, the idea of product ownership, well it's a thing out there, and it's, it is a thing beyond the traditional product view. But I don't think we've seen the divestiture, the sort of break up on the back end of the technology people, of the legacy IT group in a way that's really benefits the organization. And, like I say that that's on my list of things to think about to say, Okay, well, what would I recommend? My gut is that a lot of what we think of as being traditional IT really belongs to the COO. I think there is something that is actually inherently, should be owned by an executive role, let's call it the CIO. But it really should focus on the I, rather than the, the technology, the information, there is flow of information around an organization, which still today I don't think gets the attention that it needs. And I think somebody needs to be a custodian of the information flow. And I think the idea of technology. I guess what has been a CTO role or or evolving of that is more of an entire internal knowledge bank, internal consulting, in the capabilities that technology could present to products. So we could think about these people as being literally internal consultants, that would talk to individual digital product owners to say, Okay, this is what we could do. Right? These are some of the possibilities that XYZ technology enables, which we didn't have before. Exactly where these lines get drawn. I'm I'm not quite sure yet.

William Oellermann: 26:56

Yeah, I think you bring up an interesting point, I think that an organization really benefit from that. But the real question is, who in the organization would drive that? Because, again, it gets very political very quickly, the CIO would never want to, you know, break up his organization. And, quite frankly, a lot of the others like the COO, or, you know, the, certainly the CEO, CFO there, they don't know enough there, they're not comfortable enough with technology to know the difference, and they don't want to take it on. And, and I think that it really gets to the heart of a lot of the challenges we see with companies is that there's a lack of technical, I would say, comfort, much less knowledge with executives, and they're not, they're not sure what it should look like, and who could lead them through this kind of a change? And I think we're going to see over the next, you know, five to 10 years, I think we're gonna see some new roles start to emerge. You know, there's this idea of the CPO, Chief Product Officer has some merit say, you know, there's certainly a, I think, a redefining of the CTO role that's been out there. But I think your point about the information is spot on. I think that CISO I think kind of has some of that, but probably would need a bit more to do what you're saying. So I think there's an opportunity for more roles in the leadership level to help drive this, but organizations would really benefit from that perspective.

Michael Gilbert: 28:23

Well, that sounds like a bigger problem for another day to say, yeah, no. Wow. I, you have certainly convinced me that there is a customer experience element necessary in the productization, the recognizing of what is a product and what isn't. I think, internally, I've got some work to do to think about how do we connect that back through the grey space that I talked about, do the things that do impact customer experience, but it's not obvious to show how the connection is versus things that really don't? And, again, it's always the Devil's in the details, how do we how do we make that line? And that's, that's my take away from from from what you've said so far is that that's going to be the difficult bit.

William Oellermann: 29:17

Yeah, and I think it is, we're in that space where it's part art and part science. It's, it's not you know, when you see it, but it's a little hard to describe. But yeah, I think it does get back to what we talked about with this, this idea of a not just perpetual investment, but perpetual return on the value and that being very distinct from that point in time project that has a defined beginning and defined ending. least it should, some organizations it doesn't. But the idea is with a with a product, it is an ongoing investment in providing value and in generating revenue and growth somehow, some way back to the business.

Michael Gilbert: 29:59

I agree. As always, thank you.

William Oellermann: 30:03

Absolutely.

Michael Gilbert: 30:05

So that was a conversation I had with William earlier today. And having played it back and had time to digest it, there are three clear takeaways that I wanted to highlight at this point. The first of them came in two parts, as William talked about, it was kind of important that the product is connected to the end customer experience, that it contributes in some way to how your paying customers perceive your organization's service, product experience, whatever. It's not important that it's monetized directly, however. The second part of that, the ancillary, is that it has to be through some kind of real marketplace. By which I mean, paying customers have to have some way of either contributing or not contributing to the product based on the improvements that you're making. Otherwise, you don't have the control mechanism in place to direct investment and/or to curtail it when you should, and you risk building an expensive product engine that will just run out of control. Now, can that engine be contrived, in a sense, be an internal market? Yeah, sure, it can. But the important thing is there that the actual end users have to actually have real voting power, their opinion has to be able to steer the money. And if it doesn't, it's not really at market. The second idea was that products have lifecycles, and that investment in them isn't constant all the way through it. So when you have a very early stage product, we should be looking at rapid iterations. We've got lots of features going in, and we don't know what we're doing, we're trying things out. And I'm getting rapid response back from the marketplace to determine what should stay, what should get developed and what should get thrown out. As the product develops, as it ages, we're going to start to see that productcycle slow down. And so the feedback cycle should slow down, we should be much more deliberate about the enhancements that we're making. And eventually, we get to a maturity stage, where it's just not worth investing tremendous amount of money into the product. It's about doing just the enhancements necessary to extend this product's life, to extract all of the value, you can get back out of the investments that you've already made. The third and final point was that actually, the organizational structure that we have may not be completely suitable to a product structure. Because most of this stuff is sort of grown out of the IT organization and the legacy IT organization just isn't designed really to be able to do this very well. And we haven't really done a lot of thinking about what that organization structure should look like as an industry. And I think that that's an area I wanted to focus another full podcast on, what would the organization look like? It would be difficult to pull off, as William suggests, because there are opposing forces here, people whose responsibility you'd be taking away and other people would have to accept responsibilities for which they may or may not be comfortable picking up. But I think it's going to be important and I think it's going to make a big differentiator between the organizations that do products, digital products as a way of business and those that don't do it very well. So that brings this episode to a close and I hope it's been both educational and entertaining. Either way, head on out to

https: 33:47

//podcast.thetechnologysoundingboard.com and leave us a comment. Let us know if you liked it. Let us know if you didn't. If you have ideas or things that you would like us to focus on, please let us know and we will hope to see you next time. Thank you very much.