One of the most impactfuiml changes we have made at Microsoft is to focus our engineering teams solely on usage and the customer experience of our services .

In all my years leading product teams, I have never seen something that has impacted the culture of an engineering organization more than this. These changes have been so incredibly positive that I want to share the details of what we did to make this happen. I have two reasons for doing this: 1) I know that many of you are interested in driving cultural change within your own teams and organizations and, perhaps, the work weve done may spark some ideas for you. 2) It may be helpful for our customers and partners to understand how we prioritize our work.

Revenue is a Lagging Indicator. Usage is a Forward Indicator.

For most of my career, we have looked at revenue as one of the key factors indicating the health of a product or business. The primary reasons we used revenue is simple: We didnt have much else to go on.

But now things are very different.

Previously we built products that ran without an attachment to the cloud so we never had telemetry telling us if what we built was being used or how it was being used. At the time, many of us could list the products and services we worked on that, on the surface, was considered healthy (using revenue as the KPI). In reality, we had no idea how many of our products were being used and/or what was the actual usage. This meant we could only guess at adoption rates, we didnt know if the services were meeting needs, and we had no idea if we were at risk of losing a customer because of the experience.

Then, along came the cloud. In a world of cloud services and cloud-connected services, our telemetry and usage reports give us a daily reality check. Is our usage growing? Is it growing steadily or accelerating? Being grounded in the reality of real usage patterns allows us to very deeply understand if what were delivering is what customers want and need.

Personally, the thing I love the most about these usage numbers is that they tell the truth. No spin. Just data.

Focusing on Usage

One big way we drove the cultural change around focusing on usage and customer experience was simple: Money. A little over two years ago we made a significant shift in how we rewarded the engineering teams at Microsoft. We changed the primary metric determining everyones annual bonus and stock awards to be based on achieving and exceeding usage targets. What this means is pretty straightforward: At the beginning of our fiscal year we establish usage goals for the year and share them with the team and, because, we have aligned compensation with usage, the engineering teams have made getting customers deployed their #1 priority.

This new setup leads us to start asking new questions and planning new ways to work that really help our customers: How can we simplify the user experience? Are we improving and/or validating the most commonly used configurations? How can we make things easier to troubleshoot?

We recently closed our fiscal year on June 30, and we significantly (and I mean significantly) overachieved our usage targets for Intune, Azure AD, and System Center ConfigMgr. Notably, ithe month of June alone we had 2M new Intune subscriptions activated and put into use. By any standard,

2M new devices coming under management in a 30-day period is a pretty incredible number.

We are just beginning our new fiscal year, and this week Ill send out the new usage targets to our teams. To give you a perspective of the kind of growth we are targeting for this year, we expect our usage (monthly active devices under management) to grow by more than 150%. A few days ago, in Microsofts earning announcement, one of the stats highlighted was the number of EMS customers growing 57% over the last year to more than 52k unique customers. This accounts for an install base of >50M licenses.

EMS is now, by far, the largest Enterprise Mobility solution in the market.

How this has Changed Our Org Structure and Processes

One of the key things to understand here is how we now organize our teams. The structure of the teams literally reflects the architecture of the services.

For example, many of you see Intune and Azure AD as two independent services. The reality is that, as we rearchitected Intune over the past 18 months, we deeply aligned the architectures of Intune and Azure AD. Each of the services is comprised of many micro services, and each micro-service can update independently of every one as long as they guarantee compatibility and an SLA. This is the reason why you see the incredible/unmatchable volume of innovation coming out in EMS. There are teams updating their micro services 10 times (literally) a day with improvements. These are not bug fixes, but new capabilities being previewed and rolled out.

Pretty incredible.

Because we are constantly experimenting and examining our data, we can see opportunities to improve and innovate faster than anyone else and this is a huge value to our users. This allows us to simplify things, improve the user experiences, and move very quickly to make these changes. If there is an issue blocking a deployment, we can quickly address it. The architecture we have so carefully built enables these continuous iterations and that enables a remarkable level of agility and response time to customers needs.

How this has Changed Our Culture

Typically, engineers and engineering team are hyper-focused on the new capabilities they are building. Their mindset is Its all about new features and everything else can fall by the wayside. In a culture where usage is the primary goal, the primary focus is on ensuring customers are unblocked and the product is constantly being simplified to make it easier and easier to use. This focus is so central to the work we do that it takes priority over adding new features. But dont get me wrong we love building new features and were adding them at an incredible rate.

Another big change most of the teams at Microsoft have made can be seen in the creation of new groups within the engineering orgs called Customer Experiences (CXP) Teams. These CXP teams are made up of engineers and program managers whose sole focus is accelerating deployments. We assign individuals from the CXP teams to every large customer and give that customer a direct line to the engineering org so that they can tell us what they need and we can support their progress.

Architecture Can Accelerate Cultural Change

This element of our cultural transition has been especially interesting to watch. Considering how much of what we build are now cloud services (and also that weve attached our on-premises products to the cloud), the architecture behind these services has itself been an accelerant to our culture change.

The fact that engineers can preview changes in a cloud service and get feedback almost instantly has been like adding rocket fuel to our goal of increased customer obsession and growth mindset. This enables engineers to form hypotheses and rapidly experiment to get a feature, or menu, or task just right.

I think human nature loves to celebrate victories and wins, and, in a world of cloud services, we are able to constantly celebrate small wins because this process of constantly experimenting and learning allows for fast iterations where you can see real progress to celebrate. This also builds confidence in the individual and the teams and it that tells them that any customer need, usage scenario, or stretch goal is reachable with enough data, testing, and intelligent iteration.

In other words, this whole process feeds on itself positively.

* * * * *

I absolutely love the work we are doing right now, and, even more, I love more the culture I see in my team and throughout Microsoft. I am having more fun now than at any other point in my career, and I am more confident than ever about what we are building and delivering for our customers.

After all, I see it in the usage numbers every single day!