Kim Wier & Ron Tatro - Revisiting FinOps as Product, 3 Years Later

Speaker A: Hi everyone, this is Kim Weir and I'm Ron Tetrel. And this is the world famous Spin Ops pod.

Speaker B: The last time we did this was February.

Speaker C: It's really been that long.

Speaker B: Yeah.

Speaker C: Okay, ready? Hi.

Speaker B: This is Stacy Case and I'm Jo Daly.

Speaker C: And this is fun.

Speaker B: This is.

Speaker C: Oh my gosh, Joe. It has been a minute.

Speaker B: It has.

Speaker C: We have that little thing in San Diego that we like to do every year.

Speaker B: We did. And what's funny is I believe in December when we released the end of year 2024 episode. I want to get like 12 episodes out this year.

Speaker C: Mhm.

Speaker B: Well, we're on episode two and it is the middle of July. You know, it's one of those things that uh, we had Finops X, it was bigger than ever and it required a lot of focus. So this got shelved for a little bit. That's okay. But what's really cool is a lot of you listeners who were at Finops X walked up and told Stacy and I that you listen to it and that you appreciate it. So I was like, okay, we'll get back out.

Speaker C: They always had like super kind things to say. But you and I talked about this later, which was talking about really the value of this pod, that it's not that people are just listening to the most recent one because as we know, there have only been a few the last couple of months. But they're going back and listening to older ones too. And I think that's great because they're are such great conversations that have been had that are applicable no matter where you are. So even if it was something that was recorded, you know, 18 months ago, 24 months ago, it is still a story or something that people can relate to depending on what they're currently going through within finops. So that's really cool. Yeah, I think you and I were both a little shocked by that. When people come up and like, oh yeah, I listened to all of these just recently. We're like, huh, huh. Cool.

Speaker B: Yeah. And what I like, because there are. There are the folks who. I think there are two different types of FinOps pod fans. They're the types that they just like listening to you and I banter at the beginning.

Speaker C: Yeah. And I feel like we're letting them down right now. I'm just gonna say that.

Speaker B: Then there are the folks who listen to the entirety of the interview and they learn things from the people who we are interviewing and they're usually the ones that come in later and find the episodes.

Speaker C: And it's really cool to what you and I say, which to be fair, everybody, we are not the heart of this podcast.

Speaker B: And it's, it's not like we've been told too much blah blah blah before. So, you know, there are the blah blah blah heads and there are the, uh, content heads.

Speaker C: No, I'm going to stop right there because I'm not going to call anybody a blah blah blah. Please tell us the names for the people that just listened to the intro. I think, well, I guess. Does that mean they do like the blah blah blah or they wish we could do less blah blah blah?

Speaker B: No, the blah blah blah heads are all about the blah blah blah. The content heads actually listen to the interviews.

Speaker C: Well, hey, if we talk strictly to the content heads and get into the content, what are we covering in this episode of Finops Pod?

Speaker B: So I'm addressing the content heads right now on that whole note about people going back and listening to previous episodes. I do track this downloads of Finops Pod and it is really cool. There's a few patterns that always exist. The latest episode always has three or four months where it's just downloaded a lot. And then the next most highest episode are people who are like, I'm going to be a completionist and listen to all of them. And so they go to episode one and listen to Dina Solis. So Dina Solis has like the most amount of listens ever.

Speaker C: That's a great interview too.

Speaker B: Yeah, and I'm so glad we started with Dina because like what a great person to like introduce.

Speaker C: If we started with anybody else, we might not have still be here today. But thank God Dina came in and had something to say and we were able to ride her coat waves for a couple of years.

Speaker B: Yeah, from this there are some episodes that get downloaded quite frequently. Something happened after FinOps X 2024, which was not this last one in 2025, obviously it was in 2024, over 12 months ago, Kim Weir's episode started getting downloaded consistently each month. It was like in the top five downloads each month from there. And it's called Finops as product. And again there was just a ton of blah blah blah on that episode.

