Reflections from a designer turned product manager: 6 unexpected differences
Two years ago, I transitioned from design to product management (PM). After 10 years as a designer, from interning to managing a team, I felt unexcited by the management path ahead of me. I missed the deep product work I used to do as an individual contributor. I also felt frustrated when I wasn’t involved with the “big decisions” PMs made, such as canceling a product line or choosing a new strategic direction.
I’ve always found “why” we’re building something as interesting as “how.” To put it another way, the problem-setting was as important to me as the problem-solving. This part of the product development process was often owned by PMs, not designers.
Prior to the transition, I didn’t find any tactical advice from other designer-turned-PMs. Now having pursued both, though admittedly design for much longer, I’d like to share my reflections on how the two roles feel different on a day-to-day basis.
6 differences between being a designer and PM
1. Typical week
As a designer, the majority of my week was unscheduled. With the help of my PM and design manager, I could protect my “maker’s schedule.” Almost every day, I had a 2–4 hour chunk for “deep work”, as Cal Newport defines it, time “to focus without distraction on a cognitively demanding task.” I also had the flexibility for midday walks to noodle on a problem and spontaneous lunches with coworkers. On an average week, about 80% of my calendar was unscheduled, and 20% was scheduled.
I had the opposite as a product manager — 80% was scheduled and 20% was unscheduled. As a front-line PM, I went to all the product-delivery meetings that come with the agile software engineering process: stand-up, sprint planning, sprint kickoff, and retrospective. To stay on top of client requests, I also met biweekly with customer success and sales. Additionally, one-off events like client presentations and planning workshops would appear on my calendar throughout the month. To attend all these meetings while also getting my own work done, I needed to ruthlessly manage my time.
One benefit of having the title of “product manager” is that you can invite yourself to any meeting and “have a seat at the table” — something designers often yearn for. But you lose your uninterrupted time by going to all those important (and some unimportant) meetings. It’s much harder to get into the flow states needed to solve gnarly problems.
2. To-do list
As a designer, I started my day with a short to-do list of 3–5 items. This might include “review sign up flow with Ben” and “create prototype for Thursday’s user testing.” On most days, I simply went down the list and got things done as planned. Sometimes tasks took longer than expected, but my list didn’t change much throughout the day.
As a PM, I had an ever-growing to-do list with changing priorities. The challenge was choosing the most impactful thing to focus on. For example, one day I had planned to write a product brief for a new initiative, to unblock my designer. At standup, I heard that last night’s deployment broke our sales demo. Fixing the demo before the next client presentation was now my top priority.
As a “firefighter”, PMs are subject to a lot of context switching. You’ll often leave a product strategy meeting, where you’re discussing projects for the next quarter, and head straight to a developer’s desk to help QA a feature that’s ready to ship. For some people, wearing so many hats is refreshing and keeps things interesting. But for me, I found it challenging and exhausting.
To keep my daily stress-levels under control, I needed to do a better job managing my to-do list. I started to use the framework Eliminate, Automate, Delegate:
- Eliminate: Are there any unnecessary tasks that can be completely eliminated?
- Automate: Which repetitive tasks can I automate to save me time in the future?
- Delegate: What tasks can I delegate to someone else who can do it better, or to save me time?
3. Chores
Every job has chores. I define chores as those routine tasks that you might find unpleasant, but know are necessary.
As a designer, my main chore was making design specs. This involved creating mocks, figuring out each state, and documenting functionality for engineers. This can take a lot of time because you need to be a stickler for details — not just aesthetically, but also in terms of functionality. I spent a lot of time sweating over choices, like using the word “Cancel” vs.“Close.”
As a PM, I had a much longer list of chores. Every other week I wrote up release notes for the company, product updates for the founders, and sprint goals for the engineers. I also regularly groomed the backlog — reviewing and prioritizing a list of client escalations, bugs, and old tickets.
Teams divide up chores in different ways. Some companies have product specialists or program managers who take things off the PM’s plate. Sometimes engineering managers share the load. From my experience though, PMs do more chores to protect their designers’ and engineers’ time.
In general, a designer’s chores require more focus to go into design details. A PM’s chores require communication and project management finesse to hold together a high performing team. To get a gut reaction of whether you should be a designer or PM, I like to ask “What feels like a chore to you?” Ideally, your chores don’t feel like chores.
4. Team
As a designer, I considered myself part of two teams. The first was my product team: my PM and engineers. This trio is often called the three-legged stool because product, engineering, and design need to work together to stand up a great product strategy. I’ve always felt a close camaraderie with this type of team — a camaraderie that only comes from the ups and downs of building a product together.
My second team was my design team, the peers I sat next to on a day-to-day basis. This allowed us to bounce ideas off each other even if we were working on different projects. I felt a close kinship to designers through our shared ethos and way of thinking — design was my tribe.
As a PM, I was still part of that same product team — just a different leg of the stool. However, I learned that as a PM, your product team is larger. It includes other cross-functional groups such as customer success, marketing, support, and sales. As a PM, I was responsible for not only the user’s experience, but also the business performance of the product, and this required working with a lot more stakeholders.
A PM’s “team” varies by the size of the company. At larger companies, PMs may work with peers when there are multiple PMs in a business unit. At smaller startups, PMs may work closely with the founders. However, PMs are usually the only PM on their team, which can feel isolating and lonely at times. They spend the majority of their day working with different functions, whereas designers spend most of their day working with like-minded designers.
5. Process
I was first introduced to design through innovation design consultancies. At IDEO I learned the 5-step design process: empathize, define, ideate, prototype, and test. At frog design, there were three types of projects: discover, design, and deliver. Through these experiences, I’ve cobbled together my own point of view on the design process. As a designer, I was always focused on understanding the problem, defining the scope, exploring ideas, testing hypotheses, and delivering prototypes. My project ended after I delivered the specs to engineers, and I was promptly whisked away to a new one.
It wasn’t until I became a PM that I saw how the “design process” was only a small part of the product development process. Discovering and prioritizing which problem to solve happens before the team even brings on a designer. Handing off design specs to engineering is only the start of building something. And although often overlooked, measuring the impact after a release is one of the most important parts.
As a PM, I juggled multiple projects at a time — usually in different phases of product development. For example, I might have been exploring ideas with my designer for one project, while QA-ing another with my engineers, in addition to monitoring analytics for the last three we shipped. Keeping multiple projects running in parallel required jumping between different product development phases throughout the day. This differed from design, where I was able to focus on one phase at a time, a consequence of working on 1–2 projects.
6. Communication
When I was a design intern at IDEO, I learned one of the rules for effective brainstorming was to “build on the ideas of others.” Borrowing a principle from improv, we used the phrase “Yes, and…” followed by something that builds on someone else’s idea. As a designer, I was often looked to as the “creative” or “ideas person.” I don’t believe in the idea of a“Lone Genius Innovator” though. Great ideas come from anywhere, and it’s a designer’s job to create a positive, open environment for ideas to come out. Designers look for opportunities to say “yes” — to turn a good idea into a great one. This doesn’t mean there isn’t room for critique though. Providing useful feedback is equally important to saying “Yes, and…”.
As a PM, I quickly learned to replace “Yes, and…” with “Yes, but…” or “No, because…”. Within my first month, I had to say “no” to a client asking for a competitor’s feature, “no” to an engineer wanting to rewrite part of the codebase, and “no” my designer trying to increase scope. Saying no was necessary to maintain the team’s focus on the goal at hand. Otherwise, we wouldn’t have been able to ship the features we agreed would deliver the most value.
The most effective product managers say “no” 10 times more often than they say “yes”. Personally, I found saying “no” that often draining. I spent a lot of energy finding the most persuasive way to say “no” to each stakeholder, while hoping that wouldn’t damage our relationship. Sometimes that meant saying “not now”; other times it meant pitching why we’re doing something else instead. It was important for me to maintain the respect and trust of my stakeholders because I knew I would need to work with them in the future.
Both designers and PMs need to encourage other people to bring up ideas and requests to them, while also being able share contrary opinions. The key difference is that PMs have to say “no” by default. The essence of executing a product strategy is choosing what not to do. Designers, on the other hand, are expected to say “yes,” and approach problem solving with a positive can-do attitude.
Conclusion
A common reason designers consider switching to product management is to “get a seat at the table” to have more control over product strategy. I myself was one of those designers. And honestly as a PM, I did have more control and a larger scope of influence. I got access to more information, worked with more people, and managed the end-to-end product development process.
But with that came tradeoffs. I no longer had the time to work in flow states, focus on detailed designs, or enjoy a flexible schedule. Self-managing my calendar and to-do list became essential, as well as working in mode of constant context switching. What was hardest for me though, was shifting from saying “yes” by default, to saying “no”.
Although designer and PMs may work on overlapping tasks and with similar people, their day-to-day feels very different. In the end, whether or not you want to be a designer or product manager is a very personal decision. Only you can answer, “Which job do I do well, get paid for, and want to do?”
Before answering those questions, I needed to look inside myself to understand why I felt incredibly energized and fulfilled on some days, but stressed and drained on others. I believe that finding your “happy place” comes down to understanding your personality traits, because the truth is many designers could be great product managers with some training and skill acquisition. Here are some questions that might be helpful to answer before picking a role:
- What’s your ideal work environment? What’s your non-ideal?
- What’s your communication style?
- How do you like to be managed?
- What gives you energy? What drains you?
- How do you want to bring value to a team?
Regardless, I’m thankful that I had the opportunity to experience both. Although it was stressful at times, I think spending 1.5 years as a PM instead of 1.5 more years as a designer have made me a better designer in the long run. And who knows, for the right role or the right company, I might try being a PM again.
