How I turned my Bizops internship into a Product Manager role
Product management seems to be one of the hottest, most-coveted roles out there in the world today. When a role advertises itself as “CEO of the product” and “pathway to startup founder”, it’s not surprising that there’s a lot of hype around it. Since my early university days, I aspired to be a product manager. It seemed like an elusive and exciting world — one that I didn’t expect to join until much later in my career.
I recently came across a thread from teamblind.com where one user suggested that the “best bet” to move into a PM role is to start in bizops and internally transfer. As someone who just did the same thing, it got me thinking. Perhaps there’s some truth to this. Here’s my take on it.
🏔️ Let’s set the scene
Bizops: an internal team tasked with “cutting across traditional cross-functional boundaries to help companies set strategy, improve performance and drive results”. Sometimes known as an “internal SWAT team”.
What did I do in bizops? A bit of everything! And that’s the beauty of Bizops — you get to work on a variety of projects depending on what the business needs. Some of the projects I’ve worked on include:
- Managing company OKRs
- Increasing the efficiency of publishing feedback loops to improve our NPS score
- Producing an e-book as part of a product management conference
Product management: the team that guides every step of a product’s lifecycle. Most commonly described as the team that sits at the intersection of business, user experience (UX) and technology.
What do I do as a product management? Everything to do with the product that isn’t coding! I turn our app features from an idea on paper to a live, functioning product. My projects usually look a little like this:
- Discovery and validation: We identify the problem or the user’s need, then do all the necessary research. At Finder we’re lucky enough to have access to usertesting.com and Askable.
- Ideation. At this point,Does this intuitively meet the user intent? I map out what the solution looks like and how it should work. Our lawyers look out for any compliance risks and then the key stakeholders give the team the green light to start building.
- Design and build. The feature gets designed and I work closely with a small team of engineers to start building!
Now that we know what these roles actually mean, let’s dive into how I got into product management from bizops.
🧠 It’s all in the mind
The mission of a Bizops team is to streamline processes, push progress and improve any efficiency gaps in an organisation. In the Bizops analyst role I always asked myself:
- Is this the most efficient way of doing this? What is the current process?
- What makes the most logical sense?
As an associate product manager (APM), I now “own” an entire feature in my organisation’s app. As such I started asking myself questions such as these:
- Does this intuitively meet the user intent?
- Is this a delightful experience?
Storytime
My first product management experience was building a mobile plan comparison feature in our app. The feature asks the user for a few details about their current mobile plan (data inclusion, contract type etc.) and then it displays a list of products that could save the user money compared to their current plan.
We showed the list of products ranked by the amount of money you could save. This seemed to be the most logical way to go about it at the time. However, what we found was that it disregarded the fact that our users actually cared about how much data they would get in their phone plans.
For example, a 30 day, $30 plan with 30GB of data works out to be $1 per day and 1GB per day. A 180 day, $120 plan with 60GB works out to be $0.67 per day (much cheaper!) but only 0.3GB of data per day (not so good if you like to watch a lot of videos!). Which one would you choose?
To meet our user intent and create a better experience, we factored in the user’s preference for contract length and amount of data into our final results.
☕️ Being able to separate these mindset questions was really important as I took on the responsibility of creating user experiences, not company processes.
🔭 Zooming in and out
Bizops required a very zoomed out view of the company. We needed to have a deep understanding of the company as a whole — how certain teams work, what processes we have in place and so on. I learned about the business and met a lot of people very quickly which makes my work today a lot easier.
Product, on the other hand, is very zoomed in and focused. I live and breathe the product, and my job is to do everything for the product apart from the final designs and engineering. Admittedly, it’s a nice change because I have the mental space to focus on just a few things and do them (mostly) right.
Storytime
My former manager is literally a Wikipedia for our company. She could direct me to the correct Confluence page for any question I had. It really was necessary because after all, this “internal SWAT team” could be called onto any team or any project at any point in time. Our 1-on-1s really helped me learn about all the moving pieces of the company as I tried my best to mentally download everything I needed to know. It definitely paid off though because I now find new projects much less daunting and it takes me less time to get up to speed with things.
☕️ Learning about other parts of the business (outside of Product) is a very worthwhile investment for product managers.
💪 Let’s get down to business
Both bizops and product Management approach projects in a similar way:
The difference between bizops and product management lies in where the energy is focused.
In bizops, diving into solution-mode and being hyper-efficient is encouraged. Getting things running — and at speed — is the goal. In product management, more time is dedicated to the problem space to understand the root causes of the problems.
Storytime
Before the start of this quarter, the product managers led a series of internal “Think Tanks” to set the direction of the quarter. The deliverable at the end of the Think Tanks was a set of problem statements that would set the strategic direction for the organisation. This entire process took weeks as the PMs investigated the problem spaces in great depth.
The eagerness (or impatience) of bizops to jump into developing solutions was palpable. From the perspective of the Bizops team, the majority of the time should be spent implementing the solution. It’s hard for me to say if one approach is better than the other, but what I can say is that each team’s respective approach works well for the type of projects they take on.
☕️ Bizops taught me how to get sh*t done and get it done efficiently. Product, on the other hand, taught me the importance of knowing the “why” of our projects.
🎁 Wrapping it all up…
What I learned from the transition
My experience in bizops has allowed me to deeply understand the business, embrace my inner generalist and be capable of taking on any sort of project and this has really paid off in my move to product management. Being able to combine the bizops experience with the product management mindset is key to thriving in the role.
What you can do now if you want to move into Product Management
- Start developing the skills that I mentioned throughout the post.
- Fall in love with learning. I think it’s so important to learn from the best (and the worst!) and keep upskilling. Since joining Finder, I’ve focused on product management frameworks, keeping up with the fintech space and learning about successful entrepreneurs. Books and newsletters like this one work the best for me — find what works for you.
- Get your hands dirty. Nothing beats real experience so my advice is to find opportunities where you can work on real projects. This might be interning at a startup, volunteering for pro-bono consulting, or perhaps starting up your own side hustle!
I’m keen to delve deeper into all of the points that I’ve mentioned. Look out for them in later Batch Day posts!
If you found this useful, show the post some love 💝, subscribe (if you haven’t already!) and share it with your friends!
Thank you to Mariana Wu, Kevin Zhu and Darcy Sanders for reviewing and providing early feedback on this post 🙏