Speaker C: So you're giving the credit to Kim, but it might have been us.

Speaker B: You could have been a lot of really good blah blah blah. And then then like the first half is about Kim's career, which is really interesting, and then talking about how she is setting up Finops as a product at Target. Well, it's been three years now. Three years since that episode was released. And it's been downloaded, probably second only to Dena. So I went back and I revisited Kim and Ron Tetro, and it's been really cool. And, uh, spoiler alert. They're really good at this finops stuff. They were kind of ahead of the whole scopes cloud plus trend. They built their FinOps product to be all of their infrastructure, not just public cloud, but also private cloud. And it's been really interesting to catch up with them and see how they've developed that product.

Speaker C: So we're revisiting Kim, um, three years later to see lessons learned, things that have changed in the past three years, the evolution of her team and the product. That's cool. You should probably do more of those. That's a really great idea. All right, well, with that, you know

Speaker B: what we do well, hit the play button. Here's Kim and Ron.

Speaker C: Oh, wait, I don't need to do sound effects.

Speaker B: That's right. I have those. Previously on, um, finops Pod.

Speaker A: Yeah, so with the addition of the product owner, his first responsibility is going to be going out and talking to the engineers who are going to use the tool and get their feedback. You know, finops and efficiency engineering isn't like, well, what do your customers want? Honestly, they don't want any of this. Uh, they need this. And so we developed the tool based on what we know and understand. But now that we're at mvp, we will be going back to many more of the product engineers to say, how do you want to see this information? One thing I think is also interesting at, uh, Target, and I know this is true of everywhere product engineers, they have so many priorities and it's hard for them to balance those priorities. They have developing new features, they have lifecycle management, they have incident and change and all of those things that are coming at them that are important and how do you prioritize them? And then you have this utilization. How are you utilizing your infrastructure? How much is it costing? You have performance. You have to understand your performance. Where we're headed is eventually we want to have a holistic platform for a product engineer to go to, to see all of the things, not just my tool, efficiency engineering. And my team has been building with this future perspective in mind. All I want is for the one surface where a product engineer goes to see how are things and do I have any opportunities. So we will build just a little efficiency indicator. Are you good or are you not good? If you're not good, click in for more. And that's where they'll come to our application. But if they're good, they don't have to think about it.

Speaker B: So I can hear the listeners asking the question out loud. They want to know if you're going to create a single pane of glass that has a lot of health metrics for an application team and you want one metric to represent the efficiency engineering health check. What do you have in your mind for that one metric?

Speaker A: That's really good. My team had created an efficiency indicator. It's a battery icon and it tells how efficient an application or workload or product is. But that's the one feature that we want input on from our product engineers. So I don't actually have the vision for it yet. So it's going to be driven by the product engineers. What do they want to see? What's important to them in understanding where their efficiency perspective is at?

Speaker B: If I remember correctly, this was April of 2022, three years ago we recorded that podcast. Isn't that crazy?

Speaker A: Seems like last month, yeah.

Speaker B: I don't think anyone thought this would last for three years, but here we are three years ago we recorded that episode. And you talked about how Target is building FinOps as a product model in the last three years. Kevin, Ron, talk about how the FinOps product model has evolved and grown at Target.

