The new product organization: How AI changes teams, not just software

Software is becoming cheaper to build, but customer value is becoming harder to create. Henri Hämäläinen explains why organizations must evolve beyond traditional structures and embrace a new model centered around Explore, Engineer, and Evolve to fully realize AI's potential.

[Henri] (0:03 - 0:10)

If you want to get the value of AI in an organization, you have to have an inner source model into use.

[Pinja] (0:12 - 1:23)

Welcome to the DevOps Sauna, the podcast where we deep dive into the world of DevOps, platform engineering, security, and more as we explore the future of development. Join us as we dive into the heart of DevOps, one story at a time. Whether you're a seasoned practitioner or only starting your DevOps journey, we're happy to welcome you into the DevOps Sauna.

Hello and welcome back to the DevOps Sauna. In a previous conversation in this podcast, we talked about how writing code is no longer the scarcity it used to be. It is no longer the bottleneck and the product is not actually waiting for R&D or engineering as they used to, but it's actually the other way around.

And the scarcity has shifted and is actually now in creating the product value. We talked about the cost point, how software creation is changing. So what?

What is the next thing? What to do? Where is the concrete thing about this?

And how do organizations transform towards that type of organization that would support building better product value? And I'm once again joined by Eficode's Chief Product and Partner Officer, Henkka Hämäläinen. Hey, Henkka.

Welcome.

[Henri] (1:24 - 1:25)

Thank you. Happy to be here.

[Pinja] (1:25 - 1:44)

So let's pick it up from where we left off the previous time. We were talking about where the price point is now, but maybe a question to start with, Henkka. How do you think that an organization can support building this better customer value now that we are in the age of AI where software can be basically created it in seconds?

[Henri] (1:44 - 3:06)

Yeah, thanks. I think that's the super interesting part we covered a bit last time. And I think at the same time when creating new stuff is so fast and you can kind of build new features in minutes, I've seen so many super nice demos on how do you build, actually copy a feature from somewhere and just recreate it in a new software in minutes.

But then it doesn't change the fact that having a feature, it would immediately turn into revenue or profit or any kind of margin. So there's so many things in between. There's still all the go-to-market activities, building everything related to the customer.

And then there's the customers actually buying it, depending on what industry you are in, and then taking it into use and kind of realizing the value. So my long answer kind of goes back to why it's still so important to do the portfolio management and product decisions much better, that having the strategic direction and ensuring the focus goes to the right things. And I think this, we covered it a bit last time, but like the whole ideology of like, hey, you can experiment fast, but you have to commit very, very scarcely on wherever you kind of want to then put your money on going forward.

[Pinja] (3:06 - 3:37)

Yeah. We talked a bit about how it is actually even more important now to prioritize better and not build your whole product backlog. So today, our red thread of this discussion is more going to be towards what kind of organization would support this, actually taking those better decisions, making sure that we build the right things and not build everything all at once.

So then we make sure that, of course, customers are buying it and the customers are getting the value out of it. And you mentioned portfolio management and that, with those principles, they still apply, don't they?

[Henri] (3:37 - 4:57)

Yeah, definitely. Definitely does. Of course, AI changes a lot, so it's much faster to build different types of business analysis and experimentation, and we can go deeper on that one soon.

But the core principle doesn't yet change. So AI is very rarely the users. We're still selling most of the things to humans or then at least the systems used by humans.

So there's always the kind of like the adoption gap at the end. So that's the reason it's super important that you still analyze using the portfolio management methods really well, that what will be at the end the ones that actually go out to the market. Of course, portfolio management, as it used to be in the very beginning of like software development lifecycle or product development lifecycle, I think that's going to change.

So we can do the decisions or we should do the decisions like in multiple different points. And even for some of the ready-made features, we should be able to pull back stuff much more easily than before, because there's not this sunken cost syndrome that has been for so many years. So I think that will change portfolio management.

But the principles, what was your original question, will apply for sure.

[Pinja] (4:57 - 5:40)

Yeah, I believe in this as well. It is not, as you say, it is not agents, AI agents that we're building these for. It is still human beings.

