Product management should not replace project management. They are complementary and are both integral to enabling the frequent delivery of business value.
Let’s first look at commonly accepted definitions:
Projects and Project Management: “A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. A project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. … Project Management, then, is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements” (Project Management Institute).
Product Management: Product management “includes the acts of identifying and evolving your organization’s business vision; of identifying and prioritizing potential products/solutions to support that vision; of identifying, prioritizing, and allocating features to products under development; of managing functional dependencies between products; and of marketing those products to their potential customers” (Disciplined Agile).
Initially, it does seem that these points are in contention with each other. TaskTop talks about the importance of moving projects to products. Tasktop CEO Mik Kersten refers to project management as being “the wrong model if you want to become a software innovator.”
We support the assertion that pure projects and project management are not adequate to deliver lasting value. While the definitions and supporting literature take a stronger stance, we assert that transitioning from project thinking to product thinking is not binary. This comes from a misunderstanding of products and projects.
Product management is accountable for the continual delivery of value throughout the product lifecycle, from project to project and in-between. You go through a period or periods of project-like development to build a version of an application or product.
Essentially, product thinking does not make project thinking go away. However, it does alert people to the differing scopes for each and when to best apply them.
Transition to Product Delivery – Transitioning to product delivery in order to continually deliver value does not mean throwing away your project practices.
Build a Product Roadmap – Both projects and products can benefit from a flexible, concise, and effectively communicated roadmap.
Traditional accounting practices are tailor made for waterfall project management. Organizations that have transitioned to the use of standing product teams using Agile and DevOps need to transform their accounting practices as well or they will leave valuable capital expenditure dollars on the table.
IBM is changing the terms of its ubiquitous Passport Advantage agreement to remove entitled discounts on over 5,000 on-premises software products, resulting in an immediate price increase for IBM Software & Support (S&S) across its vast customer landscape.
So you’ve gone Agile. You do daily scrums, retrospectives, and all the “right” Agile ceremonies. But still your organization isn’t quite convinced. It is now critical to balance the drivers and goals of both Agile and traditional thinking in order to achieve organizational success.
Do you feel like your Agile teams are treading water – going through the motions but never going anywhere? It’s a risk, and practices such as daily standups, retrospectives, and demonstrations need to be used wisely or you risk losing discipline to meeting fatigue.
Stakeholders expect the speed and responsiveness of product delivery does not come at the expense of quality. QA tools offer retailers the ability to continuously ensure both business and technical quality standards are upheld, but these tools should not be viewed as a silver bullet.
When trying to implement Agile as a defined process, Scrum turned BAs or other roles into order takers with the title “product owner.” This undermines the entire value proposition of product management.
No matter how good your product roadmap and backlog are, they are only as good as your audience’s ability to understand your vision and priority.
The scrum master is like the conductor of an orchestra, ensuring that every piece fits together at the right time to create something greater than the sum of the parts. You don’t have to know how to play each instrument, but you do have to understand what each part contributes to the overall masterpiece.
Tools are important to product teams, but only when they support solid people and processes.