Project to Product: Yes, it’s that complicated
Before I get into the meaty stuff, let me clarify this article’s title. Moving from a project-based to a product-based work orientation is complicated, but it can be simplified, well understood, and well done nonetheless. You won’t learn all you need to know here, that’s why there are entire books and certification courses on this stuff, but you will gain a general understanding. And that’s a great place to start!
It’s impossible to talk about moving from project to product without talking about agile ways of working. So, you will encounter a mixing of the topics and language. I encourage you to look up anything I don’t define… and anything I do, for that matter. Reviewing materials like those found at www.scaledagileframework.com will help your understanding greatly.
What is a product?
Let’s start with the question on everyone’s mind. What is a product? Frankly, what a product is depends on the organization contemplating it. However, in general, a product is something that provides value for customers. The existence of a product or group of related products creates an ongoing value stream that must be managed. Value stream work is built into the product management and agile processes, and functions to deliver new value and insights on a regular basis.
In contrast, a project is a temporary, one-time initiative designed to create or improve a product that must be handed off to an owner to manage as-is. In this work orientation, each improvement is handled as a new project, which slows delivery of value. At times, the pace is so slow that the deliverable is no longer relevant at completion. Don’t take this to mean that the idea of projects must be scrapped altogether, though. They have their place in the world (e.g. the construction of buildings), but that place is not in the management of continuous customer value delivery.
The product mindset and work orientation is about continuously delivering value to the customer.
What is the difference between project and product?
There are several key differences between the project and product work orientations. Here are some highlights.
Intake. Projects are taken in via a centralized, and typically unlimited intake system leading to overload and prioritization difficulties. Products are demand-managed at the portfolio and program levels with decentralized intake systems that are aligned to value streams, which help ensure that only necessary, strategically-aligned work gets through, and that work is prioritized or re-prioritized easily and appropriately.
Scope. Projects are comprehensive, full-scale initiatives, which naturally make changes slow, difficult, and costly. Product work is MVP and hypothesis-based, which allows for quick testing, adjustments, delivery, and scaling.
Planning. Projects are planned in a waterfall fashion, and lack flexibility. Product work is planned using an iterative model, allowing for quick adaptation that follows customer feedback and industry shifts.
Visibility. Project communication is filtered through the project lens only. Meaning, progress and success is framed in terms of the project, instead of in terms of the broader up and down-stream impacts, which may shift over the course of a project’s lifecycle. Product work has a direct and transparent communication mechanism – technology-to-business and business-to-technology that is constant and connected at various levels of the organization. Due to the nature of product management, up and down-stream impacts are more easily identified and the information more easily used for making adjustments in strategy.
Funding. Project funding needs are estimated and allocated up front and based on longer-term deliverables with potentially uncertain ROI making it hard to fully understand the value the deliverable provides to the customer and the organization. Product funding is dynamic, controlled with guardrails, and is based on investment in the value stream. This way, it’s easier to understand where the money goes and what impact the investment had on business outcomes, which leads to smarter decision-making.
People. In the project world, the same resources are assigned to multiple projects and teams, reducing productivity. Products have dedicated resources or long-standing, high-performing teams that are focused on building expertise and maximizing productivity.
Delivery Management. Projects are managed via milestones and task completion, which does not provide incremental value to the customer. Products are managed through MVPs and measured through business outcomes. They focus directly on how to provide continuous incremental value to the customer.
What does PPM look like in the product world?
Whether you are starting fresh or undertaking a major transformation, moving to a product work orientation or operating model requires tight portfolio management. Your PPM (program and portfolio management) can be the key to success, or to failure.
PPM for the product-based operating model requires a new set of knowledge, skills, and abilities (KSAs), and a willingness at all levels to rethink how an organization works.
A clearly defined strategy employing the use of OKRs is important. The OKR process requires more frequent strategy planning than the methods of old, and enables and promotes adaptability at the organizational level, which is complimentary to an agile structure. Ultimately, you’re looking for tight alignment and clarity across the organization.
Ownership of strategy realization must also shift. The use of an OKR methodology for strategy planning requires a robust feedback loop mechanism that produces strategic objectives that are created by and for stakeholders at all levels, both internal and external. The responsibility of how to achieve those objectives must reside at the agile team level, where the detailed business and operational expertise sits. Since OKRs are typically set for quarterly achievements, quick learning is enabled, which leads to constant refinement of the strategy and process. Basically, the important things get done, and you keep getting better at getting the things done!
I should note that longer-term strategy planning is still necessary to ensure alignment with the enterprise’s mission and vision. However, even the long-term plans cannot be set in stone. New developments in the industry and business environment must be regularly anticipated and taken into consideration.
How should the customer-centric, product-based operating model be implemented?
Implementation of the product-based operating model is complex, especially if you’re undertaking a transformation in an organization that has firmly-set structures and processes already in place. There are various approaches to implementation, but here are the steps and ordering that appeal most to me.
1. Articulate the change. Why does the organization need to move to a product and agile way of working? Understand the answer well. This will be the foundation from which change management planning is built.
2. Build a coalition. Select and up-skill the people that will be become your change agents, and champion the product mindset and agile methodologies. This group should be made up of HR, executives, agile coaches, and others that will support and drive the transformation. This is also the beginning of changing the culture, because this is where leaders learn how they will have to function differently. In addition, there are four key roles that should be well-understood at this point (and preferably represented in the coalition).
Product Manager – focused on strategy, value stream, customer experience, and feedback loops
Product Owner – focused on the product and business solution development
Scrum Master – focused on the MVP and agile team
Agile Team Member – focused on the iterative work
3. Form a COE. Select coalition members to form a center of excellence (COE) around the transformation. The size of the COE will vary and scale over time. The COE will begin the work of planning and executing the change.
4. Identify value streams and ARTs.
Value streams are made up of chronological activities that begin with a trigger or need and ends with value being delivered to the customer. Products can be used to define value streams. You can also think of the value stream as the operational or development side of the customer journey, and thereby leverage customer journey mapping to help identify value streams. Product thinking and agile methodology is primarily focused on development value streams that include the systems and people that enable the operational value streams.
Agile release trains or ARTs are the teams of agile teams that support the value streams. The number of ARTs needed for a value stream depends on the size and scale of the value stream.
5. Begin implementation. Select the first value stream and ART. A tentative plan and ordering for later value streams and ARTs should also be laid out, but go easy on the details and make it flexible. Later implementations may be influenced by the ones that go before them, so the plan must be adaptable. Implementations require the full support of leadership, defined products, cohesive agile teams, and an opportunity to pursue before launching the ART. This is a big step, and as such, it comes with its own set of pre-launch work that should include:
Naming the ART and building out its defining elements (vision, roles, stakeholders, solution, etc.),
Establishing the launch date and program calendar;
Training release train engineers (RTEs), product and team roles (see key roles above), business roles, etc.; and
Standing up the agile teams.
6. Coach and learn. The COE and change agents have to stand alongside the ART in a coaching capacity helping work through the change, adapt thinking, and get players comfortable in the new way of working. This is where intricacies are realized in iteration planning, backlog management, conducting the various agile ceremonies, and more. Take this precious time to get it right, learn, document, and adjust future implementation plans.
7. Repeat steps 5-7 for all value streams. Keep in mind that as more value streams are launched the importance of tight portfolio management increases!
There is so much that this article doesn’t tell you. It leaves so many gaps and unanswered questions. And, yes, this stuff is complicated. But there’s hope! Fortunately, there are many resources out there to help get you where you need to be, and when it comes to implementation, taking things one step, one chunk at a time will get it done. Remember, the key is to success is to have everyone and everything (people, processes, technology, and information) organized and aligned while doing it.