Project vs. Product

Service companies often find it hard to instill product thinking in teams. People working on software applications believe that they are only on a temporary project - that could range from a few months to a year. When it’s done, they can move on to other projects. The application is seldom treated as a 'product', that needs to live in production for many years after the project is completed.

We’ve worked with a large online travel company for over seven years now. We’ve seen both long and short term projects. In fact, at one time, our team of 100 people were working with a client’s in-house development team of 50 people! This experience taught us many lessons and I’d like to share my experience in this post.

Our application architecture was such that it had 3 web components for different channels and around 20 services (6 of them being major ones). We had 8 features teams across two locations making changes to these web components and services. Each new feature development was termed as a “project”. Usually, a project would span across multiple services and couple of web components. Every team was working on different web components and services in order to meet the requirements. Each team had its own style of design and coding and hence there was no consistency in the code.  It was a nightmare to maintain a codebase with 150 people checking in code simultaneously.

Reality struck when our client decided to reduce the Thoughtworks team size and increase their own capacity. Ordinarily, this would be a routine knowledge transfer phase. But given the size of our codebase, it proved to be quite challenging. An exhaustive knowledge transfer required us to change our own mindsets - we had to stop thinking of teams being part of projects and start thinking of them as being owners of products.

Every service and web component was a product now. We had 5 teams owning these products. Code check-ins in each product repository was restricted only to the owner teams. This brought in lot of confusion at the beginning, because almost every project (feature) needed changes in multiple repositories by multiple teams. This increased the feature rollout time but improved the code quality and consistency.

We identified teams to own services and web components. We transferred knowledge for 6 major services and 2 web components among 4 different teams at the client end. We retained a web component with the Thoughtworks team. This way, we didn’t have to transfer knowledge of everything to everyone - but only transfer targeted knowledge to relevant teams taking ownership. By now, each product had its independent repository and owning team.

Changing our mindset from being project aligned to being product aligned transformed the way we did the knowledge transfer. But apart from this, there were many long term benefits, to name a few:-

1. No dependencies between services: Previously, all the services were in a common repo, which created dependencies for compiling and building code. A single check-in in one of the services would build each and every service. Build failure because of an issue in one service would block everything. Separating out services in their own repos made the compilation and the build process independent
2. Ownership and responsibility:  After the ownership transfer, teams became more responsible towards their respective products. Any defect arising in a product was the responsibility of the owning team. As a result, teams became more watchful and aware of their products
3. Code consistency and Quality: Product quality became the primary focus of all the teams. Products were owned by just one team hence there was code and design consistency across the product.  It became easier to maintain smaller products as opposed to a monolithic codebase
4. Long-term product vision: Teams now were more focused and had a long-term vision. They started building their product backlog and working towards it. Their thought process changed completely. People were now thinking on how to improve their product in terms of modularity, reusability, scalability, etc.

We learnt quite a few things as we moved on. Here are some of our learnings:-

1. Building an early backlog:  When we started as product teams, we did not have backlogs for each product. We did normal feature development but across different product teams as opposed to developing it in one team. But this mindset began to change and we began building backlogs for every product
2. Assigning a product owner:  As we realized that creating a product backlog is important, we also felt the need to have a product owner for each product. Hence we assigned a product owner to each product who worked very closely with the team in creating the backlog and working towards it
3. Treating web channels as customers: Our products consisted of web components and services. Web components were the channels through which end users can interact and buy tickets. It was easy to build the backlog for the web components, but for services we were not as sure. We then realized that as web channels have end users as their customers, web channels should act as a customer for services. Hence we started building services backlog by taking requirements from web channels

Changing our way of thinking had a huge impact on us.  We were now thinking and talking about products that can be maintained easily, which have less or no production defects, technical enhancements in the products, etc.

One very important change we observed was reduction of tech debts. Earlier, a team working on one project would get done with that feature without removing or sometimes building on top of the existing tech debt. But now, teams did not move ahead with feature development without removing the tech debts, and building on new tech debt was out of question. Our teams’ behavior changed from “everyone is responsible but no one is accountable” to “take ownership and be accountable”.