Speaker A: Boy, it has. So our product we call now the Cost Hub, has really come a long way. So when you take this concept of finops and build a product for your team to utilize, to understand how well they're utilizing their resources, get to talk to your customers, you get to think about things from an engineer lens and then build the solution that helps you make progress against the opportunities. So when we first met, we were at the very beginning of our journey and really defining what that product was going to be and what it was going to look like. Since then, I would say we have really different tracks going on now as it relates to finops. One, we have the Cost Hub that is fully in production. Teams can see what resources they have both on prem and in the public cloud. The Cost Hub, um, lets them know how much their resources cost and it also gives them some idea for how much they're utilizing and then how much of an opportunity they have to right size and save money. So that's really one thing. The other thing that we have is a, uh, highly matured forecast capability. And Ron, maybe you can go into that a little bit more and talk about the success the team has seen in the last three years around forecasting, even into the complexities that you're seeing now with New AI and gen AI workloads that we're starting to see. And then the third is a bigger, broader component that we're building called Infra Showback Hub. As we were looking at what our customers need and what they do every day, what that experience is like, we realize that they are being bombarded with a lot of different asks related to technology fundamentals. Cost and size of resources and utilization of those resources is just one component of the ask. From infrastructure and security teams. We have been in just the last year expanding our product beyond cost and finops into other technology fundamentals like stability and technology debt because those are other areas that request and need engineer time to really run uh, performant and stable applications at scale. So at target we have over 5,000 technology team members. So you can imagine how difficult it is to manage all of those applications from a uh, cost from a uh, stability performance perspective. So we have been building out a new solution that brings all of that together in one place for them to see how well they're doing. Ron, do you want to talk a little bit about the forecast capability?

Speaker D: I was just going to follow on what you're just saying though too, because to me that's really completing cost. Hub is very much informed, maybe getting into other ways. But if you think about our infrastructure back Hub, it really starts to optimize then operate at scale. I think, you know, we're just on the cusp of that, so that'll be good to see from the forecast capability. Yeah, I'd say like overall we have had really good success with forecasting at least in the public cloud. We have a couple of different predictive AI models that give us good close window range numbers to understand if we're tracking or not. But then also with our long term perspective, we're actually, you know, using some unit economics in our forecasting and so we're able to get some signals from business and then if we're operating like an elastic cloud in a reasonable way, those business signals end up translating pretty well into longer term numbers, at least. For the last few years most of our use case has been in delivering digital orders for our guests. That's been the vast majority of our use case there and our numbers have come in typically under 5. This last year we actually had under 1% accuracy with our forecast, which I think is insane for a company our size. I think there was a little bit of luck involved too, but it was pretty crazy how close we came.

Speaker B: Yeah, that is amazing. I was going to ask you for unit economics. Are you Using customer shopping carts or are you using a technology metric?

Speaker D: We are using the guest metric. So basically number borders. So yeah, and I think we've talked about this, we talked about aligning it to our digital guest order experience. So whether somebody's ordering a toothpaste or a tv. Right. It's the technology exists there to process the order. Right. And if we're using elastic features, then the delivered value of that, of the order experience tends to scale with order.

Speaker B: So it's just what's the business expectation on sales?

Speaker D: Right.

Speaker B: And then you're just very easy. You have your technology broken down and linked very closely. I mean if you're getting that sort of result, even with luck, it's pretty well linked to what is actually driving costs. So that's really impressive. So you're able to then forecast that out based off of business plans and if business plan shifts, you can update that as well.

Speaker D: So we can give a little bit better, more stable long game. Like we still have our predictive models on short games that do very well and then they're used for say anomaly detection or things like that. Yeah, we have just different ways that we use it.

Speaker B: This is part of your Cost Hub,

Speaker D: uh, product, part of our practitioner toolkit. And then there's some of these features that are emerging into our Cost Hub product this next quarter. So where teams will get more of that right in front of them.

Speaker B: That's really cool.

Speaker D: But that's the past. Right. And so Kim talked about the future and future. You know, that landscape is changing so I'm expecting we'll have some more variability in the future just because we have additional use cases coming in, putting different pressures on our spend where we don't have probably the same predictive model. But again we hope that we will emerge to that next door the additional business value drivers out of different use cases and then get to the same alignment of long term and short term cost forecasting.

Speaker B: So what are those new variables?

Speaker D: Well, you know, the whole expansion of AI in general is very different. Right. And so that puts different pressure points all throughout, both on prem and in the cloud. So we expect that to be just a different profile that we have seen in the past and we're still learning how that's going to influence us. And you know, I expect that to change the way we can model a little bit in the future.

