How to Manage Complex Products

I am lucky to have worked with many technically-complex products across different domains, ranging from trading engines, cloud block storage solutions to building RAG-enabled products in my product management career.

It is easy to assume that Product Managers only work with products that are clearly user-facing, but we can also work at different levels, including managing engines and technical services that power the rest of the product where user journeys are less important. Working with such products presents a unique set of difficulties compared to user-facing products, and they often do not align with popular product management frameworks.

The challenges I faced when I first started working in a new role with a complex product can be summarised as follows:

1. I don't know what I am looking at.

2. I don't know the answers, but people are throwing questions at me.

3. I don't know who this product will really help and how it will help them.

4. I don't know how to measure success or show value in a business sense (the most common measures would be revenue or Profit & Loss (P&L)).

Based on my experience, here are some things I have learned that should help tackle the challenges above:

Problem 1: I don’t know what I am looking at

Solution: Study the product, domain and technology closely

When I started being a product manager, I was still in the FinTech space. It was an easy transition as I already had a decent domain knowledge when I started.

However, when I started working for a CloudTech company, I had little knowledge about Kubernetes. I needed to build an understanding of what the cloud infrastructure space looked like, who our competitors were, how developers (the users) expected to use the product, and, finally, what type of challenges the product was facing.

Some of the things that have been useful include:

1. Do an online course or read online articles: Online courses offer a decent structure to get started on a brand new topic. I personally found it very useful to have done a course on Accounting basics when I was building an Expense product that was used by the Finance and Accounting team, so I could ensure the product terminologies could resonate with them.

2. Use the product like a real user: There is no better way to empathise with your users than actually becoming one. It is usually quite easy to do that as with a consumer-facing product, but much less so when working with a technical product. This means that making use of every opportunity to simulate and learn about user experience and understanding pain points is extremely important. When I was a product manager at the CloudTech company, I learnt to deploy my own Kubernetes clusters, tried to perform an upgrade of the software on my nodes and so on. This experience made me much more aware of how complex the product was, and what type of technical hurdles there were so we could improve our product's experience.

3. Interview relevant people (and don’t forget about your tech team): As product managers, user interview is our key tool to gather qualitative feedback. Don’t forget your tech folks at work - they might be rather similar to the end users for the technical product you are working on. Interview them and share the insights, so you can also help them to gain a better understanding of what they should pay attention to when making technical decisions.

4. Monitor bugs and feedback closely: Triaging and analysing issues and client feedback are underrated ways to learn quickly about client expectations and the weaknesses in the product. We can spot trends and identify broader themes to help inform the product roadmap.

Problem 2: I don’t know the answer, but people are throwing questions at me

Solution: Have some humility and learn from your technical team

When joining a new team, one of my top priorities is to build a strong, trusting relationship with the engineering team. This is important not only for understanding their needs better but also for learning from experts who naturally have a deeper context and knowledge of the product's strengths and weaknesses. Once trust is established, it facilitates smoother delivery, reduces project risks, and helps manage stakeholders' expectations more effectively.

While product managers are not generally expected (within the product organisations) to be experts in technology or to understand precisely how things work under the hood, having a decent grasp of the technical details—particularly for products powered by complex technology—can be highly beneficial. It is easy to assume that product managers should focus solely on what to build and why, but without at least some domain knowledge, it is easy to miss critical information during discovery and delivery phases. For instance, my ongoing experience with complex products has significantly improved my ability to identify risks to timelines in infrastructure or migration projects.

As product managers, we are often required to make decisions quickly due to deadlines, stakeholder or client demands, or unexpected incidents. The pressure to demonstrate leadership in a constantly changing and chaotic environment can sometimes deter us from asking questions and gaining a deeper understanding of the domain and technology. However, it's crucial to show humility and a willingness to learn, especially when navigating a new domain.

Taking the time to fully understand requests and asking for help when needed is essential. Pretending to know everything, or worse, throwing your team under the bus when things go wrong, can be far more damaging to relationships.

Problem 3: I don’t know who this product is going to really help, and how it is going to help them

Solution: Even when the product is complex, first principles still apply

It's easy for a product management guru to say, “How is it possible that you don’t know who your users are?!” But once you've worked on a product that hasn’t found product-market fit, or one that is strictly internal-facing, you’ll understand why I list this as a top challenge.

When working on a product powered by complex technology, there can be more hype around the technology itself than whether the product is solving the right problem or has a product-market fit. This issue still exists in parts of the technology landscape (looking at you, AI...), but it was much more rampant back when getting funded was easy.

One company I worked for focused heavily on backend technical prowess but didn't consider the user experience or whether the features truly addressed user pain points. They believed the technology would sell itself, leading to numerous unnecessary features and product rewrites that wasted time and resources.

Most users don't care how complex or cutting-edge the technology is; they only assess the product based on whether it helps with their workflow.

Hindsight is 20/20, and these are the things I would have done instead:

1. Identify user pain points: Ask ourselves - What problems are we trying to solve here? Are we thinking about the solution before correctly identifying the problem?

2. Don’t be arrogant about your ‘cutting-edge’ technology: Technology is just a means to an end, and there will always be better, faster, and stronger technology available. It's more important to focus on improving user experience and reducing friction in product workflows.

Problem 4: I don’t know how to measure success or show value, in a business sense

Solution: Advocate for your team and establish a clear understanding with stakeholders about what success looks like

It is a classic problem, especially for Technical Product Managers (TPMs), who usually only work on purely infrastructure work.

Having worked in the technology division of a bank, I understand that measurement and targets are critical because they are directly tied to people’s compensation and project budgets. In many corporations, the technology division is seen as a cost centre rather than a profit-generating department. This makes it much harder to gain the hype, recognition, or budget compared to working for companies that sell technology, where product and engineering teams are seen as revenue-generating.

This blog is not Blind (don’t spend too much time on it by the way), and I probably don’t have better advice than folks there for office politics - but I do still have some suggestions to help you grow as a product manager in this type of environment.

It is extremely important to identify and agree what good looks like for the product, even if it is not revenue-generating. Something to look out for:

1. Is it going to help to reduce cost? If so, what is the target, and who is going to benefit from it?

2. Is this going to improve the performance of the product? (e.g. Speed, accuracy, precision, success rate, risk reduction…etc.)

3. Is this related to a must-do objective in your company strategy? (e.g. a regulatory requirement that has a deadline, an audit item that would block a key strategy)

It is important to align your team so that they understand and agree with the metrics and goals established in collaboration with your stakeholders. This alignment not only makes it easier to demonstrate the team's value but also boosts morale and ensures that everyone is focused on building and improving the right things.

Conclusion

Managing complex products can feel daunting, especially at a new job. By using skills you already possess, such as continuous learning, showing empathy, and being open to new relationships, you can drive innovation and create impactful solutions that deliver real value to organisations and users. This will help you push your career forward in no time