We cannot, as we discussed in our previous episode, we cannot take as much as now with agentic AI we could actually build. And having that thinking of what do we have in an idea phase? What do we have in the building phase?

And what do we have in this maybe lifecycle management phase where we actually think about how to develop this further? Do we sunset things? And having this threefold portfolio management again.

And this is really very interesting to me, to be honest, because many have said that prioritization doesn't matter anymore so much. But I think that's the complete opposite here, as we have discussed.

[Henri] (5:40 - 6:56)

Yeah, exactly. Like, maybe we'd go a bit on the three portfolio model that we've been talking about for 10 years at Eficode is like having the opportunity portfolio, like analyzing the potentials that used to be the main thing, of course, because of like, there was a scarcity of resources. And then the whole like managing the project or development portfolio, there was multiple different names.

But like, that was about like, like handling the resources to ensure that we get the stuff out. And then there was the offering portfolio where there is the offering portfolio, which is about like the existing products and sun setting or boosting some of the features. So from like one sense, those are still the three things that matter.

But it will change so much like when you will be doing those things you were already yourself mentioning that like doing the product decisions and sunsetting features will become much more important because again, no one wants the Swiss Army knife type of a solution which has like 170 different features for the same thing. So simplicity is the goal and you have to become so much better on the like sunsetting stuff that doesn't really bring either customer value or money into the company.

[Pinja] (6:57 - 7:16)

There has to be some kind of strategic thinking behind this. What is it that we want to provide for our customers? What is it where we want to use these resources and how to translate this strategic intent for that organization?

I believe that that is the competitive advantage that we're going to see with organizations going forward.

[Henri] (7:16 - 8:25)

Yeah, I know I talk about strategic intent also quite often. It's a fluffy big word like strategic intent, but that's still in the core of everything. I especially think this is a good way like segue to go deeper on the organization.

But if you think about strategic intent, why it is so important is that like now when so many in the organizations are capable so quickly to develop things, the core thing that they follow the red thread, which is the strategic intent is like what are we trying to actually create? What's the value we're trying to give to the customers? So that's the reason why strategic intent becomes such an essential thing.

And it might depend a lot on the industry, on what it will look like, what the heck strategic intent then is. But it's about understanding what's the part your company actually plays in the value chain of the ecosystem, like really sticking into that value you give to the ecosystem. I think that's the important part.

[Pinja] (8:25 - 9:10)

I always envision strategic intent as like an actual red thread going through the organization because there's somebody who's writing the strategy, right? So there has to be some kind of connection and understanding. It might not.

Somebody might, for example, think about, oh, it's an item in the Atlassian system. So like a Jira ticket goes from epic to a task. But it might also be just the human being's understanding.

Like I'm doing this now. What is the goal that I'm actually contributing to? And that's the whole system of connections that we have in an organization.

And today's conversation is more about how do we ensure that the roles and different types of parts of the organization are managed so that we actually ensure that there's this understanding going forward?

[Henri] (9:10 - 9:57)

Yeah. Yeah. I think for me, like exactly like you said, it's the red thread goes somewhere in the like why of things.

It's not really a document or it's not like... Of course, there is attached most probably at some point the document, but that document doesn't really like... If there isn't a common understanding of the why, then the document doesn't matter at all.

But if people understand the why, then the document might be essential because then it will actually help everybody to like to follow and be able to even give to the like AI agents in some point of the value chain, the kind of strategic intent. But like at the end, it must be the humans who understand, like the strategic intent, what we're trying to achieve.

[Pinja] (9:58 - 10:27)

That's true. And if we... What I say next might sound very controversial before we explain this a little bit.

So when I say that in an organization that supports this, the old roles might dissolve. That doesn't mean that we don't need marketing. That doesn't mean that we don't need the business people or developers.

But I think we need to think about the roles in a wider setting. What are you responsible for in terms of this portfolio management thinking in order to be able to provide that product value?

[Henri] (10:27 - 12:32)

Yeah. Yeah, I think so. I think...