Speaker C: Yeah.

Speaker A: And it also changes that unit economic factor as well. One of the things the team needs to figure out and go deeper into, especially as we've gone into on premises, is what are those different unit economic factors for other parts of the business? You know, it was pretty clear for our public cloud because it's mostly Target, uh.com, but internally in our private cloud and in these new AI and gen AI workloads, you know, what is that unit economic that's driving that utilization so that we can come up with and be able to show the value that those are delivering.

Speaker B: How are you finding AI to be? Are you finding AI workloads to be? Hey, the capabilities we built through FinOps practices apply really easily here. Or like we have to expand and grow our capabilities or adjust our capabilities in some way to, uh, govern this AI spend. I mean, it sounds like you're having to refigure out your unit economics in this space. I'm interested to hear what your experience is so far with AI.

Speaker D: Yeah, I would just say that we were very early with seeing this as a possible trend or impact of cost. And so we got involved very early. And with platform teams that are running gen here, we got their costs allocated. So I think shortly after they launch we had our costs right there for all the customers. And then there is the realization that these experiments have an intended value target. And so there's really good conversations and we're maturing in the space yet around the alignment of the POC to what's the return value of that? And so because we have the rest of the stack too, we're looking forward to continue to build on that and incorporate all the costs across public, private, everywhere that these experiments can kind of touch and really look at are we getting the value returned or not? So there's a focus around that.

Speaker B: I think that's awesome and I'm glad you answered it that way because based off the first episode with Kim, Noel and I were interviewing Kim and Noel asked the question. It seemed like an innocent question, but you're answering through both of us for a loop that you let the teams define what efficient is and what the value is in our heads. Just the, uh, old school early days finops practitioners was, nope, it's utilization and cost. We've grown way past that. There's so many nuances in that space. So I'm really interested. I don't know if you're able to share, probably not able to share what the value proposition is, but can you talk about how is it different than other technology spends, like car cloud or public cloud, that you're able to go to the tech teams, the platform, and help them measure the value of that investment?

Speaker A: I think that Just having the cost data available is a big part of being able to measure the value. So if you understand how much it's costing, then you can understand what value is it bringing in and how much did that cost where, if we weren't already on top of that cost metric, we would not be able to understand if it's costing more than the benefit it's bringing or is it. Yeah, let's do this more because it's super valuable to the company and it's bringing in a lot of extra revenue as a result. So just having that cost information and being on top of it is really helping us with our experimentation.

Speaker D: Yeah, I'd say it is early. So, you know, we're still maturing in the space, but there's all sorts of, you know, how do you optimize? Types of questions that we still, I don't think, have really quite cracked yet. So it's maturing.

Speaker B: Is this AI spend already part of your Cost Hub product or is it in separate.

Speaker D: It's part of the Cost Hub product.

Speaker A: What was the big buzzword at Finops X last year?

Speaker B: No runners.

Speaker A: Yeah, there are no runners. And that, you know, this is just a perfect example of how there are no runners because once you think you're a runner, something like AI and Genai come in and now you're back to crawl and everybody has to go through that crawl phase because you have to learn how is this all going to work. So, you know, I would say that we're approaching runner at private Cloud and public Cloud, but when it comes to AI costs, we're definitely in the crawl

Speaker D: phase and it resets our forecasting.

Speaker B: That's interesting. And also right now the buzzword is cloud plus scopes, uh, however you want to refer to it. And this is something I didn't really focus on at the time three years ago because we're really still in that just, hey, we're just focusing on the cloud right now. But you all were focusing on data center plus public cloud to begin with. I want to double check something you said you're getting amazing results with forecasting, with being able to forecast your spend through your tooling and unit economics. But do you have the same M results with your private cloud in data center, Sven?

