As product people — here at Microsoft, we emphasize building on each other’s work and have a collaborative environment that makes everyone function at ease and ship products with excellent quality.

Microsoft is extremely customer-centric, and we have specialized customer solution teams who are always working with our customers, gaining continuous inputs, and providing insights to Product teams.

Regular product teams or triads or feature crews consist of program managers (PMs), designers & researchers, and developers.

I’m Pranava, a designer for Microsoft Teams, and I have been in Microsoft for two and half years now; and I have been a part of several feature crews in 3+ products. I’m about to tell you three stories of triad collaboration and what I learned from it. So, here goes:

Story 1

In the year 2018, I just had started as a designer. I was quite unaware of how triads functioned, and as newbies — we always learn on our jobs. So, the first month here — a PM sent me a “spec” and asked me to make high-fidelity designs of their “PM art.”

I kept questioning why I had to make high-fidelity mocks of mocks that were already present. And more importantly, I wasn’t convinced of the solution because I lacked context.

I was afraid to suggest changes, and each time I proposed a change — he always seemed to have an answer about why his approach was better. I hated to admit it, but there was no trust in this relationship to begin with. So, I conformed and did precisely what I was asked to do, and we shipped the designs.

A year passed, and I eased into my job. And, in 2019, many of us were neck deep into visioning work and would conduct several brainstorming sessions together as a team.

During this time, a deck I had casually sent to my manager as a design proposal got picked up as an essential item to do and was socialized amongst PMs and Engineering.

Soon, A PM started working together on the deck with me — (there was no one-pager, to begin with, the deck became the spec), and soon, it gained reasonable traction and momentum — several PMs were dropping comments. Soon this concept deck was further broken into 16 Features and had 16 Feature Crews working on it.

During this time, I learned how when PMs say KPIs or business value, we must be thinking about user value, and when they talk about features, we need to think about user needs.

The translation became more uncomplicated, and I provided my insights on planning, feature prioritization, product roadmap, and documentation. I loved how this PM emphasized shared ownership, and at the core, I think — we just trusted each other.

While immediate results were significant for both instances, the second approach’s long-term effects were more beneficial to the triad ICs (Individual Contributors). It brought in a strong sense of ownership for everyone involved. We learned from each other, and it improved the culture of the team.

Story 2

Hackathon 2019 — I was the sole member of one of the hack teams within Microsoft, and I thought I created this fantastic concept and did not bother to seek feedback from anyone, or maybe I was too shy to show it to people.

But, I was under the impression that it was an award-winning concept until, in the hackathon jury, I couldn’t answer any fundamental questions about the backend abilities or how this was useful for Microsoft. And, the jury showed me the door.

During hackathons, I think we as designers feel the need to create appealing proof of concepts because we believe products should ideally be about user needs, which is not completely false. But, we end up downplaying the value of expertise PMs and Engineers bring in with respect to business and technical requirements.

However, by Hackathon 2020, I realized that it was not so much about unique ideas but interesting people in exciting product spaces to collaborate with. So, I looked for people and jumped into a product space I had the least idea about.

I found like-minded people, formed a team; and, as a team, we evenly contributed to the brainstorming, ideation, feature analysis, detailed design mocks, an engineering prototype, and pitch video.

All of this in just 3 days. And this time, when the jury asked questions, I wasn’t alone. I had bright team members who had my back, and we managed to win the hackathon. And, that was not all — the hack project was picked up as a feature to build into Teams.

This taught me a lot about how we can leverage others’ strengths and how it can improve our perspectives. It taught me how potential for innovation lies in knowing the technologies available, adopting it efficiently and how engineering are essential parts of triads that make all our product dreams come to reality.

Story 3

Back in 2018, There was this developer who I used to sit next to, and we were a part of a feature crew. I was new, shy, and thought every conversation had to be documented. During the hand-off, I mailed him the ‘redlines’ every time there was a change in the design.

It was an iterative item that went through several loops for a long time. I would mail him every single change — “Hi, can you reduce the padding by 2px. Thanks, Pranava” instead of just communicating the change verbally and work together.

I felt we were very unproductive, and we ended up delaying the shipping cycle by a fortnight. And we were both frustrated with ourselves and with each other.

Time went by, and in 2019 — I think I had a year’s experience working in the team, certain processes had changed, conversations with peers became easier, and I had the opportunity to work with the same developer again.

But this time, maybe because of the tools we were using (Zeplin, Teams), suddenly we were communicating outside emails. We would walk up to each others’ desks (although he moved to another wing in the building) — to discuss design and redlines.

There came a time when we had to ship a feature in 2 days, and now that the developer and I had become good friends, he asked me if I could code the JSON that needed to go into the feature and gave me the confidence that this was an easy task to do.

So, the developer was patient enough to teach me, and we sat overnight, coded together, and shipped it on time.

As designers, we tend to stay away from the developers and code, we feel our job ends at hand-offs — but there was a great joy in being able to contribute and craft the product experience together. It brought a lot of clarity and quality as I understood constraints better. I learned how to design for scale by working with developers.

Learnings

Product, engineering, and design create product experiences together as individual contributors bring innovation, value, craft, and efficiency to the table. To sum it up, making products is almost like a team sport. And, great triads make great products.

Here are my top three learnings:

Learn everything you can and teach everything you know.
Please don’t stick to your job roles — go beyond.
Peer-Camaraderie makes products shine.