And in some sense, like I think the movement in some sense has been going on for a long time, but I think now the speed will make it like such an essential thing. And maybe it's good to explain the thinking a bit. We've been thinking that the roles will start to evolve to these three core categories, which are explore, engineer, and evolve.

And the ideology there is that the exploration is about like, you could almost think a bit similarly that we discussed product management, but then it will extend... Portfolio management is a larger topic than just that one. But exploration is about like, there used to be like Lean Startup and many other ideologies where you try to understand as much as possible from the market and customers your kind of potential to create some new value and get some money out of it.

Then the engineer is about creating long lasting solutions which scale, are secure, there's a good quality. And then evolving is about coming from the customer's perspective, like really like how do we ensure that like really good customer experience. I think we discussed this a bit like at some point, at least that as an example, like me using Spotify, we used Spotify as an example last time.

Me using Spotify, my value is different from Pinja yours. We discussed this like, because everyone in my family uses Spotify and a fun value for me is the Spotify Jams that everybody in the car, for example, my daughters, they just like jump in and use the Jams to kind of bring in their music. And then because of your family's like different age, then there's like different types of use cases for this.

[Pinja] (12:32 - 13:06)

Exactly. And this, the same feature doesn't apply to my family where I would be the only one using Spotify and having a road trip in a car with my family, this would not be the key feature for me anymore. So like getting that feedback from the customers and the users and then evaluating, of course, like, for example, the type of type of use case that is important to you, Henkka.

And how many people and users do we have who would be using this? How many would actually benefit from something else? So I think the realization of the value would be the key factor with Evolve.

[Henri] (13:06 - 14:08)

Exactly. That's what I was about to say is that it kind of works hand in hand with Explore. But like, again, like the feature creep having the 170 same like features for the same thing, then the Evolve people can actually make sure that like the right five features goes to the people.

And then it's still discoverable for the right people, the 165 different features. So there's that part of the Evolve. And it's so much about understanding the customer and really like making the most of the current set.

And maybe someone might think that the Explore and Evolve are the same. And for sure, there's something similar. But to my knowledge, it's quite different to really deeply understanding the customer use cases and usage and like modifying the usage to match the customer's real preferences.

So that's the reason I believe Evolve will always be a bit different than Explore.

[Pinja] (14:09 - 14:48)

There is a little bit of a nuanced difference why I also believe that they need to be separate. But if we do a little bit of deep dive into all these three elements here, how convenient by the way that they all started with an E, so it's easier to remember. But I really think about digging down into the Explore.

So are we doing the right things? And someone might say that based on what we've said now so far in this discussion and our previous conversation Henkka, this might actually be the one of the most crucial parts. And this role, people in this role might increase in number.

This should grow because this is where we actually think about where to go next.

[Henri] (14:48 - 16:02)

Yeah. If you ask these guys, they for sure think they are the most important for the company. Yeah, absolutely.

But the same is true for the others. So from that sense, it's a super interesting thing. I think here the debate of will all of the business people sit in the Explore and will any of the engineers sit in the Explore.

I actually feel that the best result is that when you have the business-minded and the development-minded people together on the Explore type of functions, that will actually be the best result. But will there be more of these? At least the ratio between these roles will change for sure.

That if there used to be one Explore to every 20 engineers, to every five Evolve-related operations and service management, I think those will be flattening out much more. So there will be a ratio. And of course, that differs a lot that like, hey, how do you organize around this?

But for sure, the ratio between these roles will change for sure.

[Pinja] (16:03 - 16:42)

That's true. It has not had the attention that it would have deserved previously. And that's, I guess, now one of the reasons why it is becoming a bottleneck, because we haven't done the shift yet.

But as you say, this is not just whether it's just business people and the engineer part is not just having the developers and engineering-minded people. But this is something that needs to take into consideration the customer needs. And they will be needing access to real tools and customers.

So they cannot just spar with AI and ask questions. Is this sufficient? Can I do it like this?

But they need access to real customers. They need some kind of understanding before we go beyond the prototype.

[Henri] (16:43 - 18:00)

Exactly. And I think this is why you can hopefully hear me smiling. But the thing is that with AI, it's so easy to, in this Explore, in a few days, create huge product prototypes that you could almost say that, hey, you can go to market with this one.

