Zeeshan Qamruddin

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.

Roadmap communication is often just as critical as developing it in the first place. Our team has a number of internal stakeholders that are directly impacted by the decisions we make. When we consider the level of detail, we try to anchor Goals and Plays. Goals ensure that we are focused on the right thematic areas, and our goals are prioritized before the start of the year. We socialize our goals and their priority level to help teams understand where we will be focusing, and why. Plays are a level deeper, tying to actions that we will take, features that we will build, and tangible deliverables that will help move the needle on our goals. Plays offer us the ability to understand effort, timing, and dependencies, which can then be socialized for everyone else to see. This empowers our teams to understand who is doing what, and when, for a quarter or half-year at a time.

This is often the case for companies in a hyper-growth state, especially as they look to find a clear fit in the market. Where I've found success with leadership is by helping them understand the trade-offs in our teams focus. For example, when planning out our team's work, we lean heavily on research and a few key metrics to prioritize. When faced with requests from leadership that may not align, we try to create an apples to apples comparison (though not always perfect) to help bring clarity to the trade-off. Two things are critical here: * Being clear about the capacity of the team, and the realistic implications of having to trade-off (vs attempting to do both simultaneously) * Leaning on data wherever possible. Data is not biased, and likely will help leadership understand your perspectives if the segment that you're looking to focus on differs from the ask.

Finding the right balance of leadership input to infuse in roadmap planning is always a challenging endeavor. What has been most effective in my career is coming to the table with a clear perspective and reasoning for prioritization. As a leader, staying in tune with the business should allow you to preempt those initiatives that are top of mind for your executive team. It is absolutely not an exact science, but building a bridge between 1. The company/executive priorities and 2. The areas that you would like your team to invest will create an organic overlap for the top items on the roadmap.

These are prime scenarios for a Product Leader, as they can use their own research and perspectives to help C-Suite understand the most beneficial bets to place. With a new leadership group, teams have the opportunity to reset on the legacy items that plagued them in the past. For example, upon taking over our Product Area in my current role, the first step that I took was to present a clear perspective on where our team could go. Because there was no leadership team from which I was taking the reigns, the company needed a point of view to be presented and owned. Painting the picture of what our team could be, the steps we would need to take to get there, and outlining how that would directly benefit each of them allowed C-Suite to provide support around an informed perspective.

Ultimately, communicating about your product should tie to the outcome that you hope to drive. When pivoting a product, I've found it's most helpful to be honest about the process the team is going through. Sharing less information with higher quality is far more valuable than any other course of action in these scenarios. For example, when our team was stuck in a rut due to poor Org Design and a mountain of tech debt, we went to our executive team with a clear message. We needed time to unravel and unwind much of the legacy issues from the past. We believed that by taking this time, we would be able to position our teams in a way that would allow an exponential increase in our teams ability to solve their core issues (around interwoven code and tech debt). We did not have an explicit understanding of exactly how long this shift would take, or what the outcome would be, but we did commit to regular updates on our progress. Setting these very vulnerable expectations and committing to continuous communication brought our customer (the leadership team) along on our journey.

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. 

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.

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.