Speaker D: I would say it's different in private. Private data centers are never built to bill, which is part of the challenge. Right. So we're still finding areas that we need to, uh, onboard and mature. Quite frankly, to answer your question is no, because it's still maturing.

Speaker A: It's A different scale. You know, we have a uh, real mature data center that already is locked and loaded with all the servers and the different infrastructure components. So we do have an understanding of how much that is and that is what's informed the bill. But now if you think about an application is consuming 4 CPU from Google versus now we have to go out and buy more servers for our data center. The cost difference is significant and so it is different because you have to go out and buy whole sets of servers in order to accommodate growth versus an application expanding to accommodate growth.

Speaker D: It's more capacity management and then just long term capital planning. I don't know how much detail we want to go into how we do some of that stuff, but yeah, it's just different.

Speaker B: I want to uh, ask how do you as product owners of your solution, you have public cloud, private cloud, AI, how do you determine what solutions and capabilities to provide and how do you prioritize that order? Because you're dealing with multiple, you still only have so much time and so much ability to deliver a feature. How do you prioritize which feature for which infrastructure set to develop?

Speaker D: You can go Ron, I do it poorly.

Speaker A: Well Joe, we really do have annual roadmaps and we try to align what we think we need for the year, what features, what are the things that our customers want and need. We do have connection points with different users in the community. We talk to senior leaders, we talk to middle management, we talk to engineers, we talk to product people to understand what is the information you need and how do you want it presented to you. And then we let that inform our uh, roadmap plus with something like FinOps. We also look at what the FinOps framework is saying and where should we mature from a FinOps framework perspective because we know that's important as well. So you kind of combine all of that into your annual roadmap. And of course quarter one you can see clearly this is what you're going to execute on. And then quarter two something comes in and informs your quarter two plan differently. So then you just need to prioritize based on what you think is going to give your customer the most value. So we have things broken down into features that we're developing and then seeing how we get that work done throughout the quarter. It's a lot of interaction with our users, the 5,000 plus people that need to be using these tools and then understanding the framework and what's important and then getting that into the roadmap so that we are bringing the value add and Believe me, at, uh, Target, there's a really significant focus right now on what's the value this is bringing and can you measure that value? And so that's another area that we are maturing this year is really how do you understand the value that this is bringing to the corporation? And, um, I think from a cost perspective, that's fairly easy. That's an easy value measure. But when you're talking about something like technology debt, well, what's the value you're bringing to the company? It's risk avoidance. And how do you quantify risk avoidance?

Speaker B: All right, so that's a perfect segue. I'm really intrigued by your infrashow idea, um, of including tech debt. And I want to ask you to expand upon what you are referring to when you say tech debt.

Speaker A: That is an elusive term. It means a lot of things to different people. Uh, at Target, when we talk about tech debt, at least within Target technology, we're not talking about the code that you wrote because you needed to get this feature done, but you know that you're going to come back and touch it again. That's not the level of tech debt that we're talking about. We're talking about when you have 80,000 CentOS servers that need to be now on Ubuntu because CentOS is end of life, that's tech debt. And so to us, it's when your infrastructure has aged to a point where you need to get off of it. And that could be vendor driven or it could be target driven that we're no longer using that product, or it's target built and it's at the end of its life and you have to move to the next platform. That's what we mean by tech debt. As we've been building out this infra showback hub. And you know, Target is all about the three letter acronym. And so unfortunately for us, somebody named our solution infrashowback Hub. So our three letter acronym is ish.

Speaker B: Ish.

Speaker A: And so we just have owned it and we, we are big and bold about it.

Speaker C: Ish.

Speaker B: I love it. So ISH is showing that cost and stability and tech debt information. Are you hinting how the engineers should prioritize their work with this?

