What I Learned in My First 90 Days
I started my new role at Square a few months ago. Here’s how it’s been so far.
Hey there! I’m Nicole, and I’m a product designer. I write this newsletter to share my experiences and lessons learned through my work as a product designer.
As it was my first time starting a new role remotely, I wasn’t sure what to expect.
Since the pandemic began, starting a new role is different. There’s no daily triathlon of driving, taking BART, and trudging on foot through a labyrinth of streets and intersections. There’s no brawling through a tangled mass of backpack-laden, iPhone-clutching commuters. There’s no waiting in line to order coffee, buy lunch, or use the bathroom. Now, all these things rest within arms reach, or at the very most, a few strides across my apartment.
Instead, on the morning of my first day at Square, I sat at my dining room table and opened my new laptop. Inside, a neatly typed page of instructions details the process of logging in for the first time. Clipart of a computer cheers me on from the margin. Together they lead me to my email, where I find my calendar, dappled with a few events throughout the week. An email from my manager greets me in my inbox. I read it and write a reply: I’m getting set up, and I’m excited to get started.
✷
I met with my manager later that day. Together, we looked over my onboarding plan:
Orientation sessions, to introduce new hires to the company, culture, and resources
An onboarding guide, to cover the basics of my role, like who was on my team, how I could get promoted, and how I should set up my Figma
Onboarding sessions with my manager, to dive into specific areas of my work
It seemed simple, but over the coming weeks, this onboarding plan quickly took on the rigor of a crash course. Human resources led the orientations, lecturing on the company’s humble origins (starting as a point of sale device) and steady evolution (to a platform-based ecosystem). Executive assistants distributed literature detailing the leadership structure. Then, guest lecturers from across the curriculum were brought in: I had introductory meetings with product marketers, product managers, engineers, and designers, each person summarizing their own subject matter and vast portfolio of projects. But my manager, tenured in his time at the company, had prepared the most interdisciplinary education of all. In a three-part series, he unpacked each of our product areas: painting historical context, inserting commentary and critique, and envisioning the future that could be.
Finally, after several weeks — I had attended the orientations, completed the trainings, read the handbooks, studied the material, and met all the people — I naively thought I was done. I graduated from onboarding! Armed with my newfound knowledge, I was ready to take on my role.
But with each step forward, I’d run into obstacles. There were small ones, like an acronym I couldn’t decipher or a design file I couldn’t locate. When these obstacles blocked my path, I’d reach for the quickest solution: I’d ping my manager or scavenge through Figma. While it was inconvenient to stop what I was doing, I’d soon find what I was looking for. The obstacle was easily cleared, and I was happily on my way.
Other obstacles, however, proved more difficult. Some appeared simple at first, like a question that seemed straightforward, but as I chipped away it would unravel layers of unknowns. Some involved many disparate parts — a tangled mess of past decisions, constraints, and context — and required the consultation of different people, timelines, and documentation to make sense of them. But despite my best attempts to piece things together, there was too much I didn’t know. The obstacles were too substantial; they refused to yield.
I realized I needed to change my approach. Resolving to get ahead of the obstacles, I decided to create a learning plan for myself:
Each day, I dedicated time to reviewing previously learned information or learning new things. I read documentation, kept up with company news, browsed conversations in Slack, and attended various meetings — even those outside of my usual schedule. By the end of each day, I’d pin follow-up notes to my list: interesting or unknown topics, questions, or ideas that had bobbed to the surface. These waited to be tackled the following day or whenever I had time.
For items that seemed especially important for my role, like team metrics, roadmaps, or current projects, I kept them bookmarked and revisited them every few days, until I felt comfortable with and even knowledgeable about the material.
Each Friday afternoon, I set aside 30–60 minutes to jot down reflections of the past week. Things I’d discovered, things I still didn’t understand, or what I wanted to learn more about. These could be reviewed Monday morning to provide inspiration for the following week.
In each of my 1-1’s with my manager, I budgeted time to ask a few questions for topics that required special attention. Things I couldn’t find information on elsewhere, or things that I wanted opinion, commentary, or backstory on.
I soon found that this slow and steady approach supplemented the introductory knowledge I gained during onboarding. Over time, it superseded it entirely. I found myself retaining more information and managing the learning process more naturally. Even better, my knowledge was now informed by the ever-evolving landscape of findings, discussions, and decisions that are made daily in the product development process.
But this approach had a shortcoming: you can only delve into the information that’s currently available. Something was still missing, and I found myself getting stumped by the same kinds of obstacles which, as it turns out, often stood in my path of being able to make effective design decisions.
✷
User research should be a vital component of onboarding, especially for product design roles. But it’s harder than it sounds. To present user research to new hires, it needs to be packaged neatly enough for someone with no context while still maintaining its inherent humanity. Even the best-intentioned artifacts, like personas or journey maps, lack a warmth that can often only be felt by those directly involved in the research.
Anecdotally, we knew basic things about our users: who they were and what they wanted to do and why. But beyond that, and more specific to my own product area, we didn’t know much more. This lack of awareness had short-term consequences: it was hard to feel confident that we were making the right decisions, whether with designs, project scope, or prioritization. And it also had long-term implications, as our roadmap needed informing, and inspiration, on what efforts should be slotted in. For these reasons, I wanted to conduct some research of my own.
In many ways, the effort was a final test of how effective my onboarding had been. Contributing to the collective knowledge requires answering the question: based on what we currently know, what do we need to know next?
So to get started, I applied what I had learned up to this point. In my onboarding travels I had discovered where most teams store their research findings; now, I revisited this to understand what was still left unanswered. I had previously been blocked by not knowing enough about our users; I returned to these obstacles and searched for clues to pursue further through the research. As for the people I’d met along the way, I now joined forces with them to rely on their expertise in shaping the research effort and to understand how it could be designed to benefit their work.
By the end of my investigation, we mapped a clear plan forward. We knew what our research should look like and what it should accomplish. We knew what users we wanted to study and what we wanted to learn from them. Most importantly, we answered both sides of that knowledge equation: what we currently know, what we don’t know, and what we should pursue next.
From my first 90 days, one takeaway was clear: getting involved in research, and leading it if possible, is the best way to get deeply acquainted with your product domain.
I hope you found this newsletter helpful! If you’re interested in reading more, subscribe here for free and share it with a friend. You can also find me on Twitter (@wontonface).
Have a topic idea or request you’d like me to cover? Submit it here.