While I have intentionally selected a level that offers the right balance between strategic oversight and hands-on involvement, my perspective is influenced by several years of remote experience in a more senior role. Experiences can vary significantly in this field, so keep that in mind as you dive in.
About Assumptions
Do not assume. Do not assume that systems or people will work in expected ways, or that tools will be used in the same way. The cosmos of each company is different, people are different, and cultures are different. I am referring to a Product Manager, perhaps a Lead Product Manager role with a maximum of a couple of juniors underneath, not a people’s manager such as a Director of Product, CPO, etc.
If I could go back now, I would have invested triple the time in understanding first and foremost the people I’d work with daily: what they do, how they do it, what they know, and how they learn. I would take culture into consideration too, and I would start by explaining my culture, character, and personality to avoid misunderstandings early on.
All this could easily take 2-3 months with good documentation being written (what we do and how we do it) and working in parallel with other tasks. In this way, I would have much more clarity on the discrepancies between my views and others’ views on standards, deliverables, expectations… heck, even wording. This helps dramatically in deciding how to approach new work and delegation.
I would also start by understanding the systems I would be putting my hands into. Architecture, API, backend operations logic, frontend operations logic, internal panels, and how they work. Product managers work closely with developers, but also with support, marketing, and sales. Do those teams have the context and tools to do their work? Are they properly briefed on our products, options, and tools they use daily? Start by prioritizing this work based on the frequency of the requests.
Don’t be a hero
The other day, I was scrolling through LinkedIn and stumbled upon a post that really hit home.
Product managers can easily fall into the trap of playing the hero, jumping from system to conversation to topic, putting out fires. This often happens because product managers usually know the most (outside of developers) and can deliver information and solve problems quickly. “I know I can solve this, so why shouldn’t I?” is a common thought.
However, going the extra mile and being a hero are not the same thing. Constantly jumping in to solve the same problems across systems and processes can take a toll on you psychologically.
Unlike engineers who mainly deal with systems, product managers also handle people interactions, expectations, and processes. Ultimately, this approach can backfire, as others will perceive you as overstepping boundaries.
In short, don’t try to be a hero.
Instead, clearly document the problem (post-mortem), escalate the issue, request additional resources, and plan to address the root cause properly. Most importantly, collaborate with others to agree on the outcome. It might be slow and sometimes even painful, but in the end, it will be drama-free.
Ruthless prioritization
If I could go back, I’d say “no” more often, mostly to my inner thoughts. “No, Marianna, you can’t take that on too with that big issue looming.” Or, yes you that this can make support’s life a bit easier, but focusing on it won’t bring us closer to our annual goals and revenue targets.
I understand that much of our prioritization is dictated from above, but how we plan our days and what we focus on each week and during each sprint can significantly impact our ability to meet goals and stay efficient. Accompany your “nos” with plenty of context and overcommunication.
Do it better than I did; lay all the facts on the table clearly and concisely, and let others understand and accept when something is a “no.” A “no” without context is frustrating for everyone, and no one can see all the details in your head. You might not have enough time to collect arguments, your preliminary findings and gut scream otherwise, but unless you are trusted 100% (not in your first year), you have to do the work and lay the facts.
Prioritize ruthlessly and support your decisions with data. You won’t be liked by everyone anyway, so you may as well ruthlessly prioritize what your skills and expertise have proven to be the most valuable for the customer and the business. But, explain your thoughts clearly and seek agreement before taking action. Over-communicate and share context. Do it early, and do it better than I did 🙂
For your day-to-day work, keep two things in mind: deadlines and impact. Use reminders, calendars, and due dates in Jira. Rely on nothing from memory—store everything in the tools you use daily.
Final thoughts
Finally, I am Greek, and I love debates. We should all debate more, in a radically candid way. Challenge directly, show you care. Emphasize the caring part, so you don’t come across as an a****e. Debates bring to light diverse viewpoints, foster creativity, and can lead to better problem-solving. Challenging directly with care and talking about mistakes is 100% better than avoiding difficult conversations.