Project or product?— that is the question

The clashing of product and project mindsets over work definition

Michael Le
Aug 8, 2017 · 4 min read
Who and how will you steer the product towards success?

A question I don’t ask enough of clients is, “Are you working on a project or product?” This question matters because without understanding where people are coming from you will clash. The clash happens because of one side sees the work with an end and the other sees the work just as the beginning.

This post is an elaboration of an earlier tweet of mine:

For this post, we will introduce Amy who is the product minded person and we can say Bruce is the project minded person.

Thinking about features

“Are you building the thing right vs are you building the right thing?”

With Bruce’s project mindset the list of features is set. The features are set because of his careful planning and analysis and this results in a clear output to define success.

On the other side we have Amy who is a product minded person who understands that the output is only the start. The output doesn’t define success for her, it is only the start of delivering value to the customer. Success is happens once the outcomes are met.

My struggle with talking about releasing features in iteration with project minded people is that they think that there will only be one release — the release. Teams who work in this way focus too much on the backlog and make sure it is full for the entire duration of time. The focus is on getting the items to done on time and on budget. As a result there is no time to learn and iterate from the customer because the release is at the end. This is a dangerous zone when advocating for agile processes because nothing about this agile.

Thinking about budget

“How much money to build this vs how much money to start this?”

With Bob he has to specify how much money to deliver everything. He will look to past projects for budget data and if he is good he will ask others for their input on the amount of work required. From this data he will pitch his whole concept that the business will get everything 9 months.

Alice will also have to do estimates. However her estimates are for the next 3 months and the rest of the 6 months after are high level. As a result her estimates should be more accurate than Bob’s in the short term and she has the ability to adapt and change as time progresses.

The nature of building software is not linear and things change. Most project companies are used to specifying everything upfront and thus increasing the risk upfront. With a project mindset, the solution to the potential change is to control the change by upfront specifications. This process takes more time and unforeseen changes are inevitable. This is harder in organisations with annual budgeting cycles. It’s hard but it is not impossible. Is it not better to take smaller risks as a business by making smaller bets?

Thinking post launch

“Who will maintain this vs who will grow this?”

For Bob, after the launch of a project, and if it was done on time, budget and scope, there will be a little party for the team working on it and the stakeholders. After the congratulations are over, the stakeholders move on and the team working on the project get reallocated to other projects. The features that were built are now maintained by a “business as usual” or “support” team. Any fixes or modifications will have to go via a change ticket that will be addressed once a team is available again to work on it.

For Alice, there might be a small celebration for the first 100 users but her team have been releasing early and often and there is nothing special about releasing code. Her team is more focused on how customers are using the product and are taking with them and looking at the metrics. They are all still together as one team and they are working on how to improve an experience for their customer. Changes that come in might be prioritised higher than the work they originally have planned in their backlog and that’s alright.

Putting it all together

Trying to change a project based organisation to a product based organisation requires a change in mentality of how a product is managed.

I believe that there should be a strong continuity between the team doing the work on the product and maintaining the product. Maintaining the product is so much more than keeping it up and running but also includes growing it.

Companies care about the time and budget but due to legacy processes try to reduce risk by sticking to the set plan made by experts. Teams in this types of organisation not acknowledging this fact of their environment will hit a barrier to working with a product mindset.

Final thought — how customers solve their problem can change so do you stick to your project plan or do you adapt?

More reading on this topic

Michael Le

Written by

Product designer, speaker, father, design mentor #ux. Based in Sydney. Creator of Navibaby