In this article, Julia Austin considers what qualities make the ideal Product Manager, and contrasts the different expectations different kinds of organisations may have of them.
First and foremost, Austin argues there are three areas where a Product Manager must excel to really prosper in a role: core competencies, emotional intelligence (EQ), and company fit.
Some of their typical core competencies (such as revenue modelling and requirements gathering) can be developed with experience, good role models, and mentoring. But, as for EQ and a passion for the product they are managing - these are often unique to the individual you are recruiting. They are clearly the most difficult things to counterfeit or train for.
When you get the right combination of these qualities, though, you can often see spectacular effects on the fortunes of a product - as it is launched, nurtured and improved in cycles by someone who really cares and has the skills to really get things done.
But there are other factors at play in determining the right fit for a Product Manager for a company, including the overall organisational and development culture your business favours. These structural considerations include the following preferences, and have various strengths and weaknesses:
In some organisations, software engineers are dynamically driving forward research, ideation and feature set definition.
In these cases PMs are serving those engineers, who are often pioneering novel approaches and new science. PMs in this scenario are facilitators, validating solutions or creating front end access points (UIs, APIs, to tap into this technology). They can add huge value by making things happen, co-ordinating contact between developers and clients, translating technical ideas into workable product propositions and business cases.
Engineer-led product management often leads to the emergence of breakthrough technology. Engineers following a hunch or a passion project, with the support of a good Product Manager to validate and figure out how to monetise it - can often bring really ground-breaking features into the marketplace.
Given too long a leash, though, developers can be constantly adding new functionality, iterating forever and over engineering at the expense of a product’s commercial viability.
In these scenarios Product Managers lead a classic waterfall development process in what Austin refers to as the ‘Throw it over the wall approach’.
The PM is the authority on the customer and the competitive environment for their product suite. Part of their function, initially, is to gather customer needs and set them down in a ‘quintessential product requirements document’, the definitive description of what the product needs to do. At this stage, it is handed over to the technical function of a business, who will spec out the technical requirements of the product before development can begin. This may be carried out in a more or less agile fashion, but in essence, the PM knows best about what customers need. In these companies, engineering is there to deliver on those insights in the most focused and efficient way possible.
In these environments engineers can focus on coding without distraction. This Product Management process works for products with long life cycles or where needs and use cases are straightforward, and where product road maps are well understood and predictable.
Engineers can lose sight of the big picture and empathy with the client. Unhealthy tensions arise when technical debt and simple product maintenance needs to be prioritised over customer requirements
In these cases a more hybrid and truly agile approach to product management prevails. Engineers join PMs in customer interviews, PMs are in Sprint meetings to unblock tasks or clarify requirements. In this scenario there is a balance of influence arbitrated by the PM themselves. PMs understand what’s being coded, but don’t tell engineers how to code. Engineers have empathy for customers’ needs, but leave prioritisation to the PM.
Streamlined prioritisation takes into account maintenance and innovation. Better design process can be developed that more carefully balances customer needs, technical constraints and commercial opportunities.
Time to market may lag, as multiple stakeholders are managed and consulted to reach the right outcome. At the same time, breakthrough innovation may not always make the market as the balance between managing the risk of commercial failure and seizing opportunities is struck.
According to Austin, there are other factors, too, that may determine the kind of Product Manager and process from which your business will benefit most. The kind of Product Manager you need is a function of your company’s scale and maturity, as well as the culture and the sector you are operating in. You may also want to consider what role the CEO might want to play in the development and iteration of their product suite, and how they will likely want to work with the PM.
One area, though, that Austin does not consider, is the kind of digital tools that a Product Manager should have access to and how their practice can be enhanced by them (or otherwise). These will have a significant impact on their ability to manage and deliver the kind of insight and continuous improvement strategies necessary for their role.
What’s more, companies necessarily don’t remain static in their size and organisational structure. The role of the Product Manager may develop over time, processes may need to be strengthened and formalised in particular ways or reinterpreted to accommodate an evolving agile process.
Even for small companies, therefore, managing any complex development process using a combination of emails, Google Docs, Dropbox, or IM products (like Slack) may not serve the PM as was as a product management focused DMS (document management system) which could be used and accessed by collaborating individuals in an organisation.
Why not just use Dropbox as a document management system?
Choosing a lean DMS where non-coders can set up and change the workflows that define the various phases of a gated process, can give organisations extraordinary flexibility
to optimise and evolve the way they work. They can help you automate and calibrate your Product Management processes to reflect your company and sector’s specific needs as well as the scale of your operation.
When you are looking for a Product Manager to fill a gap in your organisation, it’s worth also considering what tools they (and you) will need to deliver the velocity of co-operation your process requires.
At the same time selecting a Document Management System early on that can help you robustly control the competing demands of a product cycle will help any PM deliver on their goals more efficiently.
Finding one that can scale with you, that you can also customise according to the demands of working within specific regulatory environments, could, in the long run, prove to be indispensable.