Learning Beyond My Title

My title right now, were I employed, could be "program manager," "project manager," "technical program manager," or technical project manager. Fundamentally, a project manager thinks about planning, organizing, and guiding work so that a specific goal is achieved on time, within scope, and within budget. Unlike operations work, projects have a beginning, middle, and an end. They come and go. Now, I have held other titles. Once, at Scholastic, I held the title of Senior Technical Product Manager. This was a role that blended the fields of project and product management. Despite this experience, there came a time that I wanted a clearer and more current understanding of how strong product managers operate day to day. For this, I arranged to shadow a product manager where I worked. At the time, this was more about curiosity and personal growth, rather than role transition. Now, though, I could see a time coming in which I would want to transition into product management. 

Product management and project management, as I see it, are parallel fields. Some may disagree with me on that, thinking one or the other is superior, or rather should be. As I indicated above, project managers think about timelines, budgets, and deliverables. Product managers, on the other hand, define what should be built and why, ensuring that products solve real user problems while advancing business goals. They prioritize features, shape the roadmap, and align stakeholders around outcomes and tradeoffs. In short, they are responsible for maximizing product value by connecting customer needs, strategy, and execution. If the roles are not well-defined, there can be overlap and even conflict between product management on issues like ownership of roadmap, prioritization, and stakeholder communication. In a well-functioning organization, however, the roles are defined and the two are able to work as partners, ideally with an engineering lead in the picture for the project as well. My goal at that time, in shadowing a product manager, was to better support product partners and improve collaboration. What I did not do was evaluate or critique the product manager's work or role. 

One of the most striking things I observed was how much time the product manager devoted to clarifying the problem before entertaining any discussion of solutions. Rather than jumping into features or timelines, they asked detailed questions about user impact, which customer segments were affected, and what specific business outcome we were trying to influence. The conversation centered on defining success and understanding constraints before committing to an approach. As someone wired for program execution, my instinct is often to translate ambiguity into plans, milestones, and dependencies as quickly as possible. Watching that deliberate pause in favor of deeper problem framing reminded me that strong execution begins with precision about what truly needs to be solved.

Another thing I noticed was how the Product Manager skillfully balanced input from multiple stakeholders, including engineering, design, analytics, and business teams. Every decision was framed around value and risk rather than just effort or feasibility. They repeatedly communicated tradeoffs in clear, simple terms, ensuring that everyone understood what would be gained or compromised with each option. Observing this level of transparency and intentional alignment made it clear how much clarity and trust it takes to move a complex product forward effectively.

I also saw how the Product Manager navigated situations where data was incomplete, yet decisions still had to be made. Rather than waiting for perfect information, they articulated hypotheses and defined what evidence would validate or invalidate each assumption. This approach was markedly different from project management, where the instinct often leans toward minimizing uncertainty before acting. Watching them operate under ambiguity taught me how to balance calculated risk with progress, keeping momentum while still grounding choices in logic and expected outcomes.

Several things surprised me about the role. I hadn’t fully appreciated the emotional labor involved in product work—the constant need to say no, manage expectations, and maintain alignment with multiple stakeholders. I was also struck by the invisible cognitive load of holding the product vision while simultaneously navigating day-to-day tactical questions. It became evident that this balancing act requires both mental discipline and a strong sense of empathy for everyone involved.

The experience reinforced several lessons for me. I learned the importance of anchoring execution to clearly defined outcomes, of using writing and structured documentation to clarify product thinking, and of separating problem definition from solution design. Repeated communication and explicit alignment are essential to prevent misunderstandings and maintain momentum, even when all stakeholders are motivated and well-intentioned.

Shadowing a product manager reshaped how I approach program management. I now ask more outcome-oriented questions during planning sessions, check that roadmap items are tied to measurable goals, and consider how delivery timelines influence broader product strategy. I also protect space for discovery, ensuring teams can explore the right questions before rushing into execution. Overall, the experience reinforced that effective program management is strengthened when it is informed by a deep understanding of product strategy and user impact.

As I suggested above, I'm open to the possibility of becoming a product manager again, and making it my primary career path. While I love project and program management, I feel I need to stretch myself and engage more with product and user/customer. My Master of Science in Innovation and Strategic Management had a strong customer and product emphasize in the curriculum, and between that and my past exposure to product management I feel I could do well in a role that works closely with product, and in which there could be openness to a lateral move. Or, frankly, I'd be glad to take a more junior product role simply to get started. 

My prior experience as a Senior Technical Product manager gave me a great deal of empathy for the role. I wasn't going in completely unaware of what product work entails, by any means. What shadowing did for me was refresh and modernize my understanding. Part of maturity in leadership entails revisiting adjacent disciplines with an eye toward active learning. Shadowing someone outside my "lane" strengthened my effectiveness inside of it. Cross-functional respect is built through observation and curiosity. In complex organizations, no single role holds all the answers, and cross-role understanding builds empathy, improves collaboration, and ultimately drives better outcomes for teams and users alike.