“Most controversies would soon be ended, if those engaged in them would first accurately define their terms, and then adhere to their definitions.” – Tryon Edwards
As an example, here are some of the immediately identifiable challenges which one can come across when assessing the “state of play” of a technology delivery organization:
- Product managers acting as production managers irrespective of the existence of a dedicated production support team
- Product managers as quasi-business analysts: they write business and/or functional requirements[1] and are focused on short-term implementation and projects, not the product
- Product managers acting as project managers and doing project management tasks: updating PMO systems, project planning, scheduling, riding herd on development and/or QA, etc.
- Product managers not fulfilling the complete role of product management[2]
Projects have firm start and end dates. They are spun up for the purpose of doing a particular activity, whether it be the definition of a business process, or the reorganization of a group, or the delivery of a tangible software product. They are not perpetuated. Their vision is limited, by the scope; their budget, based on requisitioned resources and equipment; the ability to effect change, by the charter. Projects, in and of themselves, do not have a strategy. They are the process by which a tool is created to realize a business benefit or goal, but are ultimately temporary, very much a tangible conceptualization of the “SELECT … INTO” clause in T-SQL. When the query, or in this case, the project, is done, they no longer exist: their purpose has been served.
Products are not like that. They are not like temporary database tables; they’re the permanent tables within a schema. They are designed and created to exist over time and are aligned to essential business functions and activities which are necessary for the operation of the business organization. A product may, and will have, many projects to support it, for example:
- A project to define the business process that product or service will support
- A project to hire and/or reorganize the people resources who will be performing the function
- A project to create a technology implementation to help execute on the function
- A project to enhance the technology implementation
- A project to redesign the business process, and reorganize people resources, if necessary
- A project to create a new technology implementation to support the redesigned business process
- A project to retire the legacy technology implementation
With the above definitions, we’d like to propose an example alignment of the product versus project lifecycles, and then how the functional responsibilities of product management, project management, and business analysis fit within that alignment.
[1] It should be pointed out that there is a clear difference between business requirements and functional specifications, and that gap has created more trouble than its worth. When using business requirements (written from a business user’s standpoint) to do technical development, the end result is more often than not obvious functionality gaps. When business analysts are going directly from scope/vision to functional specifications, the end result may be technically sound, but often has reduced business value. Neither of these are ideal outcomes.
[2] Please see the section “The Consummate Product Manager” for a view of that detailed definition
Please share this with a friend or colleague who you know would benefit from it and follow me on LinkedIn where I post other items similar to this.
Cassandra John 
One comment