Does it really matter? Well yes, I think so, I think that a Product is derived from a number of Projects but there are 2 other reasons why I think its important to distinguish between them.
Firstly, I think that the word Product serves to focus peoples minds on the fact that what is being delivered is expected to return something on its investment.
Secondly, and perhaps more importantly, I think it suggests that the software that is being delivered needs to compete with the offerings on the market not only in the short but the long term too. When pieces of work are in the initial stages of consideration here we take the opportunity on to indicate whether a buy versus build decision could be made. When considering the long term we should be considering any additional phases of work undertaken and whether they continue to improve the product and keep it ahead of its competitors.
It’s this last point that I think James Shore makes very well in his Do We Need Projects? post.
When I started reading books about Agile one of the things that I found difficult to comprehend was how it translated to the enterprise environment. They all spoke about delivering products, never project, the point is subtle but a mindset shift that I think we need to make.
I’ve been very fortunate to work in a number of different areas of our organisation. Recently, I was given an opportunity to work with another department and business unit that deliver one of our biggest B2C sites.
In doing so I spoke on a regular basis with the business sponsor for the site reporting progress but also suggesting how they might deliver the site in the future.
In my conventional role, I work within a division that is focussed at delivering software to the other business units meaning that it is more B2B.
My role has been refocussed recently meaning that unfortunately I will no longer be able to work with people in the way that I have been but I wanted to offer my opinion on what I thought were some concepts that the area in question needed to understand to continue to develop.
I sent the following list to my boss and the director the other day with the intention of using them as points for conversation:
- Product vs. Project
- Breaking the shackles of the brand: Focusing on delivering features rather than the brand
- Amplifying learning = Removing the middle man = Aligning delivery teams with business units and business units with delivery teams
- Reducing Time To Live / Cost To Market / 80:20 rule
- Manufacturing vs. Engineering = Chemistry vs. Biology
- The long tail effect
- The wisdom of crowds / UGC.
A bit of a random list, I must confess, what I have realised in retrospect though is that the majority of the points above actually apply to the B2B area that I work in too.
I think in essence, what these points allude to is that, in my opinion, development teams exist to deliver value and that perhaps, some of the behaviour that I see when at work would suggest that we’ve lost sight of that.
I’ll use the next posts I make to elaborate on the points above, if for no other reason than to clarify things in my mind.