Recently I was engaged in a very long discussion about requirements and specifications. I was trying to guide the discussion towards user stories and business value. It was going nowhere.
We can argue the finer semantic points of Agile versus various Waterfall methodologies and how they basically organize work in ways that human beings can execute tasks. It’s really about reaching specific, shared goals, and the fact that you are having the argument at all means that reaching those goals is probably at some level of risk.
But I would like to propose something simple: let's compare the two words, project versus product.
Project: An individual or collaborative enterprise that is carefully planned to achieve a particular aim.
Product: An article or substance that is manufactured or refined for sale.
(first Google results).
At first glance, the definition of a project seems pretty serious. It's a solemnly planned effort. The definition of a product makes me think of something canned and put on a shelf. Think peas or sardines. But let’s dig deeper.
I want to sell something. That something has a monetary value. There is a clear way of indicating whether I met my goal or not, and it is right in the definition. My something has to compete to be successful. Finally, it is directly related to the bottom line of my business. If it doesn’t move off the shelf, I am in trouble.
A project is a more abstract concept, with a “particular aim.” I do not know what the aim is by the very definition. Maybe that is what all the careful planning is about. Which reminds me of something someone wonderful once said about what happens when plans are being made.
To be fair, projects themselves can be planning masterpieces of tasks, milestones, and critical path. Projects are essentially sold based on the credibility of their organization and precision in estimates. In that sense, the project is the product, and the best case is that everyone is happy because there are tons of things to measure and feel productive about.
But what about the particular aim?
When I think projects, I think about big things, like bridges, skyscrapers, or pyramids. I like pyramids the best. What a feat of engineering! It is hard to dispute the success of a project when the result is one of the wonders of the world. It is impossible to conceive of the planning and raw human effort over years to achieve such a lofty objective. They really made their deities proud!
Sure, a lot of lives were lost in the effort. And despite their awesome appearance, they really did not impact the lives of those who ordered them to be built. They pretty much sit there, being awesome. It would be interesting to do a cost comparison of time and materials (including all those treasures inside them and their current worth) with the tourist revenue that visiting the pyramids has generated to get some kind of ROI. I will leave that for historians. Were the pyramids a game changer? Did they improve daily life?
I would argue: no.
When I think of game changers, I think of products. You may be thinking of something that hit the market in 2007 and had more computing power than NASA had to put people on the moon. Not me.
I am thinking about the wheel.
In the same long discussion over requirements and specifications, there was a lot of talk about what is “in the spec.” This kind of project may be very familiar to you: an update to an existing enterprise application, driven by IT, funded by business stakeholders. The vision? Update the technology to something more “modern.” The roadmap? A set of specifications indicating how the application should behave, largely born from an existing legacy application and business processes.
In other words: we put this in front of the user, and we tell the user what to do. I want to emphasize this, perhaps more than debate the delivery of incremental value versus a milestone-driven approach.
Customers tell us what they want to do. They rate our apps and give direct feedback. They are more or less productive with our apps, in work and in daily life. If I have a job to do and you give me a lousy tool, I will not be happy. However, if given the choice, I can probably tell you a lot about the tool I need to do my job. That tool is a product, not the “aim” of a project.
This is what I mean by “product thinking.” I argue that there is no reason why we should not start thinking more about products and less about projects.
The next time you are having a discussion like the one that inspired these thoughts, remember how awesome the pyramids are. Then think about the last time you actually used one to do something.