5 learnings of a Product Designer turned into a Product Manager

My transition started at the beginning of 2021 when I accepted to work as a Product Designer (PD) in a different context from what I was used to in other companies.

Instead of having a Product Manager (PM) on the team, the PM role would be fulfilled by the PDs and shared responsibility with the Head of Product. The teams were composed of a PD, a Tech Lead (TL), and Engineering (ENG). There was also a UX Researcher, a UI designer, and a tester collaborating across teams.

I saw this mixed PD/PM role as an opportunity to be more involved in business decisions, having more impact on the strategy of the product while still being close to the user experience.

Along with the change in the role, it was a fully remote company, with a team distributed globally. People from Singapore, Colombia, and other places worked in the same team. It was exciting. My first time working with such a diverse team and in English (Brazilian Portuguese is my native language).

After a year in this role, we revised this experiment. It became a high cognitive load for the PDs/PMs so some people choose to be more focused on the UX/UI design, and others decided to turn into full-time PMs. I choose the latter.

Below are my main learnings in this journey.

1. Align expectations about the Product Manager role

The type of work a PM do varies a lot from company to company. Different environments, marketing, and business requirements, and thus, different needs and responsibilities.

When I started as a UX designer, I was carefully selecting opportunities, to spot and avoid fake ones. Fake because sometimes the company announces they want a UX designer, but the day-to-day responsibilities have nothing to do with UX. They are more for a graphic designer. Since I wanted to learn and practice as a UX designer, this triage would save my time and the company's time.

As a first-time PM in that context, it was a bit different. I was open to experimenting and learning with all challenges the company had. I ended up involved in a wide range of responsibilities, such as gathering business requirements for projects, conducting discoveries, ensuring the solution was viable within the constraints of the business, defining OKRs, prioritizing features, managing product backlog, and sometimes tackling the whole design flow, from ideation to handoff to ENG, if no UX/UI designer was available. Also, defining scopes, documenting product specifications, handing-off features, addressing quality assurance, coordinating projects with a multidisciplinary team, tracking and communicating progress to deliver on time, and estimating whether the product would meet goals. 😮‍💨 Phew

It was a lot to handle. Some activities I'd more frequent than others. After some time, I needed to clarify and negotiate expectations about responsibilities in this role, so it could give the company and me a better idea of what we could cut off from.

We can’t have it all. Not just because of the high cognitive load, but to evaluate performance for growth in the role, and especially give space for critical activities, such as product discovery and addressing value (will people buy it, or choose to use it?) and viability risks (will this solution work for the various dimensions of our business?).

But I do understand that depending on the context, having separated roles to cut off activities is not viable at all. That's okay as well, as long as the expectations are aligned.

Possible expectations and misunderstandings of this role:

Talking to and reading from experienced PMs about the requirements of a PM, I concluded that it varies a lot. But, there are some shared understandings of what a Product Manager should not be expected to do.

Some items below I selected from the articles by the product thinkers Marty Cagan Two in a box and Jeff Gothelf — What product management isn’t. (For more details, click on the references.)

Product Owners are not Product Managers

This can be a long debate. A quick overview is that Product Owners originated from Scrum, and were accountable for effective Product Backlog management. Marty Cagan used to say 'Product Manager' and 'Product Owner' synonymously. But later he realized that having CSPO training, or knowledge about Agile rituals did not prepare a Product Manager to lead the product. He said:

“If you tell me you’re the product manager, I’ll double check that you’re also the product owner, but if you tell me that you are the “product owner” then I will ask you if you are also the product manager? Are you just administering the backlog, or are you actually tackling and solving difficult problems for your customers and your business?”

And Jeff says that there should not be a difference, that “Scrum gifted us the role of Product Owner without reconciling it explicitly with the role of product manager”.

Product Managers are not Project Managers

Project managers may be good at scoping out budgets, and timelines, and organizing schedules in a visual way, such as using Gantt charts to share with stakeholders.

Although both roles work aligning expectations, Product Managers prioritize features and ask larger strategic questions about the product. Its highest contribution and responsibility as a product manager is to make sure that what is being built is worth building and that it will deliver the necessary results, as Marty Cagan said.

Even though there will be some amount of project management in this role, it should not be what defines the product manager's job.

Product managers are not someone's boss

The ‘manager’ word might give a misunderstood interpretation of managing people — but nope. Product managers manage the product itself.

“If you’re taking a PM role because you think it will give you management experience, you’ll be disappointed. It will, however, give you leadership experience and that is far more valuable.” — Jeff Gothelf

The team should be a flat structure and the product manager worries about ensuring the product is valuable and viable, not about people management.

Although, this role might give a leadership experience that can be far more valuable.

2. To prioritize, delegate, and say no

There is simply a lot to handle as a PM. People from different areas make requests and the PM is accountable for the final decision. Overwork and context-switching can easily become unhealthy habits.

During work, it helped me to write things down to take them out of my head and set specific focus time to go over them. But then, I'd end up with an ever-growing to-do list.

After trying to do many of the tasks myself and ASAP, which clearly did not work well, I started to learn how to delegate and prioritize. The company had already a formula for prioritization, but there are +150 out there. I learned how to use ours to make informed guesses.

Even so, it is important to acknowledge that in the product world, we often deal with wicked problems, which are chaotic and unpredictable. There is no right or wrong answer. Only what might work best for that particular context. In the end, we test in the real world assuming the risks. It feels messy. But exciting too.

