Prototype your role: Lessons-learned from building Design Research at Segment
About 6 months ago, I joined Segment as their first design research hire. The company has a strong culture of learning from customers, but I’d been challenged to build up the research function from scratch and take Segment’s customer obsession muscles to the next level 💪.
Every day I learn something new about the challenges of creating your own role and team. The experience has cemented a point-of-view I’ve kicked around for a while now: the importance of prototyping your role. We constantly test and iterate the products we launch — why not iterate and evolve how we work to be more effective teammates and take control of our own careers?
It might sound a little meta, but bear with me. Whether you’re starting a new function at a new company or looking to evolve the role you have now, here’s a few lessons-learned to get you started.
1. Discover the opportunities.
As designers, we love to take a step back from our solutions and ask ourselves: “what are we solving, really?” Why can’t the same apply to our own role itself?
I knew my first month at Segment would be filled with lots of 1:1s with new team members and stakeholders, sitting in on team meetings, and observing projects already in flight. To make that time as insightful as possible, I turned the process into an actual research project — I interviewed and observed to understand how teams were already getting customer insight today, and synthesized the biggest pains or gaps. Then I shared what I learned back with to the teams, and used those insights as a way to ground the mission for my role moving forward.
By taking a step back, I was able to identify new opportunities for my role I wouldn’t have expected from the original job description. You might be thinking this sounds like the luxury of someone totally new to a company, but I’ve observed teammates both at Segment (and in my previous life at Intuit) do the same — approach each 1:1 as an opportunity to gain insight, keep your eyes peeled for pain points across your org that you’re excited to solve, and build rationale for the changes you want to make to your role as you would with any design project.
2. Find the right place to experiment.
In design and product development, what comes next when we have an idea? We prototype it and pivot as needed. How can we bring that experimentation mindset to how we actually work?
For me, starting something from scratch was thrilling (the world is my oyster!) but also overwhelming (where do I even start?!). I was nearly paralyzed thinking about all the opportunities for a first project and all the initiatives could implement. But then I remembered the words of my previous manager and mentor Lionel Mohri at Intuit: “jump on the train that’s moving”, and looked around for a high-momentum project where research could add value and get a quick win.
The lesson-learned: if you want to experiment with a new process or role, jump on a project that’s already in the works where you can apply the change you hope to create. Look for something with good momentum where you know you can have impact. You can either be explicit about experimenting — “hey, I’d love to try out this new way of doing things here” or go inception-style. But treat it like an experiment — track what’s working or not working, pivot quickly, and carry what’s successful into V2.
3. Never stop prototyping.
There’s a hard but exciting truth in design — you never will reach a perfect solution. The second you solve a need, a new one emerges. The same goes for the “hows” of doing our job — we often dream of implementing the perfect role or the perfect team process, but the reality is our environment and needs are ever-evolving.
Starting a function from scratch brings the responsibility of defining process. The most common questions from people around me are all about the how: “how does research work with other teams”, “what’s the process for picking projects”, “have you defined a best practice for x”? And I’ve been tempted to have all the answers — after all, defining a process would make me feel productive (not to mention help me look legit). But instead of getting caught up in the how, I try to focus on why my role exists. If I’m doing good work, and prototyping the change I want to make in each project at hand, the right “how” will follow.
6 months in and I’m still prototyping. I try new things and scrap what fails. I ask for feedback with a survey after every project, and keep my eye out for new spaces my role can stretch. And honestly, I hope I never find the perfect solution — because the more I experiment with my role, the more I learn about myself and what I want from my career. So next time you are craving change, jump into it and start experimenting — don’t discount the change you can design for yourself.
