Las Vegas 2020
Two Viewpoints: Where The Remaining Gaps Are For Technology Leaders
Learn from John Cutler of Amplitude and Peter Moore of Wild Oak Enterprises.
JC
John Cutler
Head of Product Research & Education, Amplitude
PD
Peter D. Moore
President, Wild Oak Enterprises, LLC
Transcript
All right. Over the next 30 minutes, we have two talks that serve a very specific goal. These two people share a common dissatisfaction of how technology in most organizations is managed and leveraged in service of what our customers need. I believe they both can articulate better than almost anyone where the gaps are and just how harmful these gaps are to their organizations. John Cutler is in my opinion, one of the people who is doing the most innovative work in advancing the field of product and design, it's been my personal observation that his tweets are among the most widely read within the Delta enterprise community. And I personally benefited from his amazing advice and observations. John believes that technology and design are the secret formula for winning in the marketplace and helping organizations as part of his role as head of product research and education at amplitude, he will talk on his views of how we should broadly view design and technology, what we're often so missing. When we talk about product and design and what this community can do about it, to truly build great products that help our organizations win in the marketplace. Here's John.
Hello everyone. My name is John Cutler and I am so excited to be speaking today. And I'm very grateful to Jean for the invitation. I've mentioned this in earlier talks, but before tending DevOps enterprise summit in person in Las Vegas, those in-person conferences, uh, I was absolutely obsessed with the videos and Matt Skelton will say, I sit there and like obsessively tweet out links to the team typology videos. I'd see. So I'd watch them over and over and over. So to be able to do a talk on the main stage, uh, the virtual main stage, so to speak is a real honor. And a bit about me. My background is in product management UX, a few startups, I guess I got my start trying to make a video game. I made a game about bartending called last call, unfortunate name, maybe, uh, which ended up getting a mature rating by Walmart.
So it didn't really sell, it was a big commercial flop, um, but it was fun to make. And that's kind of how I got started. So then I wised up and started to get these quote unquote real jobs, um, which are kind of surreal, I guess. So in my current role at amplitude, I get to talk with lots of teams from two person startups to teams at fortune 10 companies, frontline developers, to CEOs and CTOs. And it's a lot of fun for someone who thinks about this all the time and nerds out about it all the time. Uh, this is sort of the dream job. Um, I just love this kind of stuff. Now, my goal at amplitude and Amplitude's goal thankfully, is to help teams have more impact. And we do this with our product, right? Think analytics, purpose, built for product teams and with our workshops, coaching some services, et cetera.
And that's where I spend most of my time. So that's some quick background about me now in this talk, we're going to talk about what I see as a natural evolution for the DevOps community. We're going to talk about product design outcomes, feature factories, leadership. We're going to talk about the concept of being product led and how that applies to companies that aren't digital product, first companies. And I'm going to leave you with a couple questions that I'd like to carry with you through the next couple of days of the conference. Now in my day-to-day work, I'm observing large companies jump on the product, thinking train. They come to me or they come to my employer amplitude because they've been told to adopt cross-functional teams to think in terms of products to become more outcome oriented or data informed to improve their customer experience. And in most cases sort of be like company X and we could all insert X there.
And here's what I'm seeing when those organizations put this all in motion, suddenly as expected, everything is a product there's products, everywhere there's product owners, everywhere. There's product managers, there's product owner managers, there's product portfolio managers and product analyst and product project managers and their managers. You want a budget call it a product and roadmaps, right? You have to have a roadmaps when you have products. So you, you, what you do is you actually, it's exactly like a Gantt chart and you put quarters along the top and you fill it up kind of like a horizontal Tetris game. And of course, many of you are non-customer facing teams. You actually have to play Tetris, um, based on their Tetris, which is based on the business's Tetris. So it's three it's Tetris, um, you know, to, to the third power. And then you have to have boards everywhere.
Cause they're supposed to visualize the work. You need a big done column on the right donning, shipped mission, accomplished all systems go. And then next feature, right? The train has left the station. Uh, I still I'm, I'm still trying to figure out why they're called release trains, but I'm sure there's a really good reason for that. But anyway, so it's sort of like all aboard. My son likes Thomas the train. So I think about trains along. So some of this might sound familiar. You might be supporting this. You might be operating what's outputted. You might be developing supporting tools or infrastructure platforms, or you might actually be in the thick of it as a so-called customer facing team. And this is where lots of companies are at right now. They've heard that they need to embrace product thinking. And this is kind of where we've ended up.
We've ended up with finely tuned, feature factories, reasonably usable work, reasonably fast, stable observable shipping, you know, every day, every hour, every minute, uh, it works. It doesn't really break and, uh, don't get me wrong. This is progress for sure. And it's a step up, but it's not the destination. And that is super important. And if you've been involved in software for a long time, you know, that moment where you think you've gotten somewhere, just when you start to breathe, that's usually a signal that we're seeing a false peak or a false horizon, and many organizations are missing a central idea. And this makes sense because many of the popular messages we have about digital products come exclusively from digital product. First companies that grew up selling digital products. So more specifically rapid scale-up startups, like my company amplitude, and then 20 or 30 year old, uh, tech stalwarts, you know, on their second, third, fourth, fifth, sixth act.
And these are interesting stories, uh, but they may be hard to relate to. So companies have trouble applying the ideas. And I remember this from, uh, we did a lean coffee activity in Las Vegas, and I was sat in a great group of people, but the questions were, were seem simple, but they're intense. What is a product, but we don't sell that. We sell something else. Wait, is it a product or service or an experience or skew. And so what you see is comp uh, companies, copying frameworks, renaming, everything, you know, projects to products, restructure everything, new titles, new rituals, um, they, they seem to leave out the convenient, like threats to formal authority. They don't really get the care of that, but anyway, but, um, but, but the outcomes in many cases are, are only marginally improved. So why, what is missing? So I've been thinking about this a lot lately and, and I am, I am basically obsessed with this question.
Um, and I, I think about it my day job and at other times of the day, too. So in my, my day job, I ended up talking to lots of teams and I'll be chatting to someone from a company, uh, known to be world known worldwide, to be customer centric, a great place to work an innovator in their domain. They put world-class leaders, they're thoughtful, they're embracing change, they're positive. And they're, they're nowhere near that stereotype of the bureaucratic slow moving enterprise. Yet they are still grappling with some essential truths about this new reality. So again, uh, what's missing, what do I see that they don't see, or maybe, um, maybe they see something that I don't see, who knows. So in my world, we refer to some companies as being product led and, you know, we have to dig in there cause that's some pretty big word.
So what is a product led company? So first it does not mean product manager led. We have to really get that out of the way first. And it doesn't mean that they don't have sales people or marketers. Um, it means something different and it means that they're using design and technology together to drive sustainable growth and to, you know, meet the needs of the human beings out in the world who rely on their products and services. And so when you apply that to non-digital product companies, what this means is that you're, you're using design and technology across the business to, to find sustainable sources of differentiation and growth in a sense, and this is really important. The whole company becomes the product. It's no longer a, the business and the teams or the business. And it, Peter was talking about this a lot or the business and delivery teams or, you know, my favorite, uh, the business and it renamed as product development because we've hired 400 product owners and 400 analysts and 200 scrum masters.
And, um, I don't know if, uh, 15 designers, you need 15 designers, you have a chief experience officer and we're walking around with mock-ups all over the place and talking about, you know, the intended experience, sorry, this is a little sour topic for me, but, but, um, it's, you're not seeing those divisions. What you're seeing is that the duality ceases to exist, it's all the business or the business is all the product. So back to this void and understanding, I was talking about earlier, why does this idea of being product led matter? And certainly your companies believe in your products. Uh, even if you don't sell digital products, you believe in serving your customers, that's not new news, but it does matter. And here is why one of the key things missing in these conversations is a belief, a core belief that design and technology can be the source of step changes and outcomes, a source of innovation.
Something that can help the company do just more than survive or do more than deliver features quickly, or do more than just be responsive or more than just run a feature factory. And it's a shift from supporting the company's strategic objectives to actually shaping, guiding, and leading the company's strategic objectives. And my joke is it's like, it's a shift from sitting at the table to designing a whole new table. So there's a fundamental perception issue in terms of the value brought to the table and maybe even the table itself, but that's not really the whole picture. So what you often see is for example, you know, a company is literally the best in the world in their domain, maybe it's banking or automobiles or logistics or travel or publishing or music or retail or pharmaceuticals or footwear. And yet they're struggling with creatively applying the kind of design and technology that we work in to solve problems, shoe designers, amazing at design.
But this other thing is hard. It's, it's, it's curious, right? So the scientists or the, the designer or the doctors they're being bold and creative and then there's it. So what are we, what are we grappling with here? It's what we do is a different beast than it can be super hard to wrap your head around that it can be super hard for your companies to, so say for example, um, so I'm going to propose something. I'm going to propose that the real differentiator isn't really what's shipped and delivered, but rather the domain experience awareness, um, the teams develop for the customer and the problem, and they encode that knowledge and the product. They literally, the code is a representation of knowledge. So maybe that's the product, not the code. The pixels are what gets built or deployed. Um, you know, certainly we all know that product features platforms go in and out of style, but, uh, you know, they're differentiated, right?
They, they serve their purpose, but they come and go. And what we're really doing is disrupting ourselves and nothing is truly shipped. That's like a, been a big, um, uh, um, thing that I've realized. And these last couple of years, things aren't shipped, they're only really just offered up. We're offering this to you. The team is the product. The company is the product. So, uh, I, I did a recent survey with about a hundred, 800 responses. And I asked people whether their organizations were shipping faster than they learned or learning faster than they should. And 80% now, granted, maybe my Twitter following is, um, biased probably is at 80% said they were shipping faster than they learned. Wow. That's like, that's kind of incredible if you think about it. So while important shipping alone is not the differentiator. Now I can certainly, you know, shoot holes in that. Um, I, I can see some situations where shipping is the differentiator, but that idea itself, right of the impermanence of what we build this lasting value of what we learn is a wholesale shift on how most organizations understand software delivery and operations.
Okay. So here's another mind bender for these organizations and it cuts to the central distinction between what I would call an opportunity seizing team and what we commonly think of as a delivery team, or even an operating team. We know how this goes, right? So you business pick the right thing and we will build the right thing, right? Or you designer design it and we will build it. Or you product manager own the problem. And the engineers on the solution, your customer facing teams have a high profile roadmap here. And then the non-customer facing teams have this shadow roadmap over there, or think it, build it, run it thinkers over here and the builders over there. So the idea that these are one in the seam is extremely challenging for the legacy organizations I talked to. And it got me thinking like what these native digital product led companies have figured out is the idea of truly cross-functional teams, opportunity, discovering teams, problem solving teams, creative, like close to the edge teams, close to the customer, align with the human beings out in the world, the real customers, right?
Not the internal customers. Those are partners. You don't have internal customers unless they're giving you money, right? Those are your partners, but rather I'm talking about the real customers out in the world. And these digital product. First companies have also figured out that supporting teams are not somehow second class citizens. In fact, um, the people caring for what I call the value creation system, the ability for the system to sense and respond, to operate, to adapt, to extend, to scale up scale down insights, recover on an example I have is onboarding new developers gracefully. They take that seriously. They take psychological safety seriously on the part of their teams. So it's as much as the product as, as the skew or the specific, uh, service offering that they're giving. And that is one of the big leaps and one that companies would the rock star somewhere else, right?
The rock star scientist, or the shoe designer, the car builder, lawyer, or whatever, have a tough time accepting. So let's recap for a second. So first we discussed this big rip and replace that's going on with adopting product thinking, which I think is, is going wrong in many cases. And then we talked about the difficulty translating messaging about product making from digital product examples to other industries. That's a huge challenge. And then we translated product lead for non-digital product examples. And hopefully that resonated the company is the product. And then we address these three big leaps. And I'm guessing these are some leaps that you're struggling with in your particular companies. So the first leap is design and technology as a catalyst for sustainable differentiated growth step changes, not just survival, not just responsiveness, but step change is redesigning and rebuilding the table and the importance and the lasting value of domain knowledge.
This idea that products and features the stack or whatever is, is ephemeral in a sense. And that that we have to bring product teams as close to the customer domain as possible. And finally, this idea of breaking through this false dichotomy of the thinkers and the builders on this idea of opportunity, seizing teams. So hopefully some of that resonates, um, or at least gets you thinking, uh, as you go about enjoying the conference, I wanted to leave you to ponder a couple of questions. And that's kind of my ask to you. If, if anything, you could DME in the conference, slack channel with the answers to these questions, if you thought about it over the last couple of days. So the first, what beliefs must you personally let go of to set about not just sitting at the table, but kind of leading your business, using design and technology to support these step changes, um, and sustainable growth.
So what here is another way to think about it? What would you do if suddenly I said, I'm giving you a two level promotion right now, how would you navigate that second? What steps do you need to take to be able to connect the day-to-day work of your teams out to the benefits and outcomes in the world, outside your organizations, walls, not story points, not cycle time now out to the at least be able to trace the line from that passionate engineer. Who's on a data pipeline out to the human beings out in the world that you're helping. That's something you could do today. Um, and if you do that, you start thinking about the next part of the question, is this, how can you help your organization learn as fast as you ship? Um, maybe you're the other way around at the moment, but maybe ponder the other one.
So the final question is what can you do to overcome the biases, the dichotomies, maybe the stereotypes that exist about tech in your company to be, I guess, more builders and runners to turn everything you do into the business. Think about that scientist, if you're a, you know, uh, in, in life sciences, you know, the scientists in your company are the rock stars. Um, but what would it take to, to bring the thinkers and problem solvers on your team up to their particular level? Um, so hopefully, uh, this has been interesting to you, a huge thanks to Jean and the organizers again. And I can't wait also to be able to do this in person as much as I like the virtual conferences and not traveling with a toddler. So I appreciate it. Thank you so much.
Thank you, John. All right. If John gave the right brain treatment of this topic, a to present a left-brain treatment of this gap between business and technology will be Peter Moore. I only met Peter one year ago, but he immediately struck me as someone who the DevOps enterprise community needs to know better. He spent decades in a unique position working with both business leadership and technology leadership. This started when he worked with the CEO and chairman at the New York stock exchange, where you work with CEOs of member companies. Another thing that was remarkable about his work is that it was enabled by the fact that he is the brother of the famous Dr. Jeffrey Moore author of the book, crossing the chasm and zone to win. He will talk about the many ways that business leaders put technology in the wrong frame or in the wrong zone and the bad outcomes that result. And more importantly, what technology leaders can do to escape the pull of its past of being a cost burden, and instead be unleashed as a key strategic asset. Here's Peter
Jane, thanks very much again, for the opportunity to share some ideas with the DevOps enterprise summit in Las Vegas, again like London, this is virtual. And one of the things I want to do today is get very specific about how CEOs and senior it leaders can close the gap in the perception of it as a cost center and cost burden, rather than a strategic asset. If we can't close that gap, I don't think it can make the contribution and the impact that companies needed to do to truly compete as digital enterprises. So what I'm going to do in my talk today is take you through some very specific steps on you as the CIO or another senior leader in it can actually close that gap. And when I call free its future from the pull of its past, so let's start by what that past legacy mindset might look like.
In some companies, a number of studies have documented that anywhere from 40 to 50% of CEOs and boards still see it as a cost center, not a revenue generator, less than 25% of companies are using digital technologies to advance their business strategy. And finally, more directly to some of the things we'll talk about today is it in general, still spends about 80% of its resources and budget on running the business and only 20% on changing the business. And if we can't take meaningful steps to changing that ratio, getting a closer to 50, 50, or maybe even 60, 40, 70, 30 change versus run, I think it will be very hard to overcome the mindset that it is just a cost center. So I want to take you through how I'm going to suggest we go about doing that. As Jean mentioned, my brother Jeffrey wrote a book called zone to win, and it was designed to create a framework and a set of discussion tools to enable companies to balance their resource allocation between the businesses they have now and new business investments that they'd like to make going forward.
I've adapted that zone to win model and to a foreign zone business value creation portfolio for CIO. And this is designed to make a business case that it assets are strategic assets and that they enable the CIO CIO and the teams to segment the work of it into four different. What I call themes of impact. And this framework is designed to represent it strategic priorities, business value, contributions, and operational excellence all in one place. So this is a complete picture of the potential business value that it can deliver to any organization. And as I'm sure you can imagine to successfully make this kind of shift or require a fundamental change to how it is organized, staffed and operates along with new ways to measure both TCO had ROI. So let's take a brief look at each of these four zones and I'll give you the way that it can impact each one of them.
The performance zone is where the organization has all of its businesses, and this is where your products are made and the products that are made are sold. So th this is everybody in the organization who has a revenue bogey high T's biggest contribution here to enable the performance of those businesses is to develop and deploy systems of engagement that increase customer experience value, and also develop and deploy systems of intelligence to better understand and deliver new customer value. And the key here is that it works in collaboration with our internal business partners, so that all it investments in the zone are aligned with the critical business outcomes that the business is on the hook for that particular year. So productivity zone is where all the systems of record reside in any organization, there could be ERP, CRM, finance, HR, et cetera. You have to have them.
It has to be stable, secure, and compliant with the industry that you're in. But one of the things that we noticed over a period of time is there's an enormous amount of trapped value in a number of these systems of record, particularly legacy systems that have been around for 10, 15, 20 years, that if you can recover that trap value and redeploy it against systems of engagement and systems of intelligent intelligence, you can significantly increase the business value creation that it brings to the organization. And we'll talk more about that as I go through my talk, the incubation zone is where it is exploring, identifying validating and testing next generation products and technologies that can improve the competitive performance of the organization and enable them to transform as a business into a digital enterprise. One of the things that I was really happy to hear was Don Parker.
The CEO of American airlines was asked the question, you know, who is responsible for Brit business organization and his company. And he said, everyone, especially the executives. And the key point to closing this gap is you can't be, you can't transform your business using digital technology without having it playing a central role, not only in implementation, but in the strategic design of what that new business looks like and how that technology will be deployed. And the final zone is the transformation zone. And this is where, as I said before, the original intent of my brother's book was if a company wants to launch a net new business that represents a minimum of 10% or greater of your overall revenues, this is a major transformation effort, and everybody in the organization has to align behind it, but particularly it, because in many cases it will be technology that is helping drive and scale this new business.
And so, again, what this framework is designed to do is to present a much more robust and complete picture of the total business value that it can bring to an organization, not just maintaining systems of record, but again, as I said earlier, when we looked at that, uh, resource allocation, we have to address changing that ratio of where you spend your time and your money. And we'll get into that in just a minute. So there's some very good use case, early use cases of companies that have actually deployed this framework. And one of them when Santo developed and launched a data analytics platform called science at scale to run simulations against millions of data points on seed genetics, climate, water, soil, and nutrients, the platform leverages Amazon web services and Google's TensorFlow machine learning application to reduce the time to run simulations from months to minutes, thereby increase in revenue by 17 million.
So as an example of a direct contribution from it to the performance zone in generating revenues for the organization, another example, which I think is really relevant to this community is in the work I did was Splunk. The group I worked with was the business applications team. And when we came in to the work, the team, the development teams were organized around different software stacks. So Salesforce, net, suite, Workday, et cetera, and they didn't have any direct interaction with their internal business partners. So we just mailed that structure and created Chris six cross-functional teams and assigned each team to one of the internal business partners. So it was the cloud business, it was the product teams, it was the revenue and marketing teams, et cetera. And just to give you an example of the immediacy of the impact, when we sat down with the chief revenue officer and the chief marketing officer, instead of bringing in an Excel spreadsheet of all the projects, where are they on the, on the roadmap and who needs to move it around?
We just asked the fundamental question, what is currently making it difficult for you and yours, your team to achieve the desired business outcomes that you're accountable for? And this year's plan totally open-ended that you know, where we are with projects. So the answer was, we found out that if you were a salesperson at Splunk, you had to open up five separate applications to get the total, uh, customer relationship that one customer had with all the different products and services. And so we created something called one click, one view and compress those from five down to one and apparently of about six months and turn an adversarial relationship with a partner into a true collaboration and actually one who advocated for us. So two good performance zone use case examples with Monsanto and Splunk in terms of productivity use case examples. AIG is really, I think a very good one on recovering crab value and redeploying it.
They deployed five virtual engineers inside their infrastructure to collect and analyze system performance data. A typical network network outage would go into the queue and take engineers three and a half hours to address using virtual assistance. Most outages were fixed in 10 minutes and over the first year returned 23,000 hours of trapped value back to the company. And what a good example is admins. And this is one of my favorite stories because it speaks to a lot of what the unicorn project really was talking about and how the red shirts finally said enough is enough. When the CIO of Edmonds came in about six years ago, he had inherited a Oracle ERP license and maintenance contracts that was costing the company $2 million a year. He and his team went in and looked at that contract and assess the fact that they were getting about $500,000 worth of value out of it.
So they went back to Oracle, said, we need to renegotiate the contract and we want, you know, we want, we're not using all of it. And Oracle basically said, go pound sand. So instead of saying, well, are we can do what the CIO did is he went to the CEO and said, I need half a million dollars. And the CEO said, went for, and he says, I want to take my best developers. And I want to pay them on their own time, over and above their day job to develop our own ERP system. The CEO said, how long is this going to take? Well, I don't know. It could take 12 months nine. Well, we don't really know. Four months later, four months later, they released their own ERP system, which had 80% of what they needed. And they went back to Oracle and told them to take a hike.
So I think it's a great example that when you understand the value that it brings, you don't have to be held hostage by vendors and, and, and onerous contracts that deliver more than you need or want. And I think this, again, as I said, is a terrific example of that. So if we look at, um, the, uh, incubation zone use cases, union Pacific was, this was a real surprise for me because I wouldn't see that normally as somebody who was particularly innovative, uh, but they created and launched something called P S technology, a separate commercial technology business to sell the digital technology apps. The company had originally developed for its own use, and they sold them to partners and even competitors as a result, they are now one of the largest providers of locomotive simulation systems, which has generated $50 million in new revenue for the company.
And finally, Raytheon is another really interesting example. They moved from using software as a business enabler to treating it as a new business growth opportunity. Starting back in 2007, they began partnering with, with and acquiring cybersecurity software companies. This created a new business unit with its own P and L called Forcepoint and service to CEO, Tom Kenny's vision that quote with the internet of things, cyber is pervasive in everything we do. The entire globe has become essentially a cyber economy. And this has driven a lot of the new revenue opportunities for that company. And let me finish is finally in the transformation zone with the Microsoft example, and this makes two points. It makes the point of how hard it is to free a company's future from the pole of his past, and how significant of a change you could make if you're successful in doing it.
When Steve Balmer succeeded bill gates in 2000 as the CEO of Microsoft, the company stock was trading at 2000 at a $40 a share 14 years later when Steve Balmer stepped down as CEO, the company's stock was trading at $40 a share. Now you may be thinking to yourself, how is that possible? This is a company that was generating free cashflow. Like there was no tomorrow. Well, the problem was when they did their annual planning and resource allocation, or they went through the discussions and before they got very far along 95% of all resources and budget were either allocated to windows or office. So they didn't have the discipline to be able to privilege a new investment opportunity over the existing businesses of windows. And when Satya Nadella came in in 2014, the first thing he did was he said, Microsoft is now going to pivot from an on-premise on desktop business model to a cloud first mobile first business ball.
And in doing that, he looked at the three core businesses in the performance zone of which office had windows were too, and said, they're under existential threat from the Amazon Facebooks, Googles and apples of the world. We need to reboot them. And so he took them one at a time from the performance zone into the transformation zone, shifted them from on-premise on desktop to cloud first mobile first. And the stock now is trading north of $220 a share the point being is that, and that's, that's an extreme example, but it's a very clear example. And he used the forest zone model framework as his foundational framework to manage that whole evolutionary or transformational process. So again, it's an example of how the sort of vibrancy of the liability of this framework and the practical way that you can apply it and get very significant results.
My final slide. Now we'll give you a look at what those metrics might include. And what we did in this case was each one of these zones has its own charter, its own operating culture and its own metrics. So the performance zone really has what we call investor metrics. It's all about generating revenues, margins, and profits. And if you're a publicly traded company, it's what the market looks at quarter after quarter is how well you're doing. So productivity zone is really measured by process metrics. How well can we optimize the cost of maintaining systems that record, how compliant are we? Have we been able to reduce our technical debt? You know, what's our net promoter score, all those kinds of things there. And then the incubation zone is where we really think about these as what we call venture metrics. So think about what a startup does when it begins to look at how it develops and deploys and drives adoption and utilization.
And then finally the transformation zone is these are what we call hyper-growth metrics. And here are the key is, as I said, because it's for a transformation initiative, a project to work, okay. It takes a lot of sacrifice for the rest of the organization. So it has to be something that has a significant return. And our threshold is 10% of greater overall revenues. And the key takeaway here is, and the mistake that most companies make and why most innovation initiatives fail is because they'll use performance zone metrics to measure incubation zone initiative. That is a mistake you do not want to make. And if you can, if you can segment your metrics, the way you segment your investments and your operating thing, you will get much better results. Thank you very much. And I look forward to the Q and a.