And that's so far from the truth still. There's so much engineering work, so much work on go-to-market and sales and everything. So the key thing there is that the Explore people actually understand to go out and even get some contracts or sales in place to prove that there's a value on these new features.

It's so easy to go and say, hey, do you like this stuff? And then everyone will say, yes, I like this. This is really good.

And then going to someone to actually buy it. So it's such a different thing. It's like you give free stuff on the streets there.

Everybody will take it. But then if you would do the same thing, like, hey, we have this new fancy drink. Do you actually pay for it?

It's such a different thing than just giving it for free. So I think this will be a hard thing for many Explore people.

[Pinja] (18:00 - 18:28)

It is like actually being in a demo session and seeing a prototype. I would say, yes, I like the way this looks many, many times. And at the same time, actually going beyond that and signing the contract and giving out the money, that is still the scarcity really there from the buyer's side.

So it doesn't make sense to ship out 117 features when I would only like to pay for three max.

[Henri] (18:28 - 18:58)

Yeah, exactly. Of course, if you're in a SaaS world where you can just bring in new features without a user, that's a bit easier. But in some sense, there is more of a risk that it becomes totally obsolete to use.

I think there's examples of many SaaS services that have become useless after they've been bringing in new features after another. So then the original value was just totally lost.

[Pinja] (18:58 - 19:40)

Yeah, there are useless features there. The maintenance of those features becomes completely impossible. And that's one of the reasons why we need that prioritization.

But if we move to the engineering part, I don't think it's fair to say that this part of the organization is becoming redundant, even though we have AI, age-ending AI, we have AI systems, we have AI writing the code. But as I said before, we need to build something that is sustainable, that is long-lasting. And without the understanding of the strategic intent, we're just, again, going in the wrong direction.

It has been historically the place where we have put the most of the investment, but there will still be some constraints here.

[Henri] (19:40 - 21:18)

Yeah, for sure. Maybe it's good to almost state in the beginning that it will take years for this to radically change. So there's not like, hey, next year we will suddenly have a totally different type of engineering function.

But if you think about a bit longer term, like five to 10 years, it will definitely change radically. The really difficult part is that how do you... We talked about the strategic intent.

There's almost like a similar engineering intent or product intent or whatever we end up calling it. But there's a way to solve the problem so that it's scalable, secure, and follows all of these principles. And it's also cost effective.

Like if you just solve everything so that you give it to AI to actually solve it, it's never going to be cost effective compared to others because the token consumption and energy consumption at the end. So there's still a lot of engineering which can be done and which should be done with AI for sure. So it's a super difficult topic to estimate or guess exactly how it will go.

But for sure, there will always be a need to engineer things properly. It will never go away. There needs to be architectural decisions in any case in the future.

It's just the visioning on how it will go. It will be quite different for different industries, I would guess.

[Pinja] (21:18 - 21:49)

It would be a different size of organizations regardless. So there are so many factors actually playing here. Let's go into the last E, so Evolve.

We talked about this already a bit because there are similarities towards Explore and they definitely need to work together. And all three of them, not just Explore and Evolve, but the trio is there for a reason. So we talked about the different value that we're getting from the same product and features, but this has to be a combination of many, many things to make this work better for the customers.

[Henri] (21:50 - 24:23)

Yeah, it is. If we think about almost all the current functions that would go to Evolve, it's the operations, UX, service management, customer support, all of these, those are the closest to customer. Of course, again, depending on the industry, it can go all the way to the storefront and having people serving the customer, like customer service agents and stuff like that or customer support overall.

Like the key thing really is there that how do we, from the, now again, I'm going to go quite meta level, sorry for that. But if you think about the product's potential that has been created on the Explore and Engineer, that's what we actually are doing. We are creating a potential for customer value.

So the Evolve is the one who then has to realize that the potential is actually realizing for the customer. Then for sure, there's sales and marketing, which kind of helps it to get that sold. But the Evolve is really the realization of the product potential that has been created in the Explore and Engineer.

