In product development, projects are vehicles, not end-goals

Note: This post is heavily tilted towards software product development (one product, many customers), not custom software development (one time-bound project, one customer).

As someone involved in software product development, I try to use the word project as little as possible. The issue isn’t using projects as time-bound containers for investments. Or to rally an ad-hoc team for a temporary effort. That seems pretty reasonable to me. Rather, it is what we miss when we only look at projects and/or define our projects too narrowly. In my role as a product manager, I find that by saying project less often — even when my teammates say it frequently — I keep my eyes on the prize.

Take the example of a project that adds complexity to a product. The complexity outlives the project, must be maintained, and may eventually require refactoring or a rewrite to enable new capabilities (or accommodate unexpected growth). Sure, that future work can be encapsulated under a new project, but you’ve potentially lost some of the context and continuity.

Or consider the team that is focused on the mission of improving a specific metric (e.g. retention, adoption, revenue, etc.) Leadership agrees to fund the mission, provided the team can continue to generate impact. Is the project the whole mission, or should each of their efforts be accounted for (and managed)

individually. Are you still “finishing projects” in this case?

Finally, consider the all-too-common experience of working your ass off to finish a project (and being measured on your ability to finish that project within a certain period of time)

, only to later observe that the project delivers no benefits to the business and/or customers. It “works as expected”, but it just wasn’t the right thing to build.

Our dominant view of projects has been heavily, heavily influenced by custom software contractors. That model works (basically)

like this:

• Customer asks for a specific set of capabilities (X,Y,Z)
• Customer agrees to pay $N if those capabilities become possible
• Customer cares about how long and how much
• Contractor delivers something that does X,Y, and Z and gets paid
• Contractor makes cash money But what if that is not your business model?

A company delivering a SaaS product may spend the next decade improving on how they deliver specific capabilities. The stack will not remain the same (if it does, you are prematurely optimizing). Today’s MVP will inspire countless iterations, and today’s “great UI” may one day be controlled by Alexa. Simply put, we don’t know everything, and our world is changing (and that is what leads to opportunities).

Of course, in this model you can view your engineers and designers as an internal consulting firm. Hey InternalDesignCrop, make X,Y, and Z possible, we’ll resource you with $N, tell us how long, deliver it, and we’ll “pay you”. But this is plagued by the exact same things that plague companies buying custom software when they get around to realizing benefits (see benefits realization management, it’s a thing). They may get exactly what they asked for … but it wasn’t the right thing. Plus, it kind of sucks when your engineers and designers are talented problem solvers (not feature fabricators).

For the custom software developer this isn’t a problem. Cash money is in the bank account. Customer asked for it … we built it. You wanted this ugly looking office building without windows, and we built that exact building on time and on budget. But for the product company, it is a major problem.

We benefit only when our work delivers benefits. We have all the challenges and pitfalls of “normal” projects (hats off to custom software developers…it is hard), coupled with the challenges and pitfalls of realizing the longterm benefits:

1. High initiation costs
2. Premature convergence on project scope
3. Premature convergence on solution
4. Failing to capitalize on new learning
5. Sunk-cost bias. Failure/risk adverse
6. Institutionalizing big-batches and late learning (e.g. waterfall)
7. Incentives: achieving “done” vs. driving desired benefits
8. Prioritizing across multiple projects
9. Inadequately accounting for maintenance costs, need to iterate/expand This is WHY we use incremental and outcome-drive approaches, why we dedicate teams to solving problems, and why we work in small batches. To beat these things! But even if we beat these things…we still have to consider the whole product.

So basically … projects aren’t the problem. They are a reasonably human concept (a container of work, something to shoot for, time-bound, an undertaking). The danger is slipping into viewing projects as a first-class citizen of software product development. In product companies, projects are vehicles, not the end-goal. You don’t get credit for adding a feature. You get credit for earning more revenue, retaining revenue, reducing costs, or preventing costs from increasing. So when you ask what someone is working on and they say “finishing project [xxxxxxx]”… make sure to ask “why, where are the benefits, did it work?”