Your platform is a product – act like it!

Internal developer platforms are no longer just technical tooling. In this episode, Pinja and Stefan explore why your internal developer platform should be treated like a customer-facing product.

They discuss user-centric platform design, adoption and shadow platforms, lifecycle management, roadmapping, and continuous improvement. From developer experience and security to cost visibility and business alignment, this episode breaks down what it really means to build and run an IDP that people actually want to use.

If you’re building a platform, build it like you mean it.

[Pinja] (0:03 - 0:21)

Using your user groups to build this life cycle and a roadmap for these features is extremely crucial. 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.

[Stefan] (0:22 - 0:31)

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.

[Pinja] (0:37 - 0:47)

Hello, everyone, and welcome back to another episode of the DevOps Sauna. And I'm once again joined by my co-host, Stefan. Hey, Stefan, how are you doing?

[Stefan] (0:47 - 0:57)

Hey, Pinja, all good here. I had a small hint of snow today, so it could be a good weekend we're turning into here. Who knows?

We might get snow again in Denmark.

[Pinja] (0:58 - 1:01)

I've never seen snow in Denmark before. That would be a very interesting experience.

[Stefan] (1:01 - 1:07)

I could see like 10 grains out of the window. That's how much is left. That's just like the perfect winter in Denmark.

[Pinja] (1:09 - 1:23)

Yeah, we have proper snow here in Helsinki, Finland. It's been cold-ish, but not too cold. So let's see.

We are officially over halfway through the winter months now. Some might think it's good, some might not like it so much, but that is a fact.

[Stefan] (1:23 - 1:28)

You're past the winter solstice. You're getting more and more light. Well, you don't really get light in Finland, I guess.

[Pinja] (1:28 - 1:34)

No, but it's not so dark anymore when I leave the office in the afternoon. So that's different. Let me put it that way.

[Stefan] (1:34 - 1:35)

It's going in the right direction.

[Pinja] (1:36 - 2:05)

It is. In a previous episode, Stefan and I recapped some of the trends that we at Eficode have gathered for the year 2026 in the software development lifecycle. And today we want to do a deep dive in one of them.

One of the trends was that the internal developer platform should be treated in a similar way as a customer-facing product. And why did we want to go with this one? Obviously, because this now combines the absolute expertise areas of Stefan and I, product management and platform engineering.

[Stefan] (2:06 - 2:12)

And even better, when you're done listening to this, you can go back and listen to the cookies and coffee principle. That's like, what, 10 episodes back or so?

[Pinja] (2:13 - 2:52)

I was thinking when we were prepping for this, and I was thinking about that episode. So building it and they will come might not be the best way of approaching this topic either. But in this episode, we want to do a deep dive on why it is so important or maybe crucial in this day and age that if you're building an internal developer platform that you treat it the same way as you would a customer-facing product.

And I guess the one key thing to start with is that there are now new demands from the software development lifecycle, SDLC, because it has become more autonomous. So the stakes are even higher for IDPs than before.

[Stefan] (2:52 - 3:43)

Yeah, and we have the flip side that is more rigid, like all of these legislations and everything that comes from the side. It seems like we have a lot of that coming in. So you need to be able to incorporate that as well.

So we have the more autonomous side and we have the more rigid legal side that comes in. So we need to make sure we can add that as a feature at scale or incorporate it into whatever we're doing. And if every team is building their own platform, so to say, then they all have to build this.

So we need to be quite clever here and make sure that we actually build something that benefits the company. And to be honest, every time I talk about platform as a product, I go back to the time where I was a CTO with a smaller company because we were a SaaS company. We needed to build the best product that people wanted.

If you don't have a good product, well, then you don't have any customers. All of a sudden, you have no salary and you're out. So treat your platform as a good SaaS product.

[Pinja] (3:43 - 4:14)

And if we really think of bringing the cookies and coffee and they will come, build a platform, they will come. But if you have a better user experience for your IDP, it might lead up to a higher adoption rate. It just might.

And nobody wants to throw money down the drain when you're building something that nobody uses. But it's also for the data to end decision making for management. Are we going in the right direction comparing profit and loss?

And what are the shared costs of an IDP?

[Stefan] (4:14 - 5:08)

Do the individual product teams even know the profit and loss of their solutions? Does it make sense you burn $500,000 a year on this single service? You might only make $10,000 out of it.

Well, it might be supporting 10 different ones. Well, you need this full-scale picture of everything. Because as a platform engineer, honestly, I don't care what you burn off on your solution.

