Product over Projects
– By Guenther Tolkmit, Dreams and Details Ambassador
“Artificial demand constitutes demand for something that, in the absence of exposure to the vehicle of creating demand, would not exist. …
A demand is usually seen as artificial when it increases consumer utility very inefficiently; for example, a physician prescribing unnecessary surgeries would create artificial demand.”
The Enemy of Innovation
Artificial demand has developed into the number #1 enemy of innovation in our companies.
Vendors are guilty of creating artificial demand. To a certain degree, this might be excusable because vendors are supposed to be forerunners by nature. Though, pretty much everybody is guilty of building too complicated stuff. Not justifiable is, however, the growing tendency to overhype functional capabilities to improve their company valuation.
Funnily enough, customers are even more often falling into the trap to create artificial demand. Why is this? Whenever we are producing material goods, we are used to long engineering and usage lifecycles, in particular in the business-to-business world. Hence we are attempting to be as thorough as possible to capture all present and future requirements to overlook nothing essential. The result of this approach is well-known: we always extend the product creation cycles, missing the market in many cases. Unfortunately, creating long demand lists is in our genes of manufacturing companies. This attitude has been applied to our corporate information technology activities, too. It has hardened over the last years because more and more are depending on broad consensus for making things happen. Every stakeholder can ship in their requirements resulting in very long opinion building processes. And subsequently, we have such long implementation times that more and more activities are dying a natural death before coming to fruition.
The culprit of this misery is our current entity of management. Any, relatively large activity is by default a project! Project-thinking is so internalized in us that we never thought about challenging the proposition. The proven alternative to project as a management entity is product!
Tech (software) product is the domain of tech and software vendors. Now since every company is becoming a tech (software) company (see blog-post) learning how to manage products is not only prone but also necessary for the digital age. Managing product rather than projects is key to publishing tech (software) in a high frequency.
The Key Differences between Project and Product
Project, as the word suggests, is about planning. Comprehensive planning. It often results in creating artificial demand. Product, on the other hand, is a deliverable which fulfils a specific customer demand. Iteratively. Guided by the reaction of the customer. Over and over.
There are a good number of articles outlining the details (among others Martin Fowler – Products over Projects and infoq – transform projects to products). Unfortunately, many people are mistaking this management discipline transformation as a matter of the departments who are building the software (for example corporate IT) which is wrong. The conclusion of Dreams and Details’ “Quick Guide“-post is an excellent example to see what it means for your management.
In reality, most agility initiatives are starving to death with the 1st MVP. It is tough to restrict yourself to the minimum, as discussed above because your people are wired differently. Not to speak of establishing a continuity of fast tech (software) iterations.
Fundamentally changing the management approach on how things gets done needs to be led from the top and down. And it needs the right calibre of “product managers” which are very hard to come by.
