Till late 2021, the Saas company I work at didn’t employ Product Managers (PMs). Instead, product decisions (what to work on next, deciding what was in scope, etc.) were made by product designers. When I joined as a junior designer, tasks felt manageable as they were neatly within the UX realm. But once I started (attempted) to handle things like sprint planning or feature prioritisation, I began to panic. In hindsight, I should have spoken up sooner and louder about being given PM responsibilities as I had no clue what I was doing.

Photo by Bernard Hermant on Unsplash

Thankfully that season was short — we realised a dedicated PM was needed and hired an excellent one. She gave us stability and direction — this allowed the designers to focus on what they do best. It was a divide-and-conquer, win-win solution! Since then, we’ve brought on another PM and implemented frameworks to keep the team accountable and forward-moving. I’m currently happy and energised with my work, and if I ever transition to a PM role, here’s advice to myself and my fellow people pleasers.

Juggling feedback, feelings, and features

Receiving negative feedback about your product sucks, but I actually felt worse when colleagues disagreed or perhaps felt disappointed by my product decisions. As the title of this article suggests, I’m a (recovering) people pleaser and have a strong inner critic! I want happy customers and happy team members who feel seen and heard. But features shouldn’t be built just because someone complained or requested it.

So how do you gauge whether an issue is worth fixing or a feature worth building? Use a prioritisation framework or just ask yourself these questions:

• Have customers churned because of this? What other solution did they turn to?
• Are these complaints coming from our key users? How often are these complaints coming in?
• We have many known problems — why should we prioritise this problem over everything else?

Saying “no” or “not yet” is uncomfortable, but prioritising anything and everything without evaluating its impact is harmful. Why: you might end up spending resources (brain juice, money, time, etc.) on something that provides minimal value or wasn’t that big of a problem in the first place.

Sending a ticket into a sea of requests

In Disney’s 1997 “Hercules”, there’s a scene where Herc dives into the river Styx to save his lady love Meg. Her soul is trapped in a whirlpool, ageing and unable to get free. This scene comes to mind when I think of a lost, forgotten ticket.

Pre-PM, we did create tickets to document customer feedback or requests but the product team didn’t regularly review them. As a result, tickets piled up quickly and colleagues who gathered that precious data could have felt like their efforts were wasted.

The solution: set aside a time every week to review tickets and give them a status. A status (prioritise, leave it in the backlog, etc.) gives everyone clarity. The ticket submitter knows that their ticket was seen and whether it’ll be picked up. The PM has an easier time with roadmap planning as they’re in touch with customer sentiments.

Remember your role (you’re not a yes-man)

If you’re like me, besides having people-pleasing tendencies, you might also hold yourself to painfully high expectations. (Don’t worry, I’ve got a whole other article on perfectionism.) These traits and that day-one-at-a-new-job eagerness can make you confuse your top priorities. When this starts to happen, seek clarity from your manager. Make your main responsibilities a mantra and gently remind others when necessary. Please don’t take this as a license to over-react when occasional requests come in. Ad-hoc tasks are inevitable; this is just a reminder to protect your time.

Like advocating for yourself, rejecting the urge to please others is deeply uncomfortable. The good news is that it will get easier over time. Start today and you’ll find yourself a happier designer (or PM) and overall human in general.