AMA: HubSpot Senior Director of Product Management, Fintech, Zeeshan Qamruddin on Building a Product Management Team

The great thing about being the first hire is something that is also great about Product Management: there is room for interpretation. My philosophy has always been more heavily focused on understanding how things operate current state, finding out pain points as well as the more successful parts of a product, and leaning on those insights to form your next steps. In certain scenarios, what a team may need is for someone to roll up their sleeves and do the work to keep the lights on for a product. It may be months before you can get the product to a comfortable enough place to think about weeks, months, or quarters ahead; however, that time allows you to gain knowledge of the product itself. In other scenarios, a product may be operating just fine, and your task will be to understand where it can go next. Your time will be spent with customers, stakeholders, engineering and others to understand the areas of opportunity that exist. You don't always need to reinvent the wheel or start from zero just because there was not a product team in place.

This is a situation that our team went through last year, scaling from 2 PMs to 10 over 12 months. Before hiring any additional PMs, we first took the time to survey the teams that existed in our current state. We reviewed the tools they owned, their missions, their place in the lifecyle of the motion that we support (Quote to Cash), and made our decisions from there. Certain teams needed to be consolidated, others needed to be created, and some simply needed more structure. With a plan in hand, we outlined our most critical hires; we focused on Senior Product Managers that could take our initial vision and existing teams forward. The goal was to stabilize core areas of the overall set of products that we owned first, which would buy us time to expand on that vision and thoughtfully set up the new structure. For areas that were lower risk, or that had established Engineers leading the team, we brought on PMs, knowing that they would have more room to figure things out. Finally, once SPMs had established stability over the teams they were brought on board to lead, we added APMs to ensure a healthy pipeline and create opportunities for those looking to break into the space.

At the company level, there are a few different methods of communications to keep everyone abreast of updates: 1. Product Notification emails (Ad Hoc) - These emails have a set template and allow product teams from around the company to share updates to their areas in a digestable format as major features go out of the door. 2. Product Newsletter emails (Weekly) - The weekly newsletter summarized major product updates and initiatives to all product team members. 3. Quartery Business Review meetings (Quarterly) - These larger meetings gather key parts of the business to talk through major updates each quarter, including an opportunity for the C-Suite to interact with and pose questions to respective teams. 4. Quarterly Kick-off meetings (Quarterly) - These meetings are specific to our Product Area and include our stakeholders; each team in Fintech is able to share wins from the prior quarter and plans for the coming quarter. 5. Slack Updates (Ad Hoc) - For major releases, the PM will often post a message in our global product channels to notify the broader group of the change. This allows an opportunity for the team to be recognized, as well as others to be informed about the update. 

This is a scenario that teams often find themselves in, especially in fast moving parts of a business. The question I would ask when looking across the existing products is "Where do I gain the most leverage from innovation?" There are certain products that simply need to work, and that have a built in runway so as to not detract from the companies success. If there is an opportunity to simplify an unnecessarily complex product, such as leaning on a 3rd party or making a capital investment to enable self-service, that time should be carved out early on to avoid growing the burden of support. Other products, however, can drive the business or particular segment of the business forward. Those areas should be prioritized and receive attention, while you plan to address the products with a longer runway further down the road. In the short term, it is critical to understand the value that those products bring, and the leadership investment should follow accordingly.

Today, our org structure follows the ethos of "Small, autonomous teams". In this structure, we generally have a PM paired with a Technical Lead (Eng), somewhere between 3 - 5 Engineers, and a Business Systems Analyst to focus on operational and analytical tasks. Some teams have a Design/UX representative as well, where applicable. Hierarchically, we have these teams organized into Pillars, with a shared broader mission/remit. Pillars are led by a triad, with a Senior PM, Product Lead, or Group Product Manager aligned with an Engineering Lead (above TL) and a BSA Lead or Design Lead where relevant. Finally, those Pillars roll up into Groups, where the Director level can provide guidance to the respective teams. The main thing to note about these structures, though, is that they take time to mature; where we are today is a step function change from where we were last year. Eventually, I do hope to land in the formation outlined above, but we will continue to transform as individuals grow in their roles or are brought on board over time. 

As I mentioned in another answer, lean on those around you; there is a wealth of knowledge to be amassed from stakeholders and peers that have likely interacted with the product that you've been brought in to support for some time. Those same team members likely led to you being brought on board to begin with, so learning as much as you can will set you up well for the future. If you can come up with a clear set of goals for yourself, it will be immensely helpful to gauage your progress. For example: 1. 30 - 60 - 90 Day Plan; there are plenty of online templates that can give you a baseline 2. Putting together a presentation of what you've learned for your leaders or peers after a certain number of months 3. Putting together a draft roadmap for the Product after certain number of months The best thing you can do as a new PM is avoid putting undue pressure on yourself, or feeling that there is an expectation to be met. Putting in the work to understand what the product needs will generally land you in the right place every time.