You need to tell me, all right, is there a better way we can do this that isn't so costly? Because we're sort of at an edge where it's a bit too expensive, but it's a good feature. We need to support the rest of our product to our end users.

It's tough. And I actually love that you said it might give a higher adoption rate, because it's not guaranteed. You might have a really old culture in your company.

If you have a really old culture in your company and nobody really cares about this platform building or they tried some shared hosting or something like that before and like, no, no, no, it failed last time. We don't want to do that.

[Pinja] (5:08 - 5:40)

No. The evidence doesn't support actually putting more money on it because with an IDP, when it works well and we get people to use it and we get a continuous improvement on it, we want to see developer productivity. More importantly, we want to see developer happiness.

That is, I guess, Atlassian is really big into this developer happiness as a term, but there's both the software and infrastructure and platform developers that we need to think about and we cannot treat them individually, or let me put it this way, we cannot treat them separately in this matter.

[Stefan] (5:41 - 6:10)

And there was this saying like roaming around at some time, like a platform takes the pain. Well, they do take some pain, but it should be in a balance. It's not like they're trying to feel the worst in the world and having to solve all the problems in the world.

They need a good setting as well. If you keep building unhappy platform engineers, well, that unhappiness will sort of bleed into everything else. And all of a sudden, everybody is unhappy.

They might not deliver the things you need and well, then you get annoyed and then everything just runs downhill. So you get a big snowball effect.

[Pinja] (6:11 - 6:36)

And let's do a deep dive now. So when we say treat your platform as you would a customer-centric product or customer-facing product. So there are four key elements we want to discuss today in this episode.

One of them being user centricity. We are going to talk about lifecycle management of the platform, continuous improvement, and aligning with business objectives. You might think, well, aren't you now talking about a software development project?

[Stefan] (6:37 - 6:38)

Well, you are.

[Pinja] (6:38 - 6:51)

You might be. You might be right, actually. But there are so many similarities here.

So let's start with the user centricity. So who are the stakeholders? I want to see the users and customers here.

Who do you build it for?

[Stefan] (6:51 - 10:15)

Oh, that's actually fun. I had a colleague in the office saying at some point, platform engineering is applying good software practices into infrastructure. And I actually think that is right.

And if you have a good setting for that, it will help you. But that also means we have higher requirements for those building it. But let's go back to the users.

We want to talk about those. Of course, we have these software developers. All software developers should be in this.

I was about to say, has to be in this. They don't. If we have a high adoption rate, we're happy.

Sometimes we'll say, if you get 80 percent, it's good. I know all of the directors and people that are sitting here sponsoring the platform, they will probably be unhappy when I say 80 percent is a good target. But of course, we have the software developers.

They need CI/CD. They need code repositories. They need hosting.

But they're not alone. They produce some things, but some people need an insight into what is actually being produced here. And that would be the product team, product managers.

We can even have the engineering managers as well. I think all platforms should be open to everyone to some degree. When we talk about the platform, it can be everything all the way out to production.

You shouldn't have access to that. But getting insight into it could be a portal that gives good insight. We need to make sure we have the full product team on board.

We need to make sure we have security engineers in there because they need to get an overview of what the landscape is looking at at the moment. Do we have like a thousand vulnerabilities in critical state? Oh dear God, we're busy.

It's not like to beat someone on the head, but you need to be aware of how your security setup is. What's the risk state of our complete solution at the moment? Because security will be under pressure if it could be the CISO coming in like, all right, give me a full report on how the landscape is at the moment.

We don't know. We need to go out to all of the teams, ask for reports or whatever. Make sure you integrate those in.

And even better, I already mentioned the CISO. What about giving a login to your portal, making sure that he can actually see what's the state of the union? Are we good?

Red, green, blue, or probably red, yellow, green on vulnerability and operational state. Giving these traffic lights as soon as we go into the management support into the portal, because you have all of the data available. Why not aggregate it in multiple levels?

The team needs one set of data. The department might need the second one. Your CFO might need an insight into what's the cost of all of this and who's actually the most expensive ones.

Then there's probably going to be an old school fin up guy showing up like, you need to save some money on your solution. Well, let's have a chat about what we actually make on this solution, because we need to push the cultural state of our organization as well. We need to be bold when we build platforms.

Last but not least, we need some really important people to support us in building a platform, and that's the architects and principal engineers. They're talking to all of the teams. They know how the teams are working or should be working, so they can actually promote desired practices.

