WEBVTT
00:00:01.078 --> 00:00:17.338
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.
00:00:27.320 --> 00:00:44.119
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.
00:00:44.000 --> 00:00:53.356
I recorded the conversation with William earlier. So let's just play that back here, sit back and listen and hear what he has
00:00:50.990 --> 00:01:04.400
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.
00:01:02.936 --> 00:01:06.829
and give you the three big takeaways that I have. So
00:01:04.790 --> 00:01:29.810
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.
00:01:25.700 --> 00:01:39.859
The first one was on, "Are you a product centric company? And should you be?"
00:01:40.170 --> 00:01:42.719
Right, right.
00:01:40.170 --> 00:02:11.310
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?
00:02:11.340 --> 00:02:12.689
Right? They get there, right?
00:02:12.719 --> 00:02:13.229
Yes.
00:02:13.650 --> 00:02:22.979
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.
00:02:23.009 --> 00:02:23.310
Right.
00:02:23.340 --> 00:02:25.650
So why if we build it, is it not a product?
00:02:25.650 --> 00:02:25.979
Correct?
00:02:27.479 --> 00:02:32.759
Okay, cool. Why is it being a customer impact important?
00:02:34.770 --> 00:03:23.069
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.
00:03:23.099 --> 00:03:25.586
Right, right.
00:03:23.099 --> 00:04:02.819
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?
00:04:02.000 --> 00:05:42.379
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.
00:05:42.709 --> 00:05:45.199
That that really should take priority.
00:05:46.350 --> 00:06:21.300
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?
00:06:21.329 --> 00:06:55.860
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.
00:06:56.379 --> 00:08:11.050
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.
00:08:06.730 --> 00:09:07.330
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.
00:09:08.049 --> 00:09:10.299
Sure, yeah.
00:09:08.049 --> 00:09:27.070
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.
00:09:23.320 --> 00:09:33.070
And, you know, you talk about how much should you invest in something, it's always tough when you're starting out.
00:09:29.679 --> 00:09:54.399
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?
00:09:54.429 --> 00:10:34.779
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?
00:10:35.139 --> 00:11:18.039
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?
00:11:12.820 --> 00:11:56.200
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.
00:11:56.200 --> 00:12:08.559
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.
00:12:09.080 --> 00:13:02.149
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.
00:12:57.740 --> 00:13:09.679
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,
00:13:10.000 --> 00:13:10.460
No, I think I think you're right on to it. And right.
00:13:12.850 --> 00:14:24.700
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?
00:14:25.169 --> 00:14:43.350
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.
00:14:40.139 --> 00:15:30.210
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.
00:15:30.299 --> 00:15:37.230
And the notion is that this is an opportunity for you to evolve your solution and the value you're bringing to address that.
00:15:37.620 --> 00:15:59.250
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.
00:16:00.139 --> 00:16:31.340
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,
00:16:31.370 --> 00:16:32.600
That'd be a different conversation.
00:16:33.559 --> 00:17:05.990
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.
00:17:02.570 --> 00:17:27.890
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?
00:17:28.220 --> 00:17:40.549
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?
00:17:41.170 --> 00:18:23.349
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.
00:18:20.559 --> 00:19:06.940
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.
00:19:07.349 --> 00:19:09.059
Now, that's a very classic problem, actually.
00:19:09.059 --> 00:19:45.269
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.
00:19:41.700 --> 00:19:52.259
But also there are powerful people in the organization whose jobs and welfare are based on the continued view of this.
00:19:49.410 --> 00:20:14.910
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.
00:20:15.210 --> 00:20:38.910
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.
00:20:39.440 --> 00:21:01.430
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.
00:21:01.579 --> 00:21:35.240
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.
00:21:35.630 --> 00:21:47.029
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.
00:21:43.940 --> 00:22:03.920
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.
00:22:04.309 --> 00:22:18.349
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
00:22:18.380 --> 00:22:44.420
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.
00:22:45.589 --> 00:22:57.859
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.
00:22:58.940 --> 00:23:04.759
And this has to be sort of managed and approached. But what are, what would people do with that?
00:23:06.490 --> 00:24:43.150
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.
00:24:40.240 --> 00:24:50.710
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,
00:24:50.000 --> 00:26:54.500
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.
00:26:49.460 --> 00:26:56.539
Exactly where these lines get drawn. I'm I'm not quite sure yet.
00:26:56.000 --> 00:27:53.240
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.
00:27:49.910 --> 00:28:22.220
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.
00:28:23.500 --> 00:28:32.799
Well, that sounds like a bigger problem for another day to say, yeah, no.
00:28:26.109 --> 00:29:16.359
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.
00:29:17.470 --> 00:29:46.930
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.
00:29:46.930 --> 00:29:59.230
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.
00:29:59.299 --> 00:30:02.990
I agree. As always, thank you.
00:30:03.390 --> 00:30:04.019
Absolutely.
00:30:05.890 --> 00:30:17.650
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.
00:30:18.500 --> 00:30:42.980
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.
00:30:38.359 --> 00:30:47.480
It's not important that it's monetized directly, however.
00:30:42.980 --> 00:31:04.609
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.
00:31:04.819 --> 00:31:25.250
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?
00:31:21.289 --> 00:31:37.279
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.
00:31:37.000 --> 00:31:44.799
The second idea was that products have lifecycles, and that investment in them isn't constant all the way through it.
00:31:45.099 --> 00:31:52.210
So when you have a very early stage product, we should be looking at rapid iterations.
00:31:47.980 --> 00:31:54.670
We've got lots of features going in, and we don't know what we're doing, we're trying things out.
00:31:54.670 --> 00:32:15.190
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.
00:32:15.430 --> 00:32:33.309
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.
00:32:33.569 --> 00:32:46.140
The third and final point was that actually, the organizational structure that we have may not be completely suitable to a product structure.
00:32:42.240 --> 00:33:00.569
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.
00:33:00.779 --> 00:33:37.500
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.
00:33:37.000 --> 00:33:47.349
So that brings this episode to a close and I hope it's been both educational and entertaining.
00:33:43.150 --> 00:33:47.349
Either way, head on out to
00:33:47.440 --> 00:34:00.910
//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.
00:00:01.078 --> 00:00:17.338
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.
00:00:27.320 --> 00:00:44.119
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.
00:00:44.000 --> 00:00:53.356
I recorded the conversation with William earlier. So let's just play that back here, sit back and listen and hear what he has
00:00:50.990 --> 00:01:04.400
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.
00:01:02.936 --> 00:01:06.829
and give you the three big takeaways that I have. So
00:01:04.790 --> 00:01:29.810
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.
00:01:25.700 --> 00:01:39.859
The first one was on, "Are you a product centric company? And should you be?"
00:01:40.170 --> 00:01:42.719
Right, right.
00:01:40.170 --> 00:02:11.310
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?
00:02:11.340 --> 00:02:12.689
Right? They get there, right?
00:02:12.719 --> 00:02:13.229
Yes.
00:02:13.650 --> 00:02:22.979
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.
00:02:23.009 --> 00:02:23.310
Right.
00:02:23.340 --> 00:02:25.650
So why if we build it, is it not a product?
00:02:25.650 --> 00:02:25.979
Correct?
00:02:27.479 --> 00:02:32.759
Okay, cool. Why is it being a customer impact important?
00:02:34.770 --> 00:03:23.069
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.
00:03:23.099 --> 00:03:25.586
Right, right.
00:03:23.099 --> 00:04:02.819
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?
00:04:02.000 --> 00:05:42.379
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.
00:05:42.709 --> 00:05:45.199
That that really should take priority.
00:05:46.350 --> 00:06:21.300
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?
00:06:21.329 --> 00:06:55.860
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.
00:06:56.379 --> 00:08:11.050
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.
00:08:06.730 --> 00:09:07.330
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.
00:09:08.049 --> 00:09:10.299
Sure, yeah.
00:09:08.049 --> 00:09:27.070
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.
00:09:23.320 --> 00:09:33.070
And, you know, you talk about how much should you invest in something, it's always tough when you're starting out.
00:09:29.679 --> 00:09:54.399
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?
00:09:54.429 --> 00:10:34.779
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?
00:10:35.139 --> 00:11:18.039
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?
00:11:12.820 --> 00:11:56.200
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.
00:11:56.200 --> 00:12:08.559
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.
00:12:09.080 --> 00:13:02.149
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.
00:12:57.740 --> 00:13:09.679
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,
00:13:10.000 --> 00:13:10.460
No, I think I think you're right on to it. And right.
00:13:12.850 --> 00:14:24.700
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?
00:14:25.169 --> 00:14:43.350
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.
00:14:40.139 --> 00:15:30.210
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.
00:15:30.299 --> 00:15:37.230
And the notion is that this is an opportunity for you to evolve your solution and the value you're bringing to address that.
00:15:37.620 --> 00:15:59.250
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.
00:16:00.139 --> 00:16:31.340
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,
00:16:31.370 --> 00:16:32.600
That'd be a different conversation.
00:16:33.559 --> 00:17:05.990
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.
00:17:02.570 --> 00:17:27.890
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?
00:17:28.220 --> 00:17:40.549
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?
00:17:41.170 --> 00:18:23.349
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.
00:18:20.559 --> 00:19:06.940
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.
00:19:07.349 --> 00:19:09.059
Now, that's a very classic problem, actually.
00:19:09.059 --> 00:19:45.269
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.
00:19:41.700 --> 00:19:52.259
But also there are powerful people in the organization whose jobs and welfare are based on the continued view of this.
00:19:49.410 --> 00:20:14.910
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.
00:20:15.210 --> 00:20:38.910
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.
00:20:39.440 --> 00:21:01.430
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.
00:21:01.579 --> 00:21:35.240
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.
00:21:35.630 --> 00:21:47.029
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.
00:21:43.940 --> 00:22:03.920
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.
00:22:04.309 --> 00:22:18.349
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
00:22:18.380 --> 00:22:44.420
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.
00:22:45.589 --> 00:22:57.859
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.
00:22:58.940 --> 00:23:04.759
And this has to be sort of managed and approached. But what are, what would people do with that?
00:23:06.490 --> 00:24:43.150
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.
00:24:40.240 --> 00:24:50.710
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,
00:24:50.000 --> 00:26:54.500
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.
00:26:49.460 --> 00:26:56.539
Exactly where these lines get drawn. I'm I'm not quite sure yet.
00:26:56.000 --> 00:27:53.240
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.
00:27:49.910 --> 00:28:22.220
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.
00:28:23.500 --> 00:28:32.799
Well, that sounds like a bigger problem for another day to say, yeah, no.
00:28:26.109 --> 00:29:16.359
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.
00:29:17.470 --> 00:29:46.930
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.
00:29:46.930 --> 00:29:59.230
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.
00:29:59.299 --> 00:30:02.990
I agree. As always, thank you.
00:30:03.390 --> 00:30:04.019
Absolutely.
00:30:05.890 --> 00:30:17.650
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.
00:30:18.500 --> 00:30:42.980
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.
00:30:38.359 --> 00:30:47.480
It's not important that it's monetized directly, however.
00:30:42.980 --> 00:31:04.609
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.
00:31:04.819 --> 00:31:25.250
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?
00:31:21.289 --> 00:31:37.279
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.
00:31:37.000 --> 00:31:44.799
The second idea was that products have lifecycles, and that investment in them isn't constant all the way through it.
00:31:45.099 --> 00:31:52.210
So when you have a very early stage product, we should be looking at rapid iterations.
00:31:47.980 --> 00:31:54.670
We've got lots of features going in, and we don't know what we're doing, we're trying things out.
00:31:54.670 --> 00:32:15.190
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.
00:32:15.430 --> 00:32:33.309
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.
00:32:33.569 --> 00:32:46.140
The third and final point was that actually, the organizational structure that we have may not be completely suitable to a product structure.
00:32:42.240 --> 00:33:00.569
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.
00:33:00.779 --> 00:33:37.500
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.
00:33:37.000 --> 00:33:47.349
So that brings this episode to a close and I hope it's been both educational and entertaining.
00:33:43.150 --> 00:33:47.349
Either way, head on out to
00:33:47.440 --> 00:34:00.910
//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.
