I have fallen into the trap. It’s such a pretty trap lined with certainty and speaking to underlying control issues. But it is still a trap.

I have, I admit it, gotten stuck in Project Thinking. This is my confession and promise to be better. This is not me entering into the great “No Estimates” debate. There are no winners there. This is a promise to recognize when I am working on a project and when I am working on a product.

What’s the difference?

A product is:

A living application that is defined by engaged and potential customers, their pains and gains, and the contributions to the business. A product’s development should be driven by a long term vision that is outlined in a roadmap with room for iteration and learning.

A project is:

A timeline driven goal to deliver a feature or set of features usually defined in a statement of work or contract at the beginning of the project. A project is successful if it is completed on time and on budget while satisfying the requirements.

If is too easy, when putting together a roadmap, to fall into project thinking. The business and clients want to know not only what new features a product will have but when they will get to be able to use them. Answering those two questions results in a natural impulse to put together a project plan. An impulse that must be controlled, but not eliminated! These questions need to be answered, but they need to include the context of the overall product vision and user feedback loop.

There are two articles that have contributed greatly the way I think about the way I see my responsibilities as product manager: Kyle Evan’s article Product Thinking vs Project Thinking for the Product Coalition and Sriam Narayan’s Products Over Projects on the excellent Martin Fowler blog. I was exposed to both of these blogs by an excellent software developer on my team to whom I will forever be grateful.

I saw that I was not seeing the product through the project, much like the not seeing the forest for the trees. In the building of the product roadmap, all I can see is the forest. However, in implementing features suddenly all I was seeing was trees. Everything about finishing a feature on time and the overall goals of the product were getting lost. This is Project-itis. This is where good product development teams become feature factories.

How to cure project-itis?

After spending some time reading through these articles and looking at my own ways of talking about our product, I realized the key was to know when we are talking about forests and when we are talking about trees. Because the forest is full of trees.

Yes, I know I am overusing that metaphor.

Maybe a visual will help.

A product is a set of features. The way that a product fits together consistently is two things:

1. A long term product vision that is selective about which features to include.
2. Room for tech debt, architectural improvements, honoring the campsite rule, and dev ops

The second of these is a subject for a different post.

Once I have a set of product features that support the long term product vision, I can prioritize them. Based on building an effective user feedback loop and product vision, I know which features need to be done quickly, which need more feedback, and what research.

When I open up a feature for the team that is the project. That is where good project life cycle management comes including ideation, market validation, solution generation, and release. This is where finding small slices to get feedback from users come in. This is where a project plan and estimates are useful. Focusing in tight on just that feature is a project.

If all we do is focus on the project, however, the product suffers. The trees don’t talk to each other, don’t work together, and there can be no forest.

Okay, so I really like that metaphor. It’s helping me climb out of the trap though, one tree at a time.