We can assist them. If we should shift away from running workloads on singular servers, like let's switch to containers, running Kubernetes, it might be their decision. We need to have a collaborative effort where we can support that and make sure we can do easy adoptions from running single workloads and servers into containers and hosting them on Kubernetes.

So many things, so many stakeholders here.

[Pinja] (10:15 - 10:48)

So many stakeholders, and as our dear listeners, you might understand, of course, and agree with us that this is not a very uniform group. None of these groups have the same needs. They don't have the same jobs to be done.

They cannot be treated as a uniform group at all. So there are some risks if we treat the users and the personas as a single group. One of them, obviously, we talked about already, the adoption rate.

If it's too generic, we cannot serve anybody. If it's not treating the specific stakeholder groups that we want to tackle, nobody's going to come and use it.

[Stefan] (10:49 - 11:22)

Or it could be as bad as we're trying to make sure we build this feature that fits everyone, so that means our platform will be done in two years. Well, if you start building a product that is done in two years, how good is that product going to be? It's going to be horrible.

It's going to be over-engineered with thousands of toggles and putting all of the complexity right at the user. Like, yes, you can do X, Y, and Z. You can swap this out, and you can do this.

Yes, but I just want to host a simple front-end application here. I don't need all of the toggles for controlling networks and backup policies and everything. So take away the complexity.

[Pinja] (11:23 - 11:26)

And that increases the risk of having shadow platforms.

[Stefan] (11:26 - 11:26)

Yes.

[Pinja] (11:26 - 11:51)

Because if the needs are not met, we're over-engineering this platform because we didn't listen and we didn't prioritize, to which we're going to get a little bit later in this episode today. We're going to risk having different kinds of shadow platforms being kept in different parts of the organization, and we lack that one single point of view, that one single truth of data that we're also after with IDP.

[Stefan] (11:51 - 12:27)

And shadow platforms are probably the worst, especially if we have PII data. They might not be running under the policies we have for storing personal data. We might have internal policies for lock retention, might not be within that.

Like, I used to work at a place where we had, was it 30 days of locks? Pretty sure if you run your shadow platform, like, yeah, we want to keep our locks longer because there might be some value in those locks. And they will save them for like two or three years, and they're probably going to be full of PII data.

That would just be a wreck if we get an audit. Nobody likes shadow platforms.

[Pinja] (12:28 - 12:47)

We all like shadow IT. We don't want shadow platforms. It's very important to understand if there are any groups and functionalities that we do not support at the moment.

But it also comes down to, have we roadmapped this? What is the purpose of this platform? But to do the analysis to begin with.

[Stefan] (12:47 - 12:53)

We need to figure out who's the most important ones we support first. You need to figure out the personas. Yes.

[Pinja] (12:54 - 13:23)

That's where we get into the product management practices. So what are the needs of different user personas? I mentioned the jobs to be done.

Is my job to be done? I want to be able to do stuff on a Friday night. I want to be able to give you this.

I want to have this data available. So shutting those down is actually very important to understand when we're thinking about these different user needs and the user personas, because this is all about having the setup to handle the platform as a product.

[Stefan] (13:24 - 13:41)

Yeah. Sometimes you look at all of your development teams and you create something perfect for them, but you forget the people who call them site reliability engineers or whatever you call them. You totally forget those.

And all of a sudden they have no insights into what's running. So it's like, yes, I got an alert. Now what?

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

Exactly.

[Stefan] (13:42 - 14:19)

And of course, it's not a good alert because it's not actionable. So you just get a random alert. Some lock threshold was exceeded somewhere like, yep.

So what? Yeah. So all of these details and personas, and you will definitely have more than one persona for the first run.

Yes, it's nice to have developers on, have something running. Yes, but security operations, SREs, you don't have to fulfill the full needs of all of them. Just make sure you have a minimum, coming back to the minimal viable product or thinnest viable platform or whatever we like to slap onto it.

Difference in the different companies.

[Pinja] (14:20 - 14:34)

And one way to look at it is that, is the platform mandated or chosen? Maybe we're not getting too much into this today because we already talked about it when we talked about cookies and coffee in a previous episode, but having the ambassadors to speak in the favor of the platform itself.

[Stefan] (14:35 - 14:48)

It is super important to show that the platform is good. The best way you can do that is by having good ambassadors. And well, we all know if stuff is mandated, you're not likely to have good ambassadors.

It's more like evangelists all of a sudden.

[Pinja] (14:49 - 15:26)

And one way to use the ambassadors is in lifecycle management. Let's jump into that next part of this discussion today. So treating it as a product that you're actually developing for your external customers.

