Archive for May, 2009

Chief Product Officer – Does your Organization have one?

May 26, 2009

Over the last year, while working with many of the consumer oriented businesses – I came across various scenarios where I had to compare the role of Chief Product Officer (CPO)  in comparison with the role of Chief Technology Officer (CTO). While industries are well familiar with a typical CTO role and what he/she is supposed to do, the role (and of course the need) of CPO still seems to be confusing to many. Do organization need both? Is one the replacement for other? And so on.

I tried making a Google search for the job description of CPO; however could not find one. However, I did come across several search results associated with the announcements of CPO in several organization. This makes me believe that this role is still not part of main stream. Also, an interesting observation you would see when you make this search – seems like most of the industries in end-consumer interfacing/used products are the ones who are making investment in this particular role.

So what is a CPO? PTC in one of their press release has made an attempt to describe this role. One of the analogy they have used is with the role of CFO – the way CFO is to Finance in the organization, CPO is to the product. Traditionally organizations have had fragmented responsibilities in terms of product ownership within the organizations. Product Management/Product Marketing looks at the product more from the strategy and product vision perspective; CTO looks at the same product more from design and development perspective; while VP Engineering is more responsible from an execution or product development angle. Almost 80-85% of the organizations with whom I have interfaced have typically been organized in this fashion. However, I have started seeing that many organizations have started having second thoughts on the dispersion of these responsibilities. Hence the role of CPO – someone who looks at product from an end-to-end perspective; someone who can act as a visionary and at the same time be realistic in terms of execution also; seems to be getting into prominence.

IMO, there are also some other factors which is possibly forcing organizations to think from a CPO perspective.

  • For many products, especially the ones in end-Consumer oriented, technology has now started becoming a second fiddle. By technology becoming second fiddle is not to say that technology is not important. I mean that in such applications it is not the technology which drives the user pattern, but it is the user behavior which tends to drive the technology and engineering. In such applications, the head of the product needs to be more nearer to the customer rather than just getting driven by technology & engineering.
  • More and more products are also becoming hybrid in nature i.e. products are getting built-up because of partnerships between multiple relationships. In products such as these, the need is to have someone with his/her responsibility spanning across vision and strategy, design and development, product marketing and management, and partnership management.
  • On the similar lines as above point, as Engineering and Product Development is becoming more and more commodit’ized – many ISVs today are becoming more and more dependent on their partners in helping them out on this rather than growing an in-house expertise on technology front. So from an in-house expertise perspective, organizations have started looking the role of CPO with more interest.

I also think that by investing in a role of CPO, organizations have started becoming cognizant of the fact that they need to start becoming more inclusive in their product evolution and development side – both internally and externally.

I would love to hear your thoughts – especially if you are/have played the role of CPO in your life. If you also have interacted any of the CPO out there, would love to hear your thoughts too.

Assembly Line Software Product Development

May 24, 2009

Compared to many of its engineering counter-parts like Manufacturing or Civil/Construction Engineering, Software Engineering, IMHO, probably still has not come to the level where one can see the maturity of standardization across. There are lots of arguments for this and many of them quite valid. Many consider that in Manufacturing (and similar engineering fields), it is all about creating the same thing again and again. Whereas Software is about creating something unique every time. Also, purists do differentiate between Development and Production. Few authors have said that Development is like creating a recipe, whereas Production is like following that recipe. So the variability in both Development and Production should be expected.

I am not going to disagree much with many of the arguments listed above. With more than 20 products I have been actively involved in my career, I know that each one of them had its unique DNA. Each had a big element of variability and trial-and-error model of software development. So I will agree that the expectation of standardization across them would have been far-fetched. However, my talking point in this post is that while at an Application or Product level – things can be difficult to standardize, however at a software delivery level things can certainly be standardized. For me in this post, software delivery signifies what Assembly Line signifies in a Manufacturing scenario – an arrangement of workers, fixtures, processes, and equipment in which the product being assembled passes consecutively from operation to operation until completed.

As part of Version 1.0 program, my team and me took many of the concepts of the manufacturing assembly line at an abstract level and configured them to apply that in our Software Delivery to a significant success. While we were building multiple products each with a complete different and distinct DNAs – we were also keen in making sure that these products go through certain arrangements which were common across all the products. (The possibility of developing multiple products in a Services organization certainly gave us this flexibility to experiment with such concepts; however I think many of these concepts can even be applied in product organizations where multiple product lines/releases do take place)

Here are some of the concepts which we believe resemble the practices of assembly-line software engineering –

  • Standardized Process for a Release – We felt that regardless of the type of product under development – we could standardize the process of how we go ahead in terms of making a product release across all the products. Here are some of the concepts which tried religiously following all across –
    • Use of Iterative way of Product Development Methodology. We even went to the extent of standardizing each of the iteration length to one month across all products.
    • Atleast one dedicated Design iteration would always prelude the Engineering Iterations.
    • Each iteration had fixed set of activities associated with design, development, and tests
    • Typical Releases across all the products were equivalent to 3-4 iterations.
  • Standardized Milestones across the Release – Every product went through similar milestones – Requirements Prioritization and Iteration Plan Development; Retrospection; Deployments, etc.
  • Standardized Product Engineering Fixtures and Tools – While the core product development platform varied from product to product, we made sure that the core underlying engineering platform which facilitated product engineering processes like Requirements Management, Project Management, Continuous Integration, etc.  were as similar as it could get.
  • Standardized Team Structures and Roles – While team size varied based the product complexity – we made sure that the team was organized into two groups – the functional group and the engineering group. Each group had some roles (such as Product Manager, Architects, Program Manager, Engineering Leads, etc.) which were common across all the products. The roles were well-defined so that each individual knew what was expected from them at each stage of the product life cycle.
  • Standardized Measurements and Continuous Improvement Mechanisms –  Each of the products across their life cycle were getting measured by common metrics on the dimensions of quality, schedule, and customer delight. We also made sure that the process across all the products had Continuous Improvement loops built in through methods like Retrospection, etc.

I think Software Engineering with the knowledge of millions of software products delivered to the market across decades can be standardized to significant extent similar to its other counter parts. Once again, I am not saying that recipes can be standardized. However, my argument here is that the process of creating that recipe and delivering that to its end users can certainly be standardized to a great extent.

Thoughts and comments are most welcome.