As for delegating, when things were related to other areas or parts of a system that could function without my direct influence, I realized that the team and myself would highly benefit from delegation. People had the expertise to do those things better than I would and I could focus on other priorities. This was new to me and it felt more efficient once I started.

Another important practice was asking questions before saying a 'yes'. This may seem obvious, but in the day-to-day rush, and requests with claims that 'many clients' were impacted by something or the leadership sharing things, I felt biased to just do it. But basic questions to understand better the context and numbers were helpful in the prioritization.

I had to frequently remind myself of asking questions to better understand the impact and the context, before a 'yes'.

When was a 'not now' answer, I'd add them to the product insights or backlog board. I started to share the link of those cards to give visibility, and acknowledge I heard the request.

3. To face business-centric tasks

As a Product Designer, many times I'd get most of the business context from the PM. My scope was a bit more narrowed.

As a product manager, I worked closely with the Head of Product, leaders, data, and UX research people, along with different stakeholders. I was digging deeper to have a broader vision of the business, understanding its metrics, and constraints. From that understanding, there were usually multiple potential paths to invest our efforts and a big amount of daily decisions to take.

Data helped to make those decisions, but many times, they are not fully available. This is more common than it sounds, which reminds me of the 70% rule from Jeff Bezos shares: “most decisions should probably be made with somewhere around 70 percent of the information you wish you had."

I was learning to get comfortable with making decisions based on partial data, and setting a hypothesis that I'd help me evaluate the outcome and learn from it.

Many times, depending on the risk, it was cheaper and faster to test in production. Learn from it, and adapt afterwords.

To better understand the business and the product, I felt the need to learn more about how to consult data. So my first step was to do an SQL and product analytics course. I also proposed learning together with the team, which was fun.

As I tried to apply the learnings and kept talking with experienced people from data, I had two main learnings:

• Having a data person on the team might be crucial. Knowing SQL or technical data skills does not solve unhidden problems of inconsistencies in the database, taxonomies, and lexicons, where people can end up consulting the wrong table, or creating ambiguous meanings.
• Every data consultation comes from a question to be answered. This can be overlooked, but knowing how to ask better questions is more important than learning technical skills.

The book ‘How to lie with statistics’ was an open mind for me to question the data. Math and statistics are not my strength at all, but being more critical about the data being shared was a skill I started to develop. The book brings examples of vague and biased data and how they influenced our decisions.

4. Manage the end-to-end product development process

Finding opportunities and working on them until their release was already part of my role as a Product Designer. The key difference now was to be responsible for strategic decisions of the product, suggesting trade-offs, and prioritizing the backlog.

It felt like a zoom-out on the product. Gathering inputs from the business and users, and trying to incorporate them into the product lifecycle.

All of this work was not done alone. Being a product manager is a team effort. Although, the accountability of the final decision is usually with PMs.

At this stage, I was learning to make quick trade-offs to ship the product such as the final solution not being the dream one, but the valuable one for the users and business, while viable within the constraints.

5. Communicate cross-functionally working fully-remote

Last, but not least, communication. I realized that PMs act as the 'glue' of cross-functional teams. In my scope, I was frequently collaborating with designers, engineering, marketing, data science, operations, customer support, and sales.

As the company was fully-remote with teams distributed globally, we did not have lots of meetings or hallway conversations. We were mindful of everyone's agenda because people sometimes were in opposite timezone.

I was highly advocating for asynchronous communication. This enabled me more focus time and thoughtful communication. Later on, it also helped as documentation to consult later. Although, sometimes synchronous communication was quicker and more helpful.

Most of the time, long-form messages or quick videos worked. I highly recommend this article from Doist for remote teams on how to decide which meetings can be async threads (and which can’t).

Managing projects from definition all the way through to release, and collaborating with different teams was something I really enjoyed doing.

Conclusion

There is a known overlap in the work of PM and UX designers, and some activities I’ve mentioned may be common for a UX designer in a given context. For me, it was an experience I haven’t had before. The challenge of the role in a fully-remote environment and as a non-native English speaker gave me some tools, to view myself and the product from a different perspective. I also feel I have much more empathy for the PM role now.

I have to say this was way outside my comfort zone, and it felt like a roller-coaster ride filled with excitement, self-doubts, engagement, and uncertainties that all became learning opportunities.

And even though it was one of the best companies I have worked for, I decided to quit at the end of June 2022. It was a mix of reasons, one of them was that I realized too late how drained I was, and how much I needed a break.

If I were to go back to a full-time job, which I'm choosing to not do, for now, I’d look for a Product Designer role, not a PM role. This is because as a PD, I can still be analytical, get involved in the strategy, understand the problem, get to the whys, and contribute to the direction of the product — all while unleashing my creative side, ideating and exploring alternatives to solve a problem. I'm passionate about the psychology behind product decisions and getting deeper into the user experience. As a product designer, I feel I can experience it without the cognitive load of the Product Manager role. But who knows about the future?

As for my next path, I've been excited to work on a project that my partner Cali, and I recently started. It is a consultant service called SkutaLab on a subject we both love: jobs to be done. We are still in validation mode and it is only in Portuguese for now. I'm eager to see where this new journey will lead me.

With all this being said, I'm thankful to the leaders and teammates that trusted and supported me in that role. I've learned more than I could express here. And a big thanks to my partner, that also supported and encouraged me all along.

Embracing transitions and documenting those changes have been an important part of my journey since I migrated to the UX field a while ago.
I acknowledge that there are many articles about this subject on Medium. The only difference you get with this is that it is my perspective.

I appreciate your time reading it.

❤