How to succeed as a Data Platform Product Manager
Based on the earlier posts explaining how to understand a platform customer, how to set good goals for your product and how to work well with your partners in the organization, here’s how I think a data platform product manager can thrive in their role.
Customer empathy
Of course, all product managers should have deep customer empathy. What does it mean though, in the world of data platform product management?
First, you need to understand the technical details of your platform and products — not necessarily to be able to code or manage the system as a sysadmin or DBA, but well enough that you understand those areas so you can make them better. You would need to know exactly how a developer (or someone playing that role) works, and where they see challenges in their workflows.
Knowing how your platform works and what challenges your customers face will help you figure out what value you can add as part of a product or a feature within a product.
Business goals
While understanding what the customer needs is critical, the important thing with data platform product management is that you won’t be able to justify new investments purely based on customer needs. This is where being able to link your work to the company or organization’s goals will be of utmost importance.
This is also where you can start linking some of the market and industry research you must do anyway, to real customer pains and to advancing the state of the art within the company. Bringing innovation or new ways of working to your company should also be on your agenda, of course if it is solving a customer’s problem and helping the company get better in some way.
Once you can demonstrate that your products help achieve certain parts of a company’s goals, the conversation about continuing investment in the area will be a lot easier.
Vision, Strategy, Roadmap
With the clarity of the customer problems and how they link to business goals, you should be able to define a bigger vision for your products and based on that vision and the current state you can create a strategy on how to build towards that vision.
The strategy is the most crucial part because this is what you will be selling to your leadership and all your stakeholders. If they buy into the strategy, you can break it down into chunks of deliverable roadmap items. Until then, working on tactical items is futile because it can be shut down at any time.
The roadmap should also consider options to create something internally or leverage a commercial or open-source off-the-shelf product. The details don’t need to be fleshed out, but the analysis of what’s available in the market should be included so that the typically scarce engineering bandwidth could be used for things that can only be done by internal teams.
For clarity, the way I see a roadmap coming from a product manager is a set of goals (milestones) to be achieved along a finite number of strategic pillars (workstreams). I don’t consider the actual timelines as part of a roadmap, but I have seen those two things conflated.
A roadmap is something that shows what’s coming on the road while an execution timeline is what depicts when we are going to make it to each of those milestones.
(Time-driven milestones are common and can be accommodated by adjusting scope and delivery goals but should still be considered part of execution timeline and not a roadmap.)
Relationships!
The buy-in of your strategy and the execution of the roadmap will be successful if you have all your stakeholders including the critical partners aligned (as discussed earlier).
Specifically, you need to build and cultivate relationships regardless of whether you need immediate help or not. You need to exchange ideas, provide input to each other as partners working together and of course help each other when help is needed.
These relationships span:
- Engineering: Your closest partner. You need to make sure there is adequate capacity devoted to your product. If there are sticky situations, you need to be able to request capacity shuffling, so your product development can continue. Everyone from the leader down to managers to tech leads and even individual engineers should be aware of what is being built and how it helps the organization and the customers to use the products.
- Architecture: As described earlier, you need this relationship to help bring innovation into the company and to ensure products and platforms are built correctly and are being used the way they should be.
- Governance: Another critical relationship to build since they help interpret the legal language so compliance can be built by design. With a great partnership, you can even rely on Governance to help defend what you have implemented as being good enough to satisfy the legal requirements imposed on the platform. This will become exceedingly difficult for you if you don’t have a great relationship with Governance.
- Direct and indirect customers: Your direct and indirect customers will provide you with the most impactful feedback — whether your product is working as intended or not. You need to build these relationships so you can improve your products and at the same time, leverage their help to start linking your products’ features to their key results so you can demonstrate the value delivered more clearly. Indirect customers will also give you some insights on potentially broken workflows or processes which you can influence to change.
- Direct and “diagonal” leadership: I have worked at a lot of matrixed organizations and building a relationship with your skip level management peers is as important as building the relationship within your org. As you start growing in your career at a company, it is critical that your stakeholder leadership sees the value you are adding.
For a product manager, the ultimate compliment should be a customer saying they enjoy using their products.
Storytelling
Much like a traditional product manager, an essential ingredient in the recipe to become successful as a platform product manager is the ability to tell a story. It does not matter that the customers are internal, they still have a journey, and they encounter challenges along the journey that you are helping solve.
The story to tell starts with explaining the customer journey and how your product’s vision will make that journey become easier. A delightful story is also essential to pitch the strategy to your variety of stakeholders so they can opt in and be part of your products’ roadmap.
Also, storytelling is critical for communicating the value delivered through your products — how is a feature helping achieve what it sought to achieve, what kind of needles are being moved by your products on a regular basis, etc.
Finally, you need to be a good storyteller about yourself.
What is your personal brand image? How did you improve the products and how did those improvements help the organization? What is your role in a company’s transformation?
Speak at small and large events. Write blogs internally and externally. Get the word out so you can stand by yourself and not be attached to a single company, single technology and a single set of management and leadership.
Metrics, metrics, metrics
I have stated this at the end, but it is not because it’s the least important thing to focus on. Quite the opposite, in fact. Metrics are extremely important for a platform product manager as I stated in the goals and North Star post.
Your role is to have your North Star defined at the strategic level and then have it cascade down to big rocks and smaller rocks.
Every single smaller rock should have one or more metrics associated with it — whether they are direct metrics for the platform, like cost management, or indirect metrics for end users like enabling top line growth.
In addition to clearly defining the metrics, naturally you will also need to prioritize measurement of those metrics as part of building your product and features. If you only deliver 50% of the feature set, for example, are you able to articulate what is the impact on the value delivery? Is it 50% of the intended value, or more, or less?
Just like a traditional product manager, you cannot build a feature without instrumenting it so you can see the adoption and usage of that feature. As a product manager, you need to know who is using your product, how they are using it, how much they are using it and do they have enough avenues to provide quantitative and qualitative feedback on your product. This instrumentation must be embedded from day one and should be part of the definition of done of any feature.
Note: this may be a very new concept to your engineering team and there may be groans and push back around being so metrics-driven, but you need to stand firm and be able to communicate why it is important. This is just one more example where having a great relationship and partnership will come of use.
I hope this series has been helpful to you. Please do let me know.
I will conclude this series next with comments on how to be an effective platform product management leader and provide some closing thoughts.