If we look at a SaaS product, there are always those various stages of development. So you plan, you do the actual development, you have the launch, and of course the maintenance. And maybe at some point you might have to sunset something, or the platform might evolve into something else.

And using your user groups, your ambassadors to build this lifecycle and a roadmap for these features is extremely crucial.

[Stefan] (15:26 - 15:37)

And we actually forgot one stage in that. There might be a beta phase where we let some of our users in and be the guinea pigs and test stuff out. Just need to make sure we have a big, big beta label on it.

[Pinja] (15:38 - 15:38)

That's true.

[Stefan] (15:38 - 15:47)

But get early feedback. Again, it's like software development. Early feedback is good.

Early feedback is a way cheaper way of solving issues.

[Pinja] (15:48 - 16:12)

And roadmapping the features. Basically, you can do it based on the user personas, the features that they're using, but also defining what it is that we think that good looks like. What is the target state?

So in a similar way as you're doing a customer-facing product, who is this for? What is the problem we're trying to solve for the customer with this or the user in this case? And what do we think is good quality in this situation?

[Stefan] (16:12 - 17:06)

And what is included? Let's say we have a database capability in our platform. I ordered a database.

Yes. How's the backup routine? How's the access?

Is there something I should know regarding collation for different languages and character sets? What is the default? How can I affect it?

If I can affect it, just make sure it's well-defined. If you don't have a well-defined capability set, then you're going into this magic. I don't like buying stuff on the internet in shops that don't really give me the specs.

It's not that I start by looking at the specs. I'm not that detail-oriented, but just want to say, all right, so I see all of this. If I'm buying a piece of hardware from a network at home, yes, it's a piece of hardware for my network.

Yes, but how many cables can I put into it? What's the power requirements? Is the power supply included?

I need to know what's included in the box.

[Pinja] (17:07 - 17:25)

With the roadmap, we're also able to prioritize the pain points, what to solve next. One really crucial thing about roadmapping is that it is a living, breathing creature that we need to pay attention to. We cannot set it in stone and then, oh, let's forget about it for the next year while we do this development.

[Stefan] (17:26 - 18:13)

You need to be flexible and have maybe not short, short iterations. It doesn't have to be weekly. It can be bi-weekly, monthly, or whatever you like, but just make sure you don't set a plan in stone for the next two years and say, all right, this is what we're doing for the next two years.

Of course, you're going to have a vision and you steer towards that, but all of a sudden, something comes in from the side. How many people have foreseen that all of a sudden we would be running AI workloads all over the place? Everybody wants to build MCP integrations, both to internal tools and everything.

We're not really used to having internal tools that connect in. How do we do that all of a sudden? When you do migrations into your perfect new platform, all of a sudden, you forgot something that needs to be interconnected with something different and you need to figure that out as well.

There will always be roadblocks ahead of you or a new path to pave.

[Pinja] (18:14 - 18:57)

For that, you need a group of people in your organization to prioritize this. What is the most important thing next? Is it MCP or is it something that, oh, by the way, we forgot about one group of users for which we need a very crucial functionality?

Again, tying this into everybody building their own SaaS product towards the customers is that the value promises and the value hypothesis. We want to have the promises, of course. Do we want a faster flow?

Do we want to make safer changes? The key functionality, of course, when we talk about IDPs is the developer experience and lowering the cognitive load, but how do we build testable assumptions around this is something for the organization to think about.

[Stefan] (18:57 - 20:16)

Again, it comes back to how we need to make sure we have the right team running this platform as a product. If we just swap our old labels from our operationalist department with the manager, well, all of a sudden, they're platform engineers and you have a platform manager. Yes.

Do you know how to run a product? Do you know how to do product research? Do you know how to do market research?

We need to make sure we can actually have this defined and say, all right, if we build this feature, we will actually make X, Y, and Z better or we'll mix X, Y, and Z faster. You need to have something you can measure. Start by saying, if we build this capability, it will change our build times from five minutes to two minutes.

All right, let's look at it. Is it worth lowering the build time from five to two minutes? Maybe it is.

Maybe it's not in your business. There's a good friend of mine that I've had a lot of platform chats with. They lowered the onboarding time with a minute and everybody was like, why would you lower your onboarding time with a minute?

That sounds silly compared to everything else. Well, you have 10,000 developers. It actually adds up because it was not like onboarding on your first day on the job.