And again, this is maybe the most hard to state exactly due to, I think this will differ so much about the industry and what you are doing. If you are doing like, let's take, you are creating a software that handles transactions between banks. Of course, Evolve has nothing to do with people exactly, but it's about understanding the ecosystem and all of the different agents and APIs there.

And then it's quite a different Evolve organization. It's all about the operations and speed and like your documentation. But then if you are in a more customer facing type of software, then the Evolve is really about how do you actually like to get the five features of 160 actually into use to that customer who really needs it.

If that's the customer who can use seven features out of 160 rather than five, then it realizes that. So it really depends a lot on what you're doing. But I still believe that the ideology is really good to understand that like the Evolve type of role is essential in the AI world also.

[Pinja] (24:24 - 24:41)

So now we have basically the new roles in place. We have the three new parts of the organization. If we talk about the practice a little bit, what does it mean for an organization?

Do we want the Explorer types to work with Engineering types? I know Henkka that you're a big lover of silos, aren't you?

[Henri] (24:42 - 24:43)

Exactly. Yeah, yeah, yeah.

[Pinja] (24:44 - 24:45)

How would it work here?

[Henri] (24:45 - 28:14)

The more silos, the better. So don't take that as like a quote there. No, this is not a quote.

But yeah, it's essential that these work together. Of course, like we talked about the strategic intent, which of course should kind of ensure different roles are working towards the same direction. But I think that the key goal really here is on how the different parts of organizations can keep up with the speed of change.

And I'll maybe start also stating that the tooling is one of the things that like the key thing is that there needs to be still a way to like follow the progress of everything. So like whatever the tool will be like today, it's a lot of the Atlassian or Azure DevOps type of a world where you're going to actually follow up like what's happening all the way from portfolio management to production to service management. But I think the key thing in any case is like one of the key things is that there's transparency on the items, work items, even agents and AI would be doing those ones.

So I think that's one of the key things. But then the second, the more human related thing, it's about how do you then organize the teams around this? Like, will you actually have finally the feature teams we've been talking about for 20 years in the Agile world?

Like we've been always talking that you should have the teams that can actually deliver value, which would mean that the business people, the technical people actually sit together in the same one, which kind of goes back to like, okay, so do you mean that the Explorer and Engineer and Evolve guys are in the same team? I'm not sure. It might be that in some cases they are, and in other cases you still divide.

So I'm sorry for such a vague answer, but it depends. But what we can say for sure is that it's essential to have the quality gates and like the DevOps practices and the direction setting and the UX guidelines and all of what's guiding the development to go in the right direction. I think that's gonna be even more important than the organizational model.

The organizational model, sorry for a long answer again, but like the organizational model depends a lot like what you are actually doing and what's your starting point. If your organizational architecture has built for this like Spotify model that actually there are already like possibility to deliver parts of the product value separately, then it might actually be very meaningful to have all of those isolated in a different team and then you just need less frequent syncs. But then if you are currently having like a big monolith software that you release like every month or every two months, then it might be that you actually need like a weekly or even more often the checkpoints to ensure that you are all working to the same direction.

[Pinja] (28:15 - 28:21)

And I guess that's one of the things ensuring, or one way to ensure that the strategic intent is being kept, right?

[Henri] (28:22 - 29:16)

Yes, exactly. That's the point. And also like not only the strategic intent, but like that the whole thing just doesn't break, the customer experience doesn't break like you actually create features.

So it's part of the strategic intent, but I think this is more practical, but like, hey, that no, not every team actually creates their own systems and stuff like that. There might be easily that, hey, like we just create our own account handling because it's so, so easy. And then we end up having like seven different account handlings, which of course then breaks the customer experience at the end.

So there's so many things with the speed that it creates the need to actually sync much more often that it will be a difficult thing. But I think the starting point will matter a lot on what you should actually take into use.

[Pinja] (29:16 - 29:35)

Yeah. That is, I think the principle of Conway's law that you're always shipping your organizational model still applies here. Even when thinking about that, you have your explorer, your engineer, and your evolve.

But at the same time, having those in sync would matter more in this case as well.

