16. How to get into Product Management
The story of how I got into Product, and tips I would share with anyone looking to become a PM today
Welcome! I’m Vincent and this is a Product Manager’s Notebook, a series of notes for people who are interested in sharing and learning the art of product management and career development. You can read my archive here.
If you appreciate reading this post, please consider liking and subscribing.
“BQuant” is dead. Long live “Bloomberg Lab”.
In case you missed the big announcement at the beginning of the year, Bloomberg announced the release of Bloomberg Lab, our cloud based research platform where you can combine Python with BQL, our server-based Bloomberg query language, to create sophisticated data efficient research and applications. For those in the know, it was previously known as BQuant, and had been part of a limited release for the past (by my estimate) seven years.
With the new re-release and rebranding, came long-awaited enhancements such as a cloud hosted browser-based platform that frees users up from the constraints of local installation requirements. Debugging on the platform has become far more intuitive and (I believe) Plotly Dash has been integrated for visualisation. What hasn’t changed, is the need to help users overcome the important challenge of both learning a Bloomberg specific query language in a Python object model. It’s a challenge that led me to the world of Product.
Getting into product management is notoriously difficult at the best of times. With economic and market uncertainty at a peak and constant news of tech lay offs, it is arguably harder now than in recent years and not many companies outside of Silicon Valley have Associate Product Manager (APM) programs, which are essentially entry-level graduate programmes for PMs. A quick search on LinkedIn shows 36 APM jobs posted in the UK vs 1,600 PM jobs.
So what is one to do? A common question and answer that I give is that the answer doesn’t usually lie in product management certifications. While everyone’s path looks different, I’m sharing my story in the hopes that it helps you to find your own.
From Excel to Python
Back in my days as a developer, one of my primary goals was to help customers adopt the Bloomberg Query Language (BQL), our new query language. BQL is arguably one of Bloomberg’s most significant development in recent years, by allowing customers to apply SQL-like capabilities such as dataset combinations, filtering and grouping (same as your Select, Where, Groupby) to get valuable insights in a fraction of the time, without the need to download raw data, cleanse, and then run the analysis. These days, BQL is also steadily being adopted across Bloomberg infrastructure, introducing new efficiencies and capabilities along the way. The easiest access point is via Bloomberg formulas in Excel, where you can express your data request either as =BQL() or =BQL.Query().
While wow-ing the user was easy enough, getting them to adopt the new language was much harder since the request paradigm was completely different to traditional Bloomberg data requests. For example:
A “traditional” Bloomberg formula for IBM’s latest stock price, based on security and the data you’d like to retrieve looks like this:
=BDP(“IBM US Equity”,”PX_LAST”)Of course, you need to have knowledge of the mnemonics for what you’re requesting, but so far so good.
A new style Bloomberg request for the average price per sector for the constituents of the S&P 500 Index:
=BQL.Query(“get(avg(group(px_last, classification_name)))for(members(‘SPX Index’))”)Cue the blank stares. 😳
Our target audience were time-strapped finance professionals, not technologists. How do you inspire them to invest the time to learn something new?
From my conversations with customers, what really resonated with them was the application to their real-life workflows. The fixed income analyst who needed to create watchlists of top and bottom movers of spread in the last month. The credit analyst who needed to analyse the leverage and debt to equity ratios of bond issuers to identify potential spread movement. The equity analyst who needed to create custom scoring models based on different technical and fundamental indicators to compare stocks to their peers. The query language allowed them to run the analysis much faster and more efficiently than before, but they didn’t understand how to create these requests themselves.
Starting from scratch is a daunting task. As with most modern website builders, dashboards and other products, templates give users a structured place to start. Since users were working primarily in Excel, I started to build Excel templates based on the use cases I’d seen, which I would send out to customers on a monthly basis. Why don’t you try to analyse the top 10 bonds by spread change over the last month? How about year to date? What did the picture look like for yield or duration? Every client I met, I added to my email distribution list (with their permission) and I gathered feedback along the way. Over the course of a year, I scaled this to my team and what became known as the “Spotlight” series steadily grew to a distribution list of 20k users.
With the experiment yielding good results, how could we scale this to the Python environment?
For that, I created a vision for the user journey.
Getting the buy in: Just like the Excel templates, users needed to first understand the applications for the new query language in the programming environment to see the value of adoption. How would this save them time and money, as well as generate alpha for their investments - which is really what they cared about?
Creating customised learning paths: When they began to buy in, they would need to be guided on how to use the new tools specific for their needs from basic to advanced applications. The fixed income analyst didn’t need to be understand calendarized fundamentals and the equity analyst had no interest in coupon reinvestment rates to calculate total return.
Facilitate self service and discovery: Once they adopted it, they would need an extensive library of examples and documentation to be able to reference and help themselves to continue growing over time.
By the end of the global project that I led, we had:
Dedicated asset-class specific Python examples, many based on the previous Excel templates, accompanied by tailored marketing material and webinars
Step by step guides per asset class from basic to advanced
A comprehensive code repository and documentation on how to use the query language, that became a core part of the platform with help from Engineering
Spoiler alert: it worked. The user feedback was positive and usage steadily grew over time. But I wanted more. I wanted more data to understand how users were using the product and identify how to make it better. I wanted more influence in what was being built for the product to address the limitations our customers and our team reported. I wanted more agency in defining the vision of a product, who it was built for and what it was built to solve. As time passed, becoming a PM became a clearer and clearer goal - one I was determined to pursue.
Translating experience to PM applications
When I started to apply for product applications, I did my best to translate my experience to product capabilities.
Understanding Customer Problems
Experimenting and Prototyping
User experience mapping
Building a feature with Engineering
In my interviews, I would use the STAR technique to tell stories of how my experience and skillset showed what I’d bring to the table as a PM. In case you’re not familiar, STAR stands for Situation, Task, Action and Result.
Situation - Give context of the situation you were dealing with
Task - What you had to do
Action - How you did it
Result - The outcome
Reference material on the STAR technique is ubiquitous, so I’m not going to go into it in detail. Google and ChatGPT can give you plenty of help here. Where it comes really useful for PM interviews is to give structure to your story. Ultimately, the story you want to tell is your ability to understand customer problems and proven ability to build solutions that generate value to the product and the business.
Even then, it wasn’t easy - it still took me a long time and endless rounds of interviews to get there. I wrote about that here: the Power of Failure.
So rather than taking a product management course, pick a real life problem and work on solving it. Test different ideas. Better yet, network with PMs and work on projects with them. Being able to take an idea that you’re passionate about, iterative develop a solution, take it to production and scale is an incredibly powerful story for someone looking to become a new PM. For me, that project was helping users to adopt a new language they’d never used before, on a platform they had never used before. Everyone will have a different story to tell.
These days, the newly rebranded Bloomberg Lab has a fully developed documentation website where users can search and navigate all things related to the Bloomberg query language, including data items, functions and data universes. The experience is clean, smooth and consistent: you can see the work our UX, VX and Documentation teams have put into it.
Curious enough, a lot of the material I created still exists on the platform and the shortcuts we created still work. What was meant to be a stop gap solution created 5 years ago still exists today, likely because of the value of workflow examples. Seeing the definition of a word in a dictionary is very different to seeing it used in a story that you want to hear told. Seeing it again reminds me of the countless hours I spent at my desk, locked in my bedroom amidst a global pandemic, writing, testing, sharing with customers and iterating.
The path to Product is often not an easy one, full of twists and turns, and disappointment is not uncommon. The good news is that it can have a happy ending, if you give yourself the right chances. Once you’re in the beautiful mess of it, you may wonder why you tried so hard to get there in the first place…but that’s a whole other story for another day.