Navigating the Product Management Process: Finding the Right Fit

Product Management ProcessHow do you need your product management process to function? A classic article in the HBR got us thinking about the different roles Product Managers play in different organisations and what kind of skill set, background and tools can serve them best.

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.

Finding the right Product Management fit

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:

Engineering drives product management

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.

Product Manager drives Engineering

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

PM/Engineering partnership drive projects forward

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.

Other factors

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.

What tools will they need?

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?

The benefits of a Document Management System to a product management process

  • Having some kind of formal, digital repository for requirements documentation that properly supports approval processes, while helping to verify deliverables against developed functionality is obviously going to be useful in streamlining any kind of PM’s workload.
  • A document management system with phase gating tools can let the PM set up a standard set of templates. defining the requirements for each phase of a product’s development. It can help them quickly automate the collection, collation and approval of documents within each phase of that work.
  • A good DMS can help a PM gather requirements for a product from different users and stakeholders (in different formats) and ensure they are scrutinised and approved by the right combination of people before the next phase of work is begun.
  • Its function as a central repository of the latest iteration of documents accessed by everyone involved in a project, can end the siloing that often leads to unprofitable dead ends or the amplification of quality errors.
  • At the end of the process it can ensure that a product release is efficient and automated - while making it easier to demonstrate the adherence to regulatory requirements in future audits or certification processes.
  • Post launch, as an initial product grows and the Product Management role switches to a cycle of continuous improvement - the PM can use a DMS to store and collate the feedback emerging from the marketplace, helping to define the requirements of the next version of the product.

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.

New call-to-action

Tags: Product Management

Joe Byrne

Written by Joe Byrne

Joe Byrne is the CEO of Cognidox. With a career spanning medical device start-ups and fortune 500 companies, Joe has over 25 years of experience in the medical device and high-tech product development industries. With extensive experience in scaling businesses, process improvement, quality, medical devices and product development, Joe is a regular contributor to the Cognidox DMS Insights blog where he shares expertise on scaling and streamlining the entire product development cycle, empowering enterprises to achieve governance, compliance, and rigour.

Related Posts

The Pros and Cons of Phase Gate Processes in New Product Development

Will a phase gate process hold back or enhance your new product development? What are the pros and ...

Evolving Quality Management: From Ad Hoc to Chaordic

How can you help your business evolve its mindset to achieve the most instinctive, frictionless and ...

Maximising Customer Value Through Lean Documentation

In a Lean approach to product development, customer value is defined as ‘everything the customer is ...