Who is the user in the enterprise world?
Journaling my experience of the first few months in enterprise research at Microsoft Design
It’s been six months since I joined Microsoft Design remotely. I found myself in uncharted waters, as I have never been a part of an enterprise product. I have conducted remote research in the past years; however, times are unprecedented, and COVID-19 made this the only viable approach. With little to no experience in enterprise research, I embarked on this journey to understand how enterprise products work, position kick-start research in the new team.
Understanding The Enterprise System
In my first month of joining the Microsoft Bookings and Outlook Team, my first priority was understanding the products. Outlook being an enterprise and consumer product, it was easier to understand. However, I couldn’t fathom how even to start understanding Microsoft Bookings. By the face of it, it looks easy in theory. But if you include it in an enterprise context, it gets pretty complex.
I realised understanding the domain within a month is impossible; hence, let’s learn in increments. To get me up to speed with Bookings, I utilised all the in-house channels. There were many resources available for me to read, but the work didn’t end there yet. A lot of reading led to many questions, and my stakeholders then answered these.
The design team were the first folks I was introduced to at Microsoft, and talking to them felt the most natural thing. They were kind enough to walk me through the product and explain the platform. This gave me a fantastic foundation to build my knowledge on.
I also understood that there is no one user in the enterprise world, but multiple facets of users. The product that you are working on is bought by an organisation, not by an individual. Multiple organisations from various industries use your products for different needs. These needs vary on the type of industry, the size of the organisation, and the team in the organisation that is using it.
We then have the decision-makers, aka the buyers in the organisation. Depending upon the organisation, the person who takes these decisions may vary. Their need is configurability, compliance, and the number of features. However, buyers rarely use these products. The end-users are the ones who use enterprise products on a day to day basis. Their need is to get stuff done effectively. I realised that it is essential to conduct research both with the buyer and the end-user; however, the methods may vary basis the profile.
Then I met the product managers to understand the know-how of how the product and business were doing. The product manager helped me fill parts of the story that I have been missing and helped me gain a complete understanding. I also understood the product metrics that we are tracking and the ones that we can’t. I understood the product pipeline, the things in motion and what to expect next.
This gave me a great perspective on where all can research contribute to and the next steps.
Understanding the product didn’t end there. I also skimmed through the tech community channels and feedback channels to get a sense of how the product was doing. There was a wealth of information about the current problems users were facing and feature requests. This helped me a lot to gain domain knowledge expertise.
Baby Steps into Research
I was quite intimidated initially to start my first research. But research is research, isn’t it? I assumed that I could run studies like consumer research; however, it wasn’t that easy. I was still learning about the domain and needed to gain the trust of my stakeholders. I decided to conduct the first research narrow in scope.
I planned my research in such a way that I was focussing on one specific problem/area of the product. This helped me to keep my conversation centred around the scope of research and to build on my existing knowledge.
I was prepared to be lost during various phases of research. I knew that there would be a chance that I may not understand what the participant is speaking about. And yes, that may lead me to ask naive questions. But it’s better to understand concepts in a simpler fashion than not understand them at all. I was not as lost as I expected to be due to the amazing team of designers I worked with. They are an enthusiastic bunch who love getting involved in research. My first research experience was a smoother proceed due to the conversations and feedback session that we had.
A lot of things helped me to reach the stage of taking bigger bets in research.
Gaining my stakeholders’ trust was one of them. Being proactive and listening to what they had to say about the product, the current processes, and their thoughts about research gave me a good understanding of where they stood. Taking that into context, scoping out Quick Wins Research helped me and the team to streamline some of the pending work.
Further, making the research insights actionable made it easier for the team to incorporate them in the ongoing work and made them curious about what more research can do.
I also conducted few brown bags to evangelise research within the team. This helped a lot in gaining the team’s trust.
It is difficult recruiting the right users in the enterprise world. I experimented on how can I recruit all kinds of users easier. Setting up a user panel, looking at alternative methods and also taking help from recruitment vendors were some of the steps I took towards this goal.
All these efforts for the past six months brought me to a stage where now I can propose foundational research to the team. The team is quite willing to listen and see how can the research be made better. Taking those bigger bets is still intimidating, but it’s a marathon and not a race. This journey has been quite an interesting one, from feeling out of depth to finding my way.
Have you been working in a new domain? I would love to hear your stories of how you made your way through. What approach did you take? What advice would you share with newbies?