Development of a new product normally starts in a business’s marketing department. For businesses that launch many products, such as those in FMCG or telecommunications, there are specialists called product managers. Depending on the business the role of the product manager, and the team they sit in, varies.
Let’s think of a specific example of a project to develop a product. The product manager works in marketing. Such product managers are accountable for launching new products and for the profitability of the products once they are live. This product manager is the project manager’s customer.
I am going to generalise here, and as with all generalisations what I’m about to say is not always true. One of the challenges I find in working with product managers is that they are good at coming up with interesting ideas, but they are not so good at converting their ideas into stable requirements.
Additionally, I have found many product managers don’t see the role of the project manager as necessary. They feel accountable for the product development. As the accountable person, the last thing they want is a project manager messing around with their project. They see project managers as inflexible people always going on about requirements, risks and change controls. They think of change controls as a way of slowing down projects and stopping essential ongoing creativity. Project managers are bureaucratic administrators who get in the way.
On top of this, some product managers think they can design a better product than an engineer. They don’t need the project manager, and they don’t need the engineer either.
I mention engineers, as they are the other key people involved in developing the new product. Engineers convert the product manager’s requirements into a product design, and from that design build the product. Fortunately, such engineers understand the role of the project manager very well and like the discipline of change control.
Where engineers can be less helpful is in understanding that almost every project is a compromise. Engineers, as professionals, want to build the perfect product: that is the one that best meets the requirements specification and is highly reliable. As a project manager it can be hard work convincing such professionals that at times they have to compromise on their ideals in order to meet project timescales or come within project budgets. But great care is needed in forcing compromises on engineers. No one wants to launch a badly engineered product.
On top of this, the engineers sometimes think they could design a much better product than the product manager, if only he or she would stop with all that marketing nonsense and let the engineers build a really good product.
The engineer, product manager and project manager each think they own the project. The product manager feels ownership because he or she is accountable for the product. The project manager feels ownership, because he or she must get the project delivered. The engineer feels ownership because he or she designs and develops the product.
A common problem in projects is not enough accountability. Sometimes with new product developments the problem is too much! So, what can be done?
Making this work
The starting point to successfully managing new product developments is to appreciate the strengths and weaknesses of each of the parties involved. The little example I gave above does use stereotypes, but they are stereotypes that I find quite frequently. A great new product requires a product manager with imagination and customer insights, an engineer with great skills and technical vision, and a disciplined project manager who can handle the politics of these different parties.
The way to productive working with product managers is to act flexibly, but to make them understand that if they want rapid and reliable delivery they must develop a complete and set of requirements early on in the project. Of course, any change can be catered for: but every change has risk, cost and time implications. The later the changes come the greater the cost and time impact on the project.
Explain this very early in the project – when you first start working with a product manager. It may be obvious to you. It is not always obvious to other people.
One thing to watch out for is the assumptions product managers make. Product managers make many assumptions. Some of these assumptions will be tested with customer trials, but such trials tend to happen late in a product development project. If the assumptions turn out to be wrong the project can be lengthened and budgets increased.
Ensure all assumptions are formally documented, and manage them as risks. Any assumptions that turn out to be wrong will require a change to the project. Make sure this is explicit and that assumptions are not made without the implications being understood.
The best way to work with engineers is to make sure they understand the constraints on the project, but also to listen. Engineers will often moan that if there was a bit more money or time the product could be made better or would be easier to operate or support once live. You have to make sure that constraints are treated as requirements, but don’t ignore the engineers complaints. I have seen products launched to great acclaim, only to bring trouble later to a company when the product turned out to be unreliable, just as the engineers had predicted.
Make accountabilities clear. The truth is that all three parties are accountable, but they are accountable for different things:
- Product manager : right requirements which will achieve business case if delivered
- Engineer: right solution which fulfils the requirements
- Project manager: optimised delivery to time and budget
Experience of working together helps. When marketing specialists have worked with professional project managers for a while they come to understand the benefits of project management. Product managers may like the freedom to change requirements as and when they like. But they also are accountable for product profitability. Profitable products are delivered reliably, within predictable time frames.
The general lesson
All projects have three core roles:
- A requirements owner. Usually the project customer. This person is accountable for defining what the project should deliver.
- A solutions owner. Often a technical specialist, who converts the requirements into a solution.
- A co-ordinator or project manager who brings the different threads together – but who does not own the requirements or the design.
On very small projects the 3 roles may be all performed by 1 person, but they are still distinct roles. On very large projects the roles may each be performed by teams of people. Whichever it is, a project will only succeed if all three roles exist, and if the responsibilities of each role is well understood.
Although it sounds negative, I find the best way to explain the difference is to consider who is to blame if the project fails:
- The requirements owner is to blame if the requirements turn out to be wrong – i.e. the wrong new product is delivered
- The solutions owner is to blame if the end product does not meet the defined requirements – i.e. the product does not work, or does not work in the required way
- The project manager is to blame if the project is late or over budget
(In reality, there is a level of complexity with compromises between requirements, designs, and delivery costs / timeframes / risks, but the basic principle holds).
There is nothing particularly clever here. Some reading this article may even be thinking – how basic. But it is amazing how often these very fundamental 3 roles are not clear in a project team.
People in the software development industry are normally good at ensuring these different roles exist. But I find these roles are not clear in many other projects. The lesson is basic, but think about all the projects you are involved in and ask yourself:
- Are you completely clear who owns the requirements, the design and the delivery?
- Are these three parties really clear about their accountabilities and understand the boundaries of their accountabilities?
- Does each of the parties understand what the other two parties bring and are accountable for?