Speaker A: Yes, in a way. So, you know, we've all talked about gamification. We have built an application that gamifies these opportunities or these capabilities, what we call them capabilities, Tech debt, stability and cost. And so with that there's a scoring component. And if your score is above a certain score, your grade if your score is below a certain score, then you have opportunities that you should be paying attention to. Our senior leadership also looks at those scores in their OPS review meetings. So people do pay attention to it and do make modifications and resolve some of the insights that we provide or the opportunities. So this infrashowback hub is fairly simplistic when you think about, shows the team a score for cost, a score for tech debt and a score for stability. And then it provides insights into how you can improve your score. And then within those insights we have the ability to prioritize them.

Speaker D: Yeah, I'm glad that you brought those up because that, uh, was the point I was going to make. So for our cost depth capability, we use prioritization based on how many wasted dollars we find in the insight. So if it's over a certain threshold, then we'll list it as critical or high medium. So there is an ability for teams, when they look at their insights to get a prioritization of what work they should do. And then part of the goal of each insight is we provide the steps somebody should do. So like it's actionable basically. And so there's action that engineers can take by looking at it and saying, oh, this is a high priority one. These are the actions that I should consider.

Speaker B: Do you have to have your team manually create that?

Speaker A: It's automatically created.

Speaker D: There's just generic rules. So all the billing data goes through these basically insights generation. Right. And so it's all the rules are shaped and waste is identified in the bill and that generates the insights and it gets prioritized based on how much waste is in the assessment.

Speaker A: The same is true for tech debt is there's a insight, uh, configuration that here's the parameters and then there's the engine that processes and says here's all of the tech debt opportunities. And the same thing with stability, they have their configurations and the engine processes and here's all those stability and then those opportunities are what impacts your score.

Speaker B: In my head thinking back about this, I'm thinking of all the servers that were on exception to patching lists. Like, you know, you're tracking which servers you can't patch anymore for X, Y or Z reasons. But it's all tech debt related. And I could just imagine the longer that goes, the rule might say if patching exception is longer than X, number of months or decades, uh, depending on what company you work for, score of large amount. So that would, that's really interesting. And it's complicated in the amount of things you have to figure out. But it's a simple framework, I guess. It's just a lot of data that you're sending through a simple framework.

Speaker A: Yes. Yeah. And I think, uh, that is one of the biggest challenges. Just like with finops, you know, you have to have the data first. So as you're going into building out your finops capability for your on prem workloads, you have to be able to get the inventory data and the cost data and the utilization data, much like what the cloud service providers already provide. We need to do that manually at first, where we're working with all of the platform teams to get their billing data and their utilization data and their request data and then build the pipelines. So it's very complicated from a data perspective. But once you have quality data, then you can really build so much on top of that that gives insight into how you're doing and what you can do better.

Speaker B: So really you're helping developer teams figure out which scope of, um, a FinOps practitioner would recommend that they look at. Because some teams are going to have to look at their public cloud part and other teams are going to be looking at their private cloud part. Some teams will make sure of both. And you're enabling all of that, uh, decision making from your centralized position.

Speaker A: Pretty cool. It's really leading to that developer experience.

Speaker B: Wow, you guys sound really mature at this.

Speaker A: We're trying.

Speaker D: To.

Speaker B: That's it for this episode. It was an absolute pleasure to catch up with Kim and Ron. Such awesome people who are consistently willing to share what they have learned. I think it's pretty clever how they have approached their product. They don't force decisions on product teams, they give them the information to make their own decisions. Product owners can see if they want to improve in cost efficiency, stability or lower tech debt. It's their own iron triangle of prioritizing product health. I wonder if another company took a similar approach, would they provide the same three data points or would they be different? What info would you provide your product owners and their forecasting module? So impressive that they have the unit economics down to accurate cost drivers. Editing this episode, I wanted to make a whole other podcast diving into how they did that. Maybe someday we will, but we will leave things here for this episode. Again, thank you to Kim and Ron. As always, thank you to Stacy Case for contributing to the blah blah, blah and getting this started right. Another episode will be coming soon. No, six months of waiting for the next one. Uh, until then, keep on finopsin'. Sam. Mhm.