How Your First Product Manager Role Shapes the Rest of Your Career

What I learned in my first PM job—and the lessons that have stayed with me

A journey from startup to corporate

I got into product management unwittingly through entrepreneurship. I've spent most of my career working in roles filled with market research and writing tasks. My last job before product management was as a Technical Manuals Engineer on a mega infrastructure construction project. I left that job in mid-2017 to cofound my startup, Controlcast, a tech solution and marketplace connecting advertisers with digital out-of-home screens. We were a small team working with the leanest of processes. But we shipped fast. We built the betas of four applications with their respective architectures in a year. I worked for about a year and a half on my startup without much income, so I had to look for a job while continuing to contribute to Controlcast.

Entering My First PM Job

In 2019, I chose to take on a full-time role with Egypt's largest jobs platform. This was my first PM job where there were multiple product squads, multiple teams for design and engineering, and a dedicated QA team. The product operations, or ways of working, were, on the surface, straightforward. But as I spent more time observing and then getting into the process myself, I noticed that product development was slowed down by the process in place.

My first observation that things moved slowly was watching multiple product squads work on revamping the Applicant Tracking System (ATS). To be fair, the revamp had multiple goals, one being to upgrade a legacy system. It also included redesigns of many components and experiences in the ATS. I joined the company when they were a bit more than halfway through the revamp. It ultimately took them around 6 months to release the work to customers. There was a small celebration after release, with the CEO noting that this was likely 'the largest product development effort' to date in Egypt. My initial thought was, "Wow, this team is doing big things!" But only upon further reflection did I realize the high opportunity cost. It may have added new value to customers and given new life to the product, but I don't recall that it had the desired impact on business outcomes.

At the time, company management was looking for ways to increase its footprint in the region, solidify its brand within the career solutions industry, and increase revenue. With that desire, they tasked me to research and analyze a list of 8 opportunities for new business lines that would best achieve those outcomes. And so I went to work. I conducted interviews with stakeholders and customers. I analyzed feedback data. I made financial projections. And I coordinated a working committee to assess and score each opportunity, using all the insights we had at hand. I was in my element with this task. It took me about 2 months before it was ready to present to executives.

What I remember most from that experience was the dismissiveness of the CEO towards my findings. It was a tough presentation and I struggled to get through it without interruption. I understood the mindset, even though its manifestation towards me could have been better. Founders are protective. I was one in my startup. The irony revealed itself by the end of the presentation where the CEO - and almost everyone else in the room - agreed with my recommendation. And with that, I would be the product manager for a new courses platform to complement the company's jobs board.

Navigating the Web of Process and Approvals

My squad was comprised of myself, two frontend developers, a backend developer, a UX designer, a UI designer (more on this split later), and a QA engineer. Our goal was to build the Minimum Lovable Product (MLP) for the courses platform. I emphasize MLP because the company was an established brand and its user base expected a level of quality that an MVP wasn't sufficient for. But it would still be the lightest possible implementation. The roadmap was set and Epics were defined and scoped just-in-time. As we started work, I noticed that we were not as fast as I was used to in my startup. One of the reasons was misalignment on a few key issues paramount to guiding product development work.

First, it seemed that product requirements documents (PRDs) were too heavy, and often overlapped with another document produced by the UX designer - the Design Requirements Document (DRDs). Besides the overlap, the PRDs would often (not always) need to go through a review process with the Head of Product. On the design side, it was even messier. Wireframes would go through a committee of UX designers for review, then the product squad would discuss them, then the Head of UX, then the UI designer and the UI design team! And as we know, design is rarely linear so designs often went backwards in this flow. Because of the length of this process and the number of approvals required to get a design into development, we released at a slow velocity. I struggled with this way of working. To be fair, I was also the product designer for my startup so any lengthy delay in the design approval process was a new experience.

Within the squad, I tried to speed things up, sometimes skipping approval checkpoints - much to the chagrin of the UX and Product Head. It didn't help matters that they were of one mind (in more ways than one as they were married to each other!). At the same time, the UI team was having its own running misalignment with the UX team on how the two teams should work together. We somehow managed to keep things moving but certainly not at the velocity I was used to.

All of this came to a head one day when I decided to take the suggestion of my UI designer and implement a new design for the main course page. Others wanted to borrow the design of the job page and essentially copy-paste that look and feel. In my mind, if we were trying something new for the business, it was also a good opportunity to test a different look and feel for a core experience. This didn't sit well with my manager. The discussion devolved to the point of arguing over button placement and color. The CEO even became involved in the 'button discussion' and ultimately overruled my decision. Was this how things worked in all product teams? It couldn't be.

I left that job soon after. In hindsight, it was the right call. Yet, those experiences - as uncomfortable as they sometimes were - taught me so much.

Lessons from My First PM Role

Looking back at that first PM role, I realize now the wealth of unexpected lessons it provided beyond the typical product management skills. For one, I learned that process can be a double-edged sword. Too lean, and you risk inconsistency and missed steps. Too heavy, and everything grinds to a halt. Finding that balance is an art that requires constant adjustment depending on the team, the product, and the company stage. I think I erred on the side of moving too fast because that's what I knew from my startup days.

The relationship dynamics were particularly eye-opening. When I started, I had no idea that navigating organizational politics would consume so much mental energy. I learned to pick my battles and to understand the context behind decisions before questioning them publicly.

Another lesson was seeing firsthand how a company's culture shapes its product development. In my startup, we could make decisions on the fly and pivot quickly. In a larger organization with an established brand, every decision carried more weight and required more buy-in. What I initially saw as bureaucracy, I later came to understand as occassionally necessary guardrails to protect what the company had already built. That's not to say all the processes were justified - many weren't - but I gained appreciation for why they existed.

Perhaps the most valuable lesson was learning to be an effective translator - between business objectives and technical constraints, between designers and developers, between stakeholders and the squad. In my startup, these lines were blurry. In this role, the boundaries were clear, and someone needed to bridge them. When I focused on being that bridge rather than fighting the system, I became much more effective.

I also discovered my own blind spots. Coming from a startup where I wore multiple hats, I hadn't realized how specialized product management could be in a larger organization. I had to acknowledge my strengths and weaknesses and learn to leverage the team around me.

If I had to distill it all down, I'd say my first PM role taught me that product management isn't just about building great products - it's about building them within the constraints and context of your organization, leveraging the unique talents of your team, and navigating the complex human dynamics that inevitably arise when passionate people care deeply about what they're creating.

The Bottom Line

At the end of the day—and assuming that discovery is good—product teams must execute. When they execute on the 'right things' (hindsight on bets is always 20/20 and luck is always a factor) is when you know you have great product management happening.

---