[Henri] (29:36 - 30:45)

Because the speed overall will be so enormously, enormously faster, right? Kind of almost like how far we think, like do we think like five years ahead or 15 years ahead, like in 15 years, I would imagine most of the organizations will actually have very isolated teams that can deliver value almost on their own. Then there will be for sure, like still organizations that because of their ecosystem, it's actually best to have explorer, engineer, and evolve as a separate teams that like really like ensure the explorer guys are like understanding the market and doing, and the engineers are the one who make sure that it will be like a very feasible solutions.

And then there will be the evolution, which is closer to the current one, like how organizations work. But I think it depends a lot. The SaaS world for sure will go to this very isolated feature team type of thing where the strategic intent and syncing up on the architectural intent is going to be such a key thing.

[Pinja] (30:45 - 30:57)

And I think this is very crucial now that we start to evolve towards this direction, but also that we have the processes evolving towards this direction as well and the tools while we have everything changing.

[Henri] (30:58 - 32:19)

We didn't even talk about it yet, but like the whole inner source model, I've been shouting about it for two years now is that if you want to get the value of AI in an organization, you have to have an inner source model in use. And this is like, it's a surprise how big of a surprise it still is for many. Like if you create now going back to the silo, if you've created that your teams are siloed to deliver a small piece of software, you will never really get out of, you will get faster in a team for sure.

You will get super fast in one team delivering a piece of software to do your whole. But if you don't actually have an inner source and possibility to deliver to a wider part of the stack, then you will be always limited by your like silo and permissions to deliver. This is like, it's such an essential thing that it has to be there quite early when you start getting the value.

It doesn't yet solve the problems, but it's like the number one obstacle. If you only are limited by the like delivering to a certain component that you like, it's no matter how many agents and AI you have in that team, it's never going to be a fast output of the whole at the end.

[Pinja] (32:19 - 32:31)

I agree. And it's funny how this has been, open source has been a big thing, as I say, for multiple years now. And we still get this surprise face from many organizations like, wait, what should I be doing?

[Henri] (32:31 - 32:32)

Exactly.

[Pinja] (32:32 - 32:36)

And why should I be doing that? They're aware of it, but it is not considered as an essential.

[Henri] (32:37 - 33:33)

Yeah, exactly. Maybe that's like going back to our AI maturity framework, like, when you are in phase one, you're just taking the assistance into use. You don't really think about the next phases of life, how do you actually transform the organization?

But like, you will never get to this like real benefits of the AI native or whatever we call it. But AI empowered organizations, if you don't break the barriers of delivery, and at the same time have this really good like DevOps quality gates in place. So those are such essential things that I would encourage every organization to have so much emphasis on starting to build these practices, because otherwise you will be so much limited by your organization, but also by your DevOps practices at the end.

[Pinja] (33:33 - 33:59)

Yeah. And like we discussed, the real value here does not come just from the tools and how much money you're spending on your tokens, which is the new currency of the world. But there needs to be the alignments in how you work based on what is your organizational model?

What is your strategy? Again, your geographical location, your industry, all these need to be taken into consideration, but also considering the customer value. So having that everything.

[Henri] (33:59 - 34:06)

Exactly. And that's, you know me, I could kind of just preach about this one like so long, but I think like we made the point.

[Pinja] (34:07 - 34:13)

I think we made the point. And I think on that note, I think we're going to end our conversation today. Thank you Henkka for joining me again.

[Henri] (34:13 - 34:15)

Yeah. Thanks a lot. Thanks.

It was fun.

[Pinja] (34:16 - 34:26)

And thank you everybody for joining us. And we'll see you in the sauna next time. We'll now tell you a little bit about who we are.

[Henri] (34:26 - 34:31)

Hey, I'm Henri Hämäläinen, Chief Product and Partner Officer at Eficode.

[Pinja] (34:31 - 34:47)

I'm Pinja Kujala. I specialize in agile and portfolio management topics at Eficode. Thanks for tuning in.

We'll catch you next time. And remember, if you like what you hear, please like, rate and subscribe on your favorite podcast platform. It means the world to us.