7 Tips for Software Platform Product Managers From an Engineering Manager
As software applications get more complicated, being able to re-use existing components is becoming more important to accelerate time to market, save development costs and provide a higher level of product quality and reliability. Corporations now build their own platforms to achieve these goals. Platforms, as defined here are a set of subsystems and interfaces that form a common infrastructure so that related products can be developed on them.
With the development of platforms, platform product managers need to organize and give direction to the platforms. This, in my opinion, is a very challenging role and differs considerably compared to traditional product management. Melissa Perri makes great points about technical product management in Escaping the Build Trap, I would like to expand on her points specifically for platform product management and provide some tips for platform product managers, from an engineering manager's point of view. I also decided to put a hard limit to the number of tips at magical number seven
- Beware that platforms have major differences from other software products
Corporations develop platforms to have a solid foundation for developing new applications on them. Reliability, latency, security, being able to fix bugs quickly, continuous integration capabilities, and clear documentation are some of the critical factors for platforms. Typical customers of platforms are developer groups (backend, user interface, etc) in the same company or developers at external organizations. Customers of the applications that are developed on the platform are distant from PMs in this context. Interactions with sales teams would be very limited, if not none. Prioritization processes are very different as well, you will have to deal with competing goals and politics within the company where one product team (that is a client to your platform) has a different set of priorities or deployment needs than another product team. Platforms should have an engineering culture to not own product-specific logic and features. Some features must be implemented at the application level, platforms can not carry too much business logic. These factors contribute to a unique platform product culture.
2. Do not dictate from high
I think this is true for product managers for all types of products but it really gets more profound with platforms. It’s a big mistake to pay big salaries to engineers who work on the product and who collaborate with respective customers daily and then dictate what should be done. Instead, managers should elicit feedback from these engineers to help create/maintain/update the product in question. If you use a top-down, mono-directional communication channel, rather than transparently discussing and sharing, you will most likely alienate yourself and most people, including your team, will not want to work with you. There is an incorrect cliche around product managers being a mini CEO. Product managers are not mini CEOs, they can not fire someone, in most cases, they don’t manage engineering teams directly. My strong recommendation is to really focus on “why” and try to influence the team. If you can persuade and inspire the engineers you are working with, then you are all set.
Aside from not dictating, you really have to have new ideas coming from your team. Platform product management requires getting the best out of the teams you are working with. Your engineers would be in touch with some of your customers (in some cases, other engineering teams in the company) and they would have insights into the customer needs. Because platforms serve product teams, product teams will always request features but you have to have your own ideas for features and your team can be a great resource here. If all the product ideas or all the features being implemented are coming from the customers, then you are really missing this part and things need to change.
3. Develop great relationships with Quality Assurance (QA) and DevOps
Reliability and quality-related metrics are among the most critical success metrics for platforms. Therefore, quality assurance teams have a central role in the platform lifecycle, from inception to delivery and beyond. Ideally, QA teams know the platform aspects in a broader sense compared to individual developers working on it. That’s because they need to have an end-to-end approach testing it and they also get involved in applications developed on the platform whereas a given developer could be focused on a set of capabilities of the platform. Therefore having a strong QA culture and having deep relationships with your QA team are must do.
4. Pay a lot of attention to interfaces
In my experience, the most time-consuming aspect of platform development and management is around managing how the platform interacts with applications (upstream) and services and capabilities that the platform needs (downstream). If managed poorly, interfaces can cause significant inefficiency and a lot of unnecessary communication. This is where I think a clear technical documentation team is vital. It is also important that this team should not work in isolation but with customers, developers, and QA. Wiki pages regarding how things work, clearly documented error messages, easy to browse and traceable logging capabilities are must-haves in platforms and your documentation team should be involved in these steps.
5. Similar to any product, platforms need the definition of success, vision, and metrics
Ideally, as a product manager, you need to talk to your customers and stakeholders continuously and develop a vision for the product and you should try your best to explain this vision to the technical team. Knowing the vision well, your team can also make decisions better. Vision also sets a team culture and things become muscle memory in environments where people work towards a known and shared vision. For beginners, it could seem difficult to set a vision for a platform beyond being able to support new applications. It could get especially challenging if the platform has deeply technical components (such as a non-linear optimization library or deep learning library etc) attached to it. But just like any other product, platforms need to have a vision, metrics, and a clear definition of success. Regardless of the technical complexity, starting with high-level business goals is a good first step. Typically a platform would be judged by its reliability, time to implement new features, time to fix bugs, etc. Perhaps for deeply technical components (let's say your deep learning team), it could be more challenging to define parameters and associate those with business goals but being able to understand the high-level parameters of these components, being able to articulate how these parameters impact customers and combining these specific parameters with common platform expectations is the key. For the entire platform team or for sub-teams, you should be able to define what it is that you are expecting from the team and what success means for the team.
6. Focus on why and what, distribute the ownership
It’s common (although absolutely not necessary) to see platform product managers have technical backgrounds. One challenge I have observed is that those with strong technical backgrounds love to discuss the solution and “how” in detail. Although engineers don’t mind product managers being in design discussions overall, product managers should really not own or develop the solution. If you don’t let engineers own the solution and try to come with a solution that you mandate on the team, then your team won’t feel ownership and you are doomed from day one. It’s another recipe for disaster if a product manager works with someone who is not in the implementation team (perhaps an architect or a consultant) to develop a solution and pass that solution down to the implementation team. If you do this then your development team will end up not having ownership.
Very important to highlight that product management and product ownership aren’t the same. Product ownership is a role in software development that relates to maximizing the value of the product that results from the work of the team. It has operational steps such as creating a backlog, writing user stories, writing acceptance criteria, grooming the backlog, and more. Product management is not just a role but a career. Product managers could play product owner roles for scrum teams but they don’t have to. As the product manager, you want to distribute the ownership of the product as much as you can to have engineers feel ownership. It may not work for all instances but in my experience in the most efficient teams, engineering leads take product owner roles working with the product manager. Product managers need to keep an eye on these activities and interrupt when the team is fading away from the vision. This step can sometimes be challenging if the engineering lead is also a very strong product owner or if the product manager joins a team where the engineering manager has been working for years as a product owner. Working with a strong engineering leader needs to be viewed as an opportunity to scale more for product managers and collect more data and spend more time with the customers.
7. Share data and decision process
There is always a level of uncertainty in product development. PMs need to make decisions with data and they need to be talking to stakeholders, customers, partners to continue to collect data to make decisions. I have seen that to be extremely beneficial to share some of the data and the data collection process and some of the uncertainties with the engineering team (developers, QA, DevOps). Not only the team will better appreciate the work you do, but they can also come up with out-of-box ideas that could yield alternative solutions. Especially when the product is highly technical, most of the customers will also be engineers who use this product and your team’s ideas could be very useful. It’s a practice idea to write emails and notes monthly to your team and share those data points. You know you are doing well if engineers seem to be interested in your data and data collection process.
It’s also important to continuously collect data from your team in terms of feedback and new ideas. It’s also a good idea to randomly chat with team members informally and try to observe if they have a good level of understanding of what matters most for the product.
The views and opinions expressed in this article are mines only. I’d like to hear your opinion and experience regarding challenges and ideas around managing a platform. See my contact info to connect with me.