When I was growing up, I wanted to be a teacher. If someone had traveled back in time to tell me that one day I’d be a product manager at a global cybersecurity company, I’d LOL.
Today, in retrospect, it all makes sense. I have always loved collaboration and finding connections where they were not obvious. This is how I got to work in multiple industries from engineering consulting to medical devices, and multiple roles across marketing, business development, etc. It’s also how I became a Scrum Master, aka, master of facilitating an agile environment.
Two years ago, a recruiter on LinkedIn reached out to me about a Scrum Master role at Palo Alto Networks. I thought, this is something I haven’t done before – working in IT and in cybersecurity – of course I’m interested!
Within the next 15 months, my role evolved into an IT Product Manager. While Scrum Master and Product Manager are quite different, there’s one commonality – in both roles, I’m a part of our IT Employee Experience team, which is responsible for making employees’ lives better. I knew there is a direct connection between engaged employees and company performance, but I have never seen such commitment to employee satisfaction that would merge the digital experience with more traditional HR initiatives. It felt so obvious, yet so… challenging!
The hard part
I had worked with PMs before, seen them create product roadmaps, strategize, negotiate, and launch a product. I have supported and admired them for their grit and creativity, but I have never been one. When the PM opportunity came up, I was extremely excited but also terrified. Despite my lack of PM experience, leadership took a chance on me.
I spent months reading about HR systems, top tools, why different companies choose different solutions. I was convinced that to succeed as a PM I have to absorb all the relevant technical knowledge, and also build strong business alliances to understand the needs and translate them into feasible solutions. After all, many failed initiatives do not usually lack technical excellence, they just don’t match expectations of the end users.
Much of my work involves gathering business requirements from our partners (e.g., what’s the problem, gaps, desired state) and mapping out technical requirements with dev leads and architects (e.g., what systems will interact in the proposed solution, what infrastructure and security will be needed). To drive initiatives forward, a PM needs a good dose of diplomacy, persistence, patience, and problem-solving skills.
The scope is going to change
My business partners are groups in HR – Global Talent Development, Talent Acquisition, Compensation, Benefits, etc. My technical partners are the IT development teams, delivering solutions to employees across the company. We work on a variety of projects like how to provide FLEXWORK, improve the internal mobility process, or keep employees connected and engaged remotely.
Together we launch exciting products such as our first-ever Mentorship App that grew into a company-wide Mentorship Program. What started from a weekend idea of one of our brightest developers turned into a large-scale initiative. We’re on a third iteration of the app now and continuing to enhance the employee experience with regular check-ins and roadmap reviews. It’s been so rewarding to watch this grow from a handful of users to over 400 employees making nearly 260 mentoring connections! Eventually this will be available to all employees.
My days are filled with feedback gathering, analysis and writing. For example, I may receive a Business Requirements Document (BRD) from a business partner, then do the technical requirements brainstorming with our team in IT, then work with a designer to show what the solution might look like, then go back to the business with wireframes to ensure that we’re all on the same page.
I used to get upset whenever I hear “the scope has changed” but being a PM has taught me that the scope is often likely to change. It’s up to the PM and dev team to figure out how flexible the solution(s) provided should be.
Product manager is like a prism
The role of a PM is not a cookie cutter. In a startup, a PM might be the “CEO of product” and be tasked with everything from coming up with product ideas, to developing, all the way to marketing them; while in large companies, there might be multiple PMs owning different parts of one big product (e.g., a PM for a popular app, another PM for a mobile version of the same app).
In my case, as an IT PM I get to help build bridges between two worlds – that of business needs with that of technology choices. The impact that comes from discovering similar needs from different stakeholders and refining/consolidating solutions is gratifying.
IT is often this “behind the scenes” department that you call when your laptop doesn’t work. But there is so much more to it! While we couldn’t function without our IT Help Desk and software upgrades backbones, we also have tremendous technical thought leadership touching all parts of business. From ensuring our infrastructure is secure, to smooth new product introductions, supporting engineering, mergers and acquisitions, and innovating marketing and sales tools.
Building a product can be a daunting task because of the many layers of translation between the end user, the business, the developers, etc. Working on an “internal” employee-oriented product doesn’t make it any easier, but the experience is fulfilling because I personally know my “customers” – the employees who end up using the product.
The beauty and challenge of being a PM is that there are no two identical PM roles – you have to find your own path. I am in my dream job 🙂 To me, PM is like a prism – a transparent material that reflects light and helps analyze what’s going through. Or PRISM: people, reasons, ideas, systems, messaging (or product manager).
Keys to success
Many years ago I got a piece of advice: “When something makes you feel very excited and a little scared, it’s usually a growth opportunity.” I agree wholeheartedly. When you experience that, I’d say – go for it!
Always try to foster a spirit of trust and collaboration with your colleagues. We achieve greater results as a cohesive team – innovation happens when ideas are shared and people feel purposely connected regardless of their physical location.
If you enjoyed this post and would like to explore opportunities at Palo Alto Networks, check out our open roles. You can also read more stories like this or learn about our technologies.