It was onboarding into new projects, creating new projects, going into other projects. That whole journey of switching products and coming into that flow, just reducing that with a minute for 10,000 developers, that's a lot, but it might not be the highest priority.

[Pinja] (20:17 - 20:50)

No, but that's the thing. How do you prioritize that? Is it in your own business priorities to move into a faster flow?

Is it something that has to be prioritized because of something else? What is actually valuing these ones? Maybe the last thing about lifecycle management here is to guide the development as you would if you were building a customer-facing product.

So prototyping, but as said, if you're doing beta testing and prototyping, you need to be extremely careful in mentioning that, by the way, this is a prototype that we're doing at the moment.

[Stefan] (20:51 - 21:55)

Find some good friends, make sure they know that this is a prototype. I had some old colleagues at some point, they said like, oh, every prototype ends up in production, which is sort of sad because that means you have no trust in the management giving you the time to finalize that feature, like finalize in quotes here, because it's never going to be final. But make sure it's at the minimum required level, like you have good observability, you can actually fit it in, it's based on open standards, so you can easily swap it out later.

If you have a good modular design, you can swap out your login, your lock storage and put something new in. It's just going to adopt everything because it's open standards and everybody's happy. Good open standards for building your platform is really, really important when you're sitting on the technical side.

It sounds good to swap from one lock provider to another one. It's easy, it's just locks. Yeah, then the technicality comes to the surface and all of a sudden you figure out like, oh, we're running this custom lock agent on all of our servers.

Oh, so we have to switch all of that out all of a sudden.

[Pinja] (21:56 - 22:25)

And continuing to the next phase, if we think about what is in the maintenance part of a platform or now let's first think about the SaaS product, of course, we need to figure out how to continuously improve it. And as in the software business, feedback loops, people. How do we get the data?

How do we use it? How do we improve it? And it needs to feed back to what we just discussed, so the roadmap and the prioritization.

[Stefan] (22:25 - 23:46)

Like if you adopt different tools that people are using for feature toggling, for example, they actually include ways of tracking what is being used afterwards. So if you build a good feature and you enable it, you might actually be able to see how many people use it in that piece of software. So you don't have to build up this whole statistics department that tracks everything in your platform.

You might pay something for the feature toggling software, but it might be really valuable for using. So you just get all of these insights. Making sure you integrate with all of the tools you have, because most of the tools do actually have insights.

Not all the vendors are equally good. Some would like to force you to go into their tool to see the details, but some of them will actually allow it for external aggregation or pivoting. The more open a tool is, the better it is because you can start looking across different tools and say, all right, we can see here that people are using GitHub.

All right, perfect. How slow are the pull requests? How fast are the pull requests combined with how slow fast our build systems are?

Is there something that might correlate here? So getting insights into all of this data and making sure we surface it and we let people pivot it and have fun with it. Sometimes it's good to take a Friday afternoon and look at some data and say, have you looked at this before?

What's hiding?

[Pinja] (23:46 - 24:17)

Exactly. So paying attention to the data and feeding it back, but also talking again to your user groups. So actively collecting the feedback.

You might have your ambassadors and ask, how do you see this at the moment? Is this feature actually providing you the value that we wanted it to bring? So back to the hypothesis statements of the value, validating those with the data, with the feedback, because the platform will expire pretty fast if we don't improve it on a continuous basis.

[Stefan] (24:17 - 24:33)

There's nothing like people saying like, oh, we already built our platform. We haven't touched it for years. Yeah, we're done.

All right. Did we lay off all of the employees that built it or do we just have two guys left to operate it? In that case, like if it only requires two people to operate, what are the last eight guys doing?

[Pinja] (24:34 - 24:36)

They might be building their own shadow platform.

[Stefan] (24:36 - 24:38)

Oh, it could be. They're building a platform for the platform.

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

Of course.

[Stefan] (24:40 - 25:30)

Like you need to figure out what you want to evolve with it because there's going to be new versions of everything. There's going to be new feature sets coming all of the time. Developers will ask for new features as well.

There might be sort of like an emerging standard or a new framework that doesn't really fit in well. Like if we run frontends, we'll see this like a new frontend framework every week. It's not as bad as it used to be, but there are still new frameworks and different requirements, different ways they render stuff, different ways they map everything out.

And does that fit in with the infrastructure you have today? What do you need? Do you need a version two of your frontend hosted application or what do you need?

Being open and listening to the developers and seeing what they actually like and just reaching out to your architects and principal engineers and seeing if it runs towards their overall mission and vision.

[Pinja] (25:32 - 25:53)

