“I don’t understand products vs. projects. What’s the difference?”
When I share some of my stories about working with product development teams, some people look at me as if I’m describing the impossible. They seem confused when I tell them about agile teams that didn’t have to provide story point estimates to management or normalize points across teams. What I’m talking about is so far outside of their experience, they can’t conceive of how it could work. One of the most challenging things for me to explain to people who haven’t experienced both is the difference between project- and product-based organizations.
In a previous article, I wrote about a company with a legacy of building project plans from requirements and estimates. We used feature budgets to avoid problems with that planning style. When I left that company, I was surprised my new one didn’t ask teams for detailed estimates to make project-based funding decisions. What they did instead opened up far more opportunities for teams to operate with agility.
Products as an Estimation Alternative
When I arrived, I discovered a key difference from my prior organization: product-based funding. There was no Project Planning Group to approve and monitor project plans. The organization didn’t fund projects. They made high-level decisions about much to invest in a given product. Because the primary cost for product development was labor, this effectively meant deciding how many teams to have at any given time. Instead of teams forming and disbanding as projects started and finished, teams were relatively stable over time. When investing more in a given area of a product made sense, they would spin up new teams. They made funding decisions annually, with some adjustments during the year. Notably, they didn’t base these decisions on detailed estimates of work at the team level.
Investment decisions were made at the highest level of the organizational hierarchy. The job of the next level down in the org chart was to make good decisions about how to spend that investment. In effect, the C-suite said to Product Development, “Based on what you’ve told us about your work, the state of our finances, and the direction we want to go, this is how much we’re going to spend on each product.” Product Development responded, “Ok, based on that direction and budget, here are the problems we will solve with each product.”
At the time, I didn’t appreciate how radically different this product-based funding approach was – and how few people outside tech companies experienced it. Obviously, I’m simplifying the actual budgeting process. But aside from the timing, it wasn’t much different from what we had been trying with feature budgets. This organization used “product budgets” in much the same way, on a larger scale. It also used a version of an estimation alternative called Strategic Choice Chartering. The key was decoupling the high-level funding decision from the detailed work specification and estimation.
Products vs. Projects is a Funding Decision
Products and projects are not incompatible. They can co-exist. In fact, the answer to the question “products vs. projects?” is often “both.” The real question is which approach an organization uses as its default way to manage work. The primary difference between product- and project-based organizations is their funding model. A project-based organization looks at work as having distinct start and end points, typically with a defined scope derived from requirements analysis. As we often say in our classes, projects are “buckets” of time, money, and high-level scope. They are usually a set of features that make up something valuable together. Many projects are either launches of new products or work to add new features to an existing product. Project–based organizations manage projects as the primary unit of delivery. They steer the organization by choosing which projects to fund and monitoring their progress.
Product-based organizations, on the other hand, make funding decisions around products. This works as I described above. It doesn’t mean that they don’t run projects. They might use projects to coordinate adding new features to a product. Product-based organizations are more likely, however, to be able to take advantage of incremental and iterative delivery approaches. They aren’t committed to time and scope the same way that project-based organizations are.
There are plenty of subtle (and not-so-subtle) differences between project- and project-based organizations. I tend to assess them along the products vs. projects spectrum by their way of funding work. In my experience, project-based organizations tend to say, “We want to know what it will cost before we decide to pay for it.” Product-based organizations tend to say, “We’re planning to spend this much. What can we get for that?” You’ll hear both messages in any organization, but whichever is louder tells you which approach dominates.
Product Funding Encourages Agility But Requires Focus
One lesson from my new company was that product-based funding suits agile approaches. It tends to push decisions about scope and timing to the right levels in the organization. Incremental delivery and iteration also are easier with products. In most organizations, projects are lengthy – usually more than a year long. This encourages large releases and discourages fast feedback. It’s not surprising, then that the “products vs. projects” debate emerges in many discussions about business agility.
My five years at that company also taught me about steering with constraints. A budget is a type of constraint that expresses organizational tolerance for cost. We were making budget decisions – in both time and money – at the product and team levels. We could tell teams, “Here’s the customer problem we want to address. Work on this for X amount of time and deliver as much value as you can.” We trusted – and supported – teams to do just that.
Expressing constraints in this way gives people something to align to. Managers constantly have expectations about how much something “should” cost, whether or not they tell people what they expect. Making budgets clear is an intellectually honest approach. It gives teams the freedom to act while setting boundaries around their decisions. When teams know what customer problem they are trying to solve (and why) as well as the constraints on possible solutions, they make better decisions and build better products.
If working this way has so many advantages, why don’t more companies do it? First, steering with constraints and pushing decisions down – which is what strategic choice chartering requires – is not easy. Managers must develop their people’s abilities to work at the right level of abstraction. They also have to make the organization’s goals and constraints clear. In both situations, they must avoid the temptation to work “a level down” and do this for them. To do this, managers need the technical skills to “level up” their people and provide them with the required information. They also have to overcome their personal challenges around delegating these decisions.
Funding products instead of projects also requires the senior levels of management in organizations to be confident in their choices of where to invest. Project-based funding is – strangely enough – motivated by wanting to spread investment as thinly as possible. Decision-makers want to know exactly what something will cost so that they can pack in as many projects as possible. Rather than strategically choosing what not to do, these organizations act as though they think the magic of spreadsheets will let them do everything. In this environment, estimating and planning projects turns into a Tetris-like exercise. (This is also why going “over budget” is a mortal sin in many project-based organizations.)
Product-based funding, on the other hand, is about focus. Instead of spreading investment to as many things as possible, it focuses spending in a few key areas. (Ironically, setting a small number of product-based limits on investment makes it much less likely that you’ll spend more than you intend.) This type of focus requires confidence in your strategic choices. It also means that people with a knowledge of your strategy need to be more involved in the ongoing work of managing the product rather than just sitting in on monthly project plan reviews. That type of focus is counter-cultural for many organizations.
High-Level Plans Don’t Require Detailed Estimates
I started off part one by claiming that estimates aren’t the only way to make high-level planning decisions. The experiences I had at these two companies – using feature budgets and product-based funding – showed me that decoupling high-level planning and funding from low-level specifications and estimates is both possible and powerful. For most companies, however, it’s not easy. It requires changing the scope of responsibility for teams, which often means up-skilling people. It also means that managers need to operate at the right level, create clarity, and guide with constraints. Making these changes is often beyond what many organizations are willing to commit to, which is why so many “transformations” fail. But those that are able to operate this way are the ones that see the real benefits of agility.
