Influencing product direction and changing the minds of cross-functional partners
All my Microsoft stuff is under an NDA. Instead of showing a full-blown case study, let me tell you an interesting story.
You don't need to understand any of the other jargon and terminology to follow along with the story. Explaining those is not my goal here.
I work on a product called Azure Active Directory.
An identity and access management system. Some simple use cases are if you want multi-factor authentication for your cloud app or you want your employees to have Single Sign-on for all their apps.
Project Workload identities: context
For one of my first projects at Microsoft I got handed a list of simple requirements: "we have this new thing called Workload Identities, it is important because it affects the licensing of the product. Hence we want to have a new page to frame the new value. We have some ideas about content and where to surface that page within the product Information Architecture".
For one of my first projects at Microsoft I got handed a list of simple requirements: "we have this new thing called Workload Identities, it is important because it affects the licensing of the product. Hence we want to have a new page to frame the new value. We have some ideas about content and where to surface that page within the product Information Architecture".
Influencing product direction and changing the minds of cross-functional partners
All my Microsoft stuff is under an NDA. Instead of showing a full-blown case study, let me tell you an interesting story.
You don't need to understand any of the other jargon and terminology to follow along with the story. Explaining those is not my goal here.
I work on a product called Azure Active Directory.
An identity and access management system. Some simple use cases are if you want multi-factor authentication for your cloud app or you want your employees to have Single Sign-on for all their apps.
Project Workload identities: context
For one of my first projects at Microsoft I got handed a list of simple requirements: "we have this new thing called Workload Identities, it is important because it affects the licensing of the product. Hence we want to have a new page to frame the new value. We have some ideas about content and where to surface that page within the product Information Architecture".
I was relatively new to the team and didn't know too much about the domain, the product, who is who, etc.
A super junior PM who was even newer than I was, that was their first PM gig, first time at a big company, first time working in the Identity domain. They got to do the bulk of the PM work on this project as their first task.
A super senior PM who's been at Microsoft for 20+ years, knows the domain in and out, knows the product in and out. Also super busy and a single parent, which made the communication difficult. They are a dotted manager to me and manage directly the super junior PM which made it hard to push against their opinion.
Other teams couldn't do their thing until our work was done. This includes data and front-end engineers but also other teams who's work depended on releasing our project.
I was relatively new to the team and didn't know too much about the domain, the product, who is who, etc.
A super junior PM who was even newer than I was, that was their first PM gig, first time at a big company, first time working in the Identity domain. They got to do the bulk of the PM work on this project as their first task.
A super senior PM who's been at Microsoft for 20+ years, knows the domain in and out, knows the product in and out. Also super busy and a single parent, which made the communication difficult. They are a dotted manager to me and manage directly the super junior PM which made it hard to push against their opinion.
Other teams couldn't do their thing until our work was done. This includes data and front-end engineers but also other teams who's work depended on releasing our project.
Main stakeholders
Some people on the broader team (data engineers, PMs on related projects) were talking about Workload identities as if they were one monolithic offering. They would say, for example, 'Workload identities provides additional functionality to Conditional access".
Others however were talking about Workload identities as if these were objects with their own modifiable properties. They were talking about "Conditional Access for Workload identities".
Some people on the broader team (data engineers, PMs on related projects) were talking about Workload identities as if they were one monolithic offering. They would say, for example, 'Workload identities provides additional functionality to Conditional access".
Others however were talking about Workload identities as if these were objects with their own modifiable properties. They were talking about "Conditional Access for Workload identities".
Some people on the broader team (data engineers, PMs on related projects) were talking about Workload identities as if they were one monolithic offering. They would say, for example, 'Workload identities provides additional functionality to Conditional access".
Others however were talking about Workload identities as if these were objects with their own modifiable properties. They were talking about "Conditional Access for Workload identities".
During the first project kick-off meetings I started to notice how people used a slightly different language to describe what we were working on…
But why?
Why introduce new / additional terminology?
I wanted to understand the business reasons behind all this. And they are quite good actually:
align with the broader industry (e.g. Google uses the term Workload identities). That, and increase the Gartner rating of our product - Gartner loves fancy new jargon!
I wanted to understand the business reasons behind all this. And they are quite good actually:
align with the broader industry (e.g. Google uses the term Workload identities). That, and increase the Gartner rating of our product - Gartner loves fancy new jargon!
Context:
This is the Azure portal. To launch the product that I work on, one has to click on the Azure Active Directory icon above.
Pan right >
This is the Azure Active Directory overview page.
Via the left nav the user can navigate to each area/section of the product.
The initial idea was to include a Workload identities page under the Enterprise applications section.
(remember, confusingly, Enterprise apps = Service principals)
But that didn't make sense to me:
If Enterprise applications (service principals) are a subset of Workload identities, then introducing a Workload identities page under Enterprise apps would make no sense.
Context:
This is the Azure portal. To launch the product that I work on, one has to click on the Azure Active Directory icon above.
Pan right >
This is the Azure Active Directory overview page.
Via the left nav the user can navigate to each area/section of the product.
The initial idea was to include a Workload identities page under the Enterprise applications section.
(remember, confusingly, Enterprise apps = Service principals)
But that didn't make sense to me:
If Enterprise applications (service principals) are a subset of Workload identities, then introducing a Workload identities page under Enterprise apps would make no sense.
So what did I do?
I resorted to PowerPoint — the tool all Microsoft PMs live in. I created a number of decks that illustrated and made my arguments on what the problems are, how to go about them, where I disagree with other proposals.
Turns out, some people thought of Workload identities as the same things we already call Service principals.
Others thought it is an umbrella term for both Service principals and App objects.
Then there are these things called Managed identities that are a subtype of Service principals, did that make them a subtype of Workload identities, too?
To make matters worse, the terms Service principal and App objects are used across the product APIs, CLI and external documentation, but practically never in the GUI for historical/legacy reasons.
The short-term result
In the short-term, I managed to convince the team to work on a flexible solution (can't show it, NDA) that would not introduce further IA complexity, and would introduce the new jargon more carefully.
Nobody was 100% happy, but we found a way not to make matters worse until a more broad, cohesive fix is available.
In the short-term, I managed to convince the team to work on a flexible solution (can't show it, NDA) that would not introduce further IA complexity, and would introduce the new jargon more carefully.
Nobody was 100% happy, but we found a way not
In the short-term, I managed to convince the team to work on a flexible solution (can't show it, NDA) that would not introduce further IA complexity, and would introduce the new jargon more carefully.
Nobody was 100% happy, but we found a way not to make matters worse until a more broad, cohesive fix is available.
The long-term result
I convinced key stakeholders, beyond my immediate team of 2 PMs that we need a major overhaul of the current Apps user experience. And By that I mean the end-to-end experience across GUI, API, CLI and the documentation. The initiative is only just beginning but is already gaining traction.
My role in this process is to make sure that there's a common understanding of each concept that we have and how these concepts relate to one another. Then I will drive the effort to surface each concept in each interface in a consistent common sense manner.
I convinced key stakeholders, beyond my immediate team of 2 PMs that we need a major overhaul of the current Apps user experience. And By that I mean the end-to-end experience across GUI, API, CLI and the documentation. The initiative is only just beginning but is already gaining traction.
My role in this process is to make sure that there's a common understanding of each concept that we have and how these concepts relate to one another. Then I will drive the effort to surface each concept in each interface in a consistent common sense manner.
I convinced key stakeholders, beyond my immediate team of 2 PMs that we need a major overhaul of the current Apps user experience. And By that I mean the end-to-end experience across GUI, API, CLI and the documentation. The initiative is only just beginning but is already gaining traction.
My role in this process is to make sure that there's a common understanding of each concept that we have and how these concepts relate to one another. Then I will drive the effort to surface each concept in each interface in a consistent common sense manner.
"This is exactly the type of conversations I want to have with UX!"
The Super-senior PM
Who is also my dotted-line manager
"There are not a lot of designers that can go toe to toe with PM on the technical stuff!"
The Super-senior PM
Who is also my dotted-line manager
"This is exactly the type of conversations I want to have with UX!"
The Super-senior PM
Who is also my dotted-line manager
"There are not a lot of designers that can go toe to toe with PM on the technical stuff!"
The Super-senior PM
Who is also my dotted-line manager