It's like, again, running it like you would your product that you're offering to your customers. And with that, aligning to their business goals. Somebody once said, well, we're improving the developer experience, so the business benefits will follow.

Kind of. It sounds good, but it's oversimplifying the thing.

[Stefan] (25:53 - 27:43)

It's a bit too fluffy because how do you measure your business benefits and how do you measure your developer experience? Just measuring developer experience, that's three years of research and several PhDs in a room. We talked to Justin Reock about future software and the time he spends on doing research into developer experience and developer happiness, it's insane.

There's so much detail that goes into it. And even he says it's hard to measure because you have these different organizations, different ways of working, different people that have their own ways of what is a good developer experience. And yes, your developers might be happy.

Well, I can be happy and make horrible software that doesn't really support the business well. It's easy always to invert the statements and say, well, I can easily be happy and do horrible stuff, or I can feel very horrible and do really good stuff as well. We need to figure out what we actually want as business goals?

Is it faster experimentation? All right. If we can experiment today, how do we build up a feature for that?

Is it feature toggling? Is it user tracking? Is it super custom feature tackling with A/B testing or what do we want?

That takes a lot of time. And as we talked about in the beginning, there's all of this regulatory stuff coming in from the side. How easy can we follow the regulations and make sure that we don't get a fine all of a sudden?

If we have a good platform, we might be able to say, all right, these capabilities don't fully support it, but if we just tweak them 2%, they will. All right. It's cheap.

Do it. Just make sure you don't break everything or make sure you have a transition story or whatever we call it to make sure we can come to the level where we're within the regulations. And yeah, cost.

Everything comes down to cost in the end. Is it the cost?

[Pinja] (27:44 - 27:44)

Yeah.

[Stefan] (27:44 - 27:46)

Are we making more money than we're burning?

[Pinja] (27:47 - 27:53)

And how are we on top of that? So the cost predictability is one thing to look out for.

[Stefan] (27:53 - 28:07)

I love when teams reach out and say, if we want to do X, Y, and C and it requires this, what is the estimated cost of it? Well, how many users do we have? Oh, we don't know.

Well, let's sit down and look at it and figure out what this is going to be, price-wise.

[Pinja] (28:08 - 28:35)

And when Stefan and I were, when we were planning this episode and we were thinking, how do we close this? And Stefan just said, well, we could say, do it like you mean it. And I just wrote it down.

And here we are on air saying it. So if you're building a developer platform, do it like you mean it. Actually think about the users, think about the roadmap, treat it as something you're offering as a service internally.

Don't forget about your own people because they're the customers for this.

[Stefan] (28:35 - 29:40)

Make sure you invest in having the right setup for it. The amount of times I've seen a director all of a sudden going from being like manager of manager or strategic person in a setting, all of a sudden he needs to start thinking about product lifecycle. He needs to talk to stakeholders.

He's already doing way too much from the beginning. All of a sudden he just gets additional workloads on top of everything. Some people might be able to do it.

Of course, there are always these rockstar people out there that can do everything, but you need to make sure that you have the right setup for running the platform as a product. And you need to have a good variation of skills in your platform department or team. You need someone who can be the initial ambassador.

You need someone who can go and evangelize it, even though I hate saying evangelizing because that's more like pushing your product. But you need to think about marketing. A good corporation has marketing, product, support.

You need all of these skillsets in your team and usually tech people are not the best at marketing. So I spoiled it for everyone.

[Pinja] (29:41 - 30:02)

No, to pay attention to that is the first step and thinking about it, how to build it. We don't need a separate marketing function just for this. That's an overkill.

Don't get us wrong, but to pay attention, how do you implement it and how do we actually get people to use it on a voluntary basis, not by mandating.

[Stefan] (30:03 - 30:07)

How do we package it well and give it a nice present if you want to buy it?

[Pinja] (30:07 - 30:12)

And on that note, I think that's all the time we have for this today. Stefan, thank you so much for joining me.

[Stefan] (30:12 - 30:13)

Thank you.

[Pinja] (30:13 - 30:24)

And thank you everybody for tuning in and we'll see you next time in the DevOps Sauna. We'll now tell you a little bit about who we are.

[Stefan] (30:24 - 30:29)

I'm Stefan Poulsen. I work as a solution architect with focus on DevOps, platform engineering and AI.

[Pinja] (30:29 - 30:34)

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

[Stefan] (30:34 - 30:36)

Thanks for tuning in. We'll catch you next time.

[Pinja] (30:36 - 30:44)

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