It is a little disturbing to still come across the confusion about the roles of a product manager and project manager being perpetuated in the software domain. This is even harder to understand with the seeming maturity in our understanding of both the waterfall and agile techniques. Perhaps it is marketing hyperbole, a need to desperately differentiate yourself or your work from the competition. Perhaps it is a more a lack of understanding of when and in what situations the different roles will be advantageous in execution. If the reason for the confusion is the later then the issue being faced is far more dangerous.
If you are involved in developing a software product it is highly unlikely that you have a clear view of how you will get to the finishing line, assuming you can see the finishing line at this stage. There will be many unknown hurdles, and it is to handle the incomplete knowledge of these hurdles that agile techniques were invented. This lack of full knowledge also introduces a very high number of changes during execution that the old waterfall method could not, and in fact was not meant to handle. It is precisely because of these unknown factors that as an outsourcing service provider never executes product development as a time-boxed exercise, unless of course the intention is to fail.
What agile techniques allow you to do is to learn by speeding-up the feedback loop via shorter iterations. This learning is important to produce continuous develop-test-integrate-deploy cycle. The effort is exploratory in nature, until after one or a few iterations one begins to feel sure of the choices made. Venturing into the unknown is a bit like a rock climber; never move a limb until the other three are firm in their grip. Of course you occasionally have to take that leap of faith.
A product manager offers the right skill set to manage the successful development and launch of the product; a typical project manager will simply not suffice. Areas in which skill and knowledge would be wanting for the product manager are, domain, technical, design, communications, process, and marketing. Of course, you will never find a product manager with expertise in all of these concerns.
- A lack of domain knowledge would render the whole product development exercise null and void. How much of domain knowledge would be sufficient? If the domain knowledge is too little to none then the product will not get off the drawing board.
- It is not enough to be comfortable with technical and design concepts, but should be adept and seeing new metaphors in the technical solution for the domain. He should have spent some amount of time in the technical and design trenches. The architect and designers will provide support, but the buck stops with him.
- Communication is of paramount importance; the team will look to the product manager for confirmation of the correctness of existing and new approaches or ideas. The scrum master plays a crucial role in identifying and helping to smooth out problems in the process.
- All these issues are made more difficult if the product development is outsourced to a service provider. Add some more points to the difficulty if the team is remotely located.
As mentioned above, the other type of project is a time-boxed development. Although, an outsourcing service provider will have an SLA agreement with all clients, in this type of project it is imperative to have an SLA. This type of project is pure execution, and this means you apply best industry practices. This is also the reason why you need a project manager and not a product manager. This is not to minimise a project manager function, it is more to put its context in perspective when developing software.
This type of project, if executed correctly, presents only delivery issues. There is no learning involved in the execution of these types of projects. If the need to learn is slowing the project, then either you have constituted the wrong team or the information for a successful delivery within the time constraints is just not provided. There is exploration of the solution, it merely requires an exploitation of the talent you already posses to execute the project.
Often times one comes across claims of agile execution being used for these project types. This is a total misinterpretation of agile, simply because one has implemented a periodic progress review with the stakeholder, the execution does not become agile. And, simply because you have a five minute stand-up meeting with the team does not mean you have implemented agile. These are simple monitoring techniques, no amount of marketing speak will make them otherwise. These act as process moderators providing transparency to your stakeholder, and improve your relationship with your stakeholder.
- One is not looking for domain, technical, or design expertise; one is looking for a good monitor. Someone who captures the activity of execution and highlights any critical issues.
- Never execute a time-boxed project, if all of the information for it is not available at the beginning. There will never be ample time to manage changes during execution. Never execute a time-boxed project, without an SLA, unless you care little for your development team.
If you chose a project manager for the product manager role then for all the reasons mentioned above, then it would be like putting a square peg in a round hole, the project will fail. If you don’t understand or accept the reasons for the failure, you will be condemned to repeat the failure.