Project to product
A journey into a new world of software development
With the current agility needs triggered through business, the whole software development must be re-looked. The project to product is a new concept to fulfill the agile needs of the current industry. This blog provides a bird’s eye view into this concept:
The focus of traditional projects has always been on delivery features and is confined to the following constraints:
- Delivery of features
- Bounded context teams
- Compartmentalized skills
- Success measurement on time and budget
The new model, “Product thinking,” is more toward ‘delivering for the future. Product thinking, unlike projects, has the following critical KPI and attributes:
- Delivery of outcomes — Delivery success is measured on business outcomes rather than purely on the success of the IT project. For example, suppose the goal is to increase the lead to conversion ratio by 5%. In that case, the success is achieved only if the business reaches this 5% rather than successfully implementing world-class lead management or CRM system.
- Success measurement on business impact, NPS, etc. — This is a related KPI to the above. The outcome of what the project achieved gets measured against the bottom line and top-line revenue, which is part of the net promoter score of most institutions.
- Self empowered teams — Self-governed and autonomic teams rather than hierarchical, fragmented decision-making teams. The units are empowered to make decisions.
- T-Skill across areas — The squads must be conversant with primary and secondary skills, the secondary skill in most cases being domain knowledge.
A radical 360-degree change is required
this change cannot be achieved as a single big-bang approach in a short period. This needs meticulous planning and progressive change to achieve the same. The key areas which need to change are the following:
- Role definition — The existing traditional roles will not work in this new model. A new role definition with a new rulebook is required (Product owner, Business outcome owner, etc.)
- Culture — The organization needs a severe cultural change from a hierarchical to a flat, empowered squads
- Taxonomy — As the roles and responsibilities are re-defined, it calls for a definition of a common taxonomy or business vocabulary to avoid confusion among different teams of the organization (business and technical teams)
- Business/technology unification — The demarkation between business and technology needs to be thinned out over a period of time as technology teams do not deliver technical requirements; instead, they have business outcomes.
- Sphere of influence — The sphere of influence of the technology teams needs to expand beyond its boundaries into the business domain as well. This is required to translate business outcome/impact seamlessly into technical solutions, which can be measured and improvised continually.
- Talent — the existing talent model needs to be re-looked
- Leadership — Next to the natural requirement is the buy-in and sponsorship from management for squad empowerment and de-centralized operation etc.
