Projects vs. Products: An Essential Distinction to Optimize Product Team Productivity
This post highlights the spectrum that spans two of the 4 P’s: projects and products. It addresses organizations operating in the SaaS space looking to maximize delivery value, speed and quality of the output by their product teams. Understanding how to find balance across this spectrum will save time, reduce cost and increase morale for the groups in your organization tasked with working on the business.
The Spectrum Spanning Projects and Products
At one end of the spectrum, projects have a distinct beginning and end, delivering business outcome(s) that typically get defined when they begin and evaluated at the end. A key tenet to evaluating their success is determining how closely the outcome matches what was planned.
At the other end, products have an ongoing life span that delivers customer value continuously. Their initiatives are iterative such that they agilely respond, adjust and reprioritize as customer needs evolve. Products are evaluated continuously on customer feedback throughout their life spans, based on the value experienced by the customer.
Problems when Projects and Products Collide
In modern SaaS organizations, teams that design, develop and deliver tech-based products work in small groups. The most productive teams typically adopt a tight cadence of recurring ceremonies, some of which align to frameworks like Lean Kanban, Scrum and SAFe Scaled Agile. To continually maximize the value they deliver, they are careful about how they balance their time between these recurring meetings and heads-down design/development work. If they lose this delicate balance, they can become unproductive very quickly.
It is a regularity for projects to crop up that are related to SaaS development work, such as major business implementations, customer migrations, or procurement projects that are related to SaaS product features/initiatives being delivered. These projects often require features and capabilities that need to be developed to meet their requirements (for example, to accommodate a data migration, or an internal business reporting need), along with those requested by customer end-users. In some cases, these projects are not formally defined or chartered.
Problems arise when leadership of these projects attempts to comanage, assign, prioritize or break down their own development work. Proper classification at the portfolio level would avoid the act of making development work part of any project charter in a SaaS organization. Product development should instead become a dependency by projects placed upon product teams so that it avoids interrupting their cadence and focus.
Interruptions that Lead to Time/Focus Imbalance
Organizations that do not distinguish, classify and allocate resources formally among project and product efforts detrimentally and inadvertently enable encroachment upon product development work by inviting product dev team roles to typical project rituals such as kick-offs, recurring updates to report progress and one-off planning sessions. When product team members such as product owners, engineers and developers are invited to these rituals, their energy gets consumed by these meetings leaving a diminishing remainder to apply to continuous product innovation.
If product innovation cannot keep pace with SaaS competitors, the eventual result is obsolescence.
D’Mention systems, LLC
If this practice becomes engrained in a SaaS organization’s culture, its inertia persisting over time can slow up product road maps to evolve at a snail’s pace by extending delivery timelines. A SaaS product development team’s capacity is both costly and limited, and so any interruption contributes to this detriment. With that, inviting them needlessly to project meetings increases the hourly cost of each event.
Value Siphoned Away From the Customer to Project Overhead
In addition to being inefficient and costly to include product team members into project rituals, it also forces these team members to spend their time on things that do not deliver product value to their customers.
Siphoning the energy of SaaS product teams away from how their work is ultimately evaluated (by their contributions to the product fulfilling the customer) is a huge morale detractor for people in this line of work (and no doubt contributed to the authoring of the Agile Manifesto).
In addition to the time spent, there are also negative cognitive effects associated with context switching between the overhead (e.g., project planning, RACI assignments, resource/role allocation and reporting progress) of projects and creative product work. These are all reasons to allocate project resources and recognize product team roles accordingly at the portfolio level to ensure that the right roles focus on the right things. Below, we will delve into ways to mitigate these challenges.
How Should Projects Get their Needs Met by Product Teams?
Earlier, we stated that technical and functional product team members must not have their fragile cadence interrupted by project meetings.
If we abide by that covenant, then how is a project to get its needs met by a product in a SaaS organization?
Position the Project as a Customer of the Product
When your SaaS customers request features and capabilities for a product, do you allow them direct influence over your product team’s calendar to discuss requirements, project planning, resource allocation and in-depth inquiries about the how?
No. However, we do prioritize customer face time for Product Managers (and occasionally other members of product teams when it’s appropriate) to observe and capture the what and the why. Product Managers routinely distill these observations into epics and user stories in a way that aligns seamlessly with the agile cadence and focus of their product teams, allowing them to maintain their continuous flow of innovation and productivity.
There is no reason why a project cannot interface with a product in exactly the same way as any other customer by simply communicating the what and the why through a product manager and allowing the product dev team to prioritize and execute accordingly.
Submit Project Dependencies through the Product Team’s Agile Ceremonies
If your organization has multiple product and project teams, then they will potentially have dependencies on one another. For this, your organization’s product domains should each be holding one recurring cross-team ceremony such as a Scrum of Scrums, or a Product Owner Sync.
Like the team-based product development ceremonies, this cross-team event is also a tightly run meeting, meant to remain short and minimize the burden on product owners, product managers and engineering managers. This ritual is an appropriate time and place to include managers from any of the 4 P’s, including project managers in this case so that they can communicate their dependencies in terms of what and why (and abstain if they have none).
Closing
The most important aspect of being able to benefit from the above mitigations is to commit to the portfolio management discipline of classifying projects apart from products in the first place. This enables adoption of the optimal way of working for product teams and their harmonious coexistence with related projects.
To help leaders in your organization distinguish between projects and products, we’ll close with this handy table below to bookmark and reference whenever your organization’s portfolio takes on new projects/product initiatives that need to be classified.
 … |  … |
| Have a distinct beginning and an end. | Have a lengthy dynamic life cycle beginning with inception and ending with sunset. |
| Primarily accountable to business stakeholders. | Primarily accountable to customer end-users. |
| Examples include: system implementations, business enablement/goto-market readiness efforts for new offerings, procurement efforts, team-based market research. | Examples include: SaaS application development, continuous deployment/integration of new SaaS features, internal business application development. |
| Value the business outcome or state of the business upon completion. | Value customer fulfillment and satisfaction after product’s time in service. |
| Yield best outcome from work being planned up front. | Yield best outcome if needs are discovered via customer feedback. |
| Allocated from functional business groups into team roles and responsibilities by RACI. | Organized into cross-functional teams from an organizational matrix. |
| Function best when organized into tasks, requirements, stages and phases. | Function best when organized into user stories, epics, themes and milestones. |
| Value identifying the most complex task path in order to keep the entire project on schedule (critical path method). | Value identifying the simplest most viable unit of customer value that could be delivered next (MVP approach). |
| Value adhering to a plan and schedule baseline. | Value change and adaptation as customer needs are discovered. |
Mike Liskow is a business development consultant, writer, artist, entrepreneur and thought leader in the business development space for tech startups.
D'Mention Systems was established in 2003 and provides business development consulting engagements for tech startups.
