A Rose By Any Other Name… Product Manager or Business Analyst ….?

So does title really matter? I find myself asking this question more and more lately as I come across people in technology organisations with titles and roles that, on the face of it, look similar but in reality are quite different.

Although I don’t think there is too much merit in getting hung up on titles, I do think it is important that anyone performing a specific role knows what they are supposed to be doing and clearly understands their responsibilities. Difficulties arise when you have a title that can be applied to a very broad discipline.

For example, I sometimes come across people in established technology companies with the title Business Analyst – they sit somewhere between engineering and marketing but their role descriptions can be quite vague. This really got me thinking about whether title really matters and if it does then what are the key differences between the roles of Product Manager and Business Analyst?

For many companies they only begin to adopt a product management discipline at a certain stage in their evolution – often they apply many of the principles of product management without formally recognising that they are doing it and often they don’t recruit a specific resource to manage the function – someone just evolves into the role. In some cases however, it may seem like a natural next step to hire someone with business analysis experience to manage the process.

The role of Product Management covers a breadth of functional activities in the organisation, encompassing product strategy, sales support, commercial ROI, pricing & licensing, support for release management, go-to-market strategy and so on. However, you may see titles like Product Manager, Project Manager, Programme Manager, Product Marketer and Business Analyst being applied to those who are carrying out these functional activities. The roles and responsibilities for each of these titles will often vary from company to company.

In reality I don’t think it is the title that matters so much as the function or role that we perform and the responsibilities associated with that role. It is important for all of us to understand the requirements of the job that we undertake – otherwise the title is meaningless. It is not enough to assume that if we have been given the title of Product Manager or Business Analyst that there is a clear definition of what this means for the organisation for whom we work. Having been a practitioner of product management in a large organisation myself and now helping organisations of various sizes apply the discipline, I know that the responsibilities of the Product Manager will vary depending on the stage of growth of the company.

So what if we take the role of Product Manager and Business Analyst as an example – is their a difference?

The International Institute of Business Analysis defines business analysis as:

…the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions to enable the organization to achieve its goals.

They go on to say …

Business analysis involves analyzing the business and understanding:

  • Why the organization exists
  • How an organization works
  • What are its goals and objectives
  • How it accomplishes those objectives
  • How it needs to change to better accomplish objectives or to meet new challenges

So if we were to substitute the word “organisation” above for “customer” or “market” then perhaps in reality there is not much difference between a Product Manager and a Business Analyst? – but in my view there are key differences:

  • Product Managers focus on understanding an external customer or market in great detail. They analyse the jobs the customer does, what problems or needs they have and what their goals and objectives are? Their aim is to find many customers with the same problems or needs – they seek out and define a market in which to position a product or solution. In this way they can develop a scalable business model.
  • Business Analysts are focussed more on the business needs of a specific organisation – typically the one that they work for or are contracted to. Their focus is more internal than external and they seek to find processes or technology solutions that will meet the business objectives of that individual organisation.

The IIBA identify many job titles for business analysis practitioners including business analyst, business systems analyst, systems analyst, requirements engineer, process analyst, product manager, product owner, enterprise analyst, business architect, management consultant, business intelligence analyst, data scientist, and more.

So, it may help to view the Product Manager and Business Analyst as practitioners of business analysis who adopt similar tactics in doing their jobs (stakeholder interviews, requirements capture and specification, user stories, etc.). Both are effectively conduits between the stakeholders from whom requirements are captured and the teams who will deliver on those requirements. Although they may adopt similar practices, at the end of the day they perform different roles – one more focused on “internal” organisational process and one on “external” customer or market needs.

Having said all of this, each of you may have your own view as to what a Product Manager or Business Analyst does. In reality, as long as the people who are performing the function know what they are supposed to be doing and are delivering against core objectives for the business then titles shouldn’t really matter.

Perhaps this is where the problem lies. In my consultative experience, I am finding that confusion around titles leads to confusion around roles and responsibilities.

Whether you are performing the role of Product Manager, Business Analyst or any other role for that matter, make sure that you get the right help in defining the role for your organisation and articulate clearly what the title means in your business. Don’t assume that everyone working in the organisation has the same view – you need to clarify.

After all, if unclear product requirements lead to poor products then … unclear job specifications will surely lead to poor employees.

Top 5 Approaches for Product Managers to Manage Up and Across

Org StructureOne of the more difficult challenges for any Product Manager is “managing up” or “managing across” the organization. The ability to demonstrate the soft skills required to effectively communicate and work with multiple people in the organization is often an underestimted part of the product manager’s role. This is not about becoming the bosses best friend, it is about stepping through the sometimes subtle political minefield that exists in most organizations.

Few of us receive specific training on what is a very important part of what we do. We don’t often discuss the negative impact of this aspect of our role  with others for fear of showing weakness and the training to deal with political interactions is often “on the job”, with many of us bearing the battle scars.

So what are my top 5 approaches for managing up and across (although like all of you I’m still learning!)

Build a relationship of trust with your key stakeholders

Difficulties in establishing a strong relationship with other stakeholders can stem from a lack of trust and a lack of understanding of the other person’s role. People can sometimes have a tendency to retreat to their trenches and adopt a stance based primarily on mistrust.

Making an effort to understand the value that each group in the organization brings is crucial. We all think we are brilliant and are clearly adding the most value but in reality we are all part of a bigger team. All stakeholders have the potential to add value – no man is an island, you need other people as much as they need you. In your communication with others show how you can support them in their role and how they can support you. Great companies are built with great people who develop strong relationships.

Understand your counterpart’s objectives and their management style

Conflict can often occur when you don’t understand or care about your peer’s objectives. Although we may be working to different team KPIs at the end of the day there must be some common ground – do we not all aspire to create successful companies?

Rather than going head-to-head with someone over a position they have taken, try and understand their motives and objectives. If you are new to the role, try and speak to others in the organization to understand the different “management styles” that exist in the organization. Put yourself in the other person’s shoes first – it can help to avoid conflict if you know what motivates the other person and what they are trying to achieve.

Take advice from others – work with a mentor

Product management is a multi-faceted role – it requires good communication, a strong focus on commercial aspects of business development, an ability to multi-task, the capacity to lead and above all the capability to deliver order from chaos. Often the product manager is a solitary figure with no direct reports but they communicate with and require support from many people in the organization.

I found huge benefits in working with a mentor in my early days of product management and today I find it hugely satisfying to mentor product managers in their role.  Product Management can be a lonely place but it is an immensely rewarding role if approached in the right way. Take advice from as many other people as you can, especially those who have faced similar challenges to you. If you have a product manager in your team, ensure they are receiving the right supports from inside and outside the organization.

We are all on a journey of continuous learning – reach out to others who have made mistakes, learned from those mistakes and who can guide you in your approach.

Adopt processes that support better communication and interactions

Misunderstandings are more likely to occur when there is no formal process in place to guide how people work together. In the absence of a process for communication things can fall between the cracks and one side can blame the other.

Using something like the RACI model to understand who is responsible, accountable, consulted or informed for key projects can be hugely beneficial and can support positive cross-team interactions.

Keeping lines of communication open outside of your own group and establishing forums of communication can be hugely beneficial.

Understand your leadership team’s strategic objectives

It is important for product management to have a “voice” at the leadership table – they support alignment, guide decision-making and ensure everyone is moving in the same direction. As much as possible they try to reflect the CEO’s corporate strategy in their product strategy. Sometimes the leadership team may disagree with or do things that undermine the product manager’s strategy. Dealing with this situation can be a political minefield.

Managing up is such an important part of what we do and sometimes our passion for “doing the right thing” can override our ability to recognize that sometimes there are people more senior than us, who (for the best of reasons) may not agree with our vision. Product Management must tread a fine line between giving good counsel and dictating strategy. We have to ensure that we can see the bigger picture and that we recognize that there are often many contributory factors to good decision-making. As long as we enable our leadership teams to make informed decisions, with the right data, then we are doing our job. It’s important to realize though that we may not always agree with every decision that is made.

Although product managers may feel like they have no authority they do have the ability to lead and guide good decision-making and that is where they can add true value. Remember, don’t bring problems to the leadership team without some well thought out potential solutions.