Project vs. Product (1): The Underlying Conflict

One of the most persistent discussions in the ]project-open[ community is "Project" vs. "Product".

What is a Project?

There are many, many definitions of what projects are and what not. For us, the ]project-open[ guys there is an easy definition: "Get stuff done. Be fast! But make the customer happy!"

What is a Product?

A "product" in contrast (our ]project-open[ application) is something completely different. This has even a kind of esoteric dimension: "Do things right. Right from the beginning!". It is obviously very questionable waht "right" means. But it is clear that the "product" should not include quick & dirty hacks and similar constructs.

Instead, the "product" is something that we will push - earlier or later - to our ~2.500 customers around the world by means of a product update. So "product" is about responsibility, security, extensibility and many more.

Another Definition of "Product"

In a nice conversation with Dennis Riedel of Opus5 we came up with a nice alternative definition of "product": It's the least common code denominator of > 3 customers. Dennis' background is custom web site development for a number of high-profile customers. Their (Opus5) problem is that every customer has very special ideas on how their application should look like. So coding at Opus5 includes a code reuse strategy of "copy-paste-modify" then "productify".

Customer Variability

So here is a core characteristics of a "product": A single code base has to serve a number of customers. Specific customization should be reduced to a minimum. Instead, a "product" is supposed to include a number of parameters so that you adapt the product behavior to a range of customers.

But what happens if a customer doesn't fit into this corset?

Difficult question: Some companies would take on high-profile customers and mess up their product; these companies tend to be successfully in the short term. Other companies would reject such a customer and go for "scalability". These companies tend to be more successful on the long term. But there are always exceptions...

Turning down Customers???

So does that really mean turning down customers? Any sales guy may consider this to be heretic thinking. But yes, in order to "keep the product clean" you need to turn down customers who would pollute the "product" (remember? The beautiful piece of code that is the base of your business...) too much.

Conclusion? You will get trouble if you don't listen to your sales guys, but you will also get into trouble if you don't listen to them at all.

Conflict Lines

A "conflict line" in the context of "Project vs. Product" is the separation between:

• the "product guys", the "guardians of the pure code" and
  
• the "project guys", the people who create happy customers

From the text above we can already assume that none of the two can exist without the other one. However, each customer's project will come with a struggle between the two sides.

The Beauty of Conflict Lines

But here comes the beauty of a conflict line: If both projecties and producties take their job serious, they will - with some moderation by senior management - come up with a nice compromise, satisfy the customer and during that process enhance the product.

How?

Stay tuned, subscribe to this channel and ask for more! There will be more coming on conflict lines and project vs. product.

Frank