Product Manager in an agile world

In traditional world, for an idea to translate to a product, it had to go through different phases like conceptualization, solutioning and then development. Market research team would do the research, come up with a concept and hand it over to the product manager. Product manager would then come up with a solution and pass the requirements to project manager. Project manager would then get the development started from the team. In this scenario the vision of the product or the business objective gets diluted like a Chinese Whisper game. There is no single owner in this case. Market research team is responsible for the concept, product management is responsible for the solution and development team owns the development. But no one is responsible for creating a sustainable quality product as a whole. 

How can this problem be solved? There must be one person who owns the product, who is responsible for the product from concept to launch. Now, who that person should be? Who other than Product Manager can take that responsibility? As he is the one who is close to the market and closer to the development team. For successful delivery of any product, Product Manager must closely work with the development team. In agile world, Product Manager is part of the development team and works closely with the scrum master.

What an agile product manager must do: -

1. Be part of the development team: - Product Manger must not work in isolation. He or she should be part of the development team like developers, QAs, etc. Product Manager must work very closely with the scrum master through the iteration or sprint. Product Manger knows the business priority and Scrum Master knows how the team is progressing, they both can help each other in critical decisions. Scrum Master and Product Manger roles complement each other throughout the product life cycle.

2. Participate in sprint meetings: - Product Manager must participate in all the meetings, like iteration planning, daily scrums or stand ups, retrospectives, etc. as he or she is part of the scrum team. In fact he or she should drive some of the meetings like iteration planning. Product Manger's inputs in these meetings are very important. For instance if there is a change in priority from business, product manger is the one who would know it first and this input in daily stand up or iteration planning meeting will help the team to start accommodating such change early on, instead of last minute surprise.

3. Work with market research and other stakeholders: - Being part of the development team doesn't mean that Product Manager should not participate in market research, concept triages and brainstorming sessions. As he or she is closely working with the development team, his inputs about the feasibility and the limitations of accommodating and implementing new ideas are very vital. Knowing these details early in the cycle helps in faster decision making process. 

4. Think like an end user: - Product Manager must always think that the product is developed for himself. What features and functionalities he would want if he has to use the product. Product is of no use if it cannot satisfy end users' needs. Hence, while building a product, Product Manager should always put himself in end users' shoes and take decisions.

What an agile product manager must not do: -

1. Work as a separate entity: - Some Product Mangers work remotely, away from the development team. This creates a huge gap between the team and the Product Manger. Product vision is not translated to the team. The communication cycle for the smallest information becomes very lengthy. When Product Manager works in isolation, he is not aware of how product is evolving and team is unaware of the long term objective of the product. Hence, adaptability and agility of the product becomes very low.

2. Responsibility without authority: - Product Manger should have complete authority on the decisions regarding the product. A pseudo owner without any authority may lead to team burn-outs.  Since Product Manager is responsible for delivering a successful product, he should be authorized to take important decisions about the product. Involvement of other stake holders is important in decision making process but Product Manager should be the one who makes the final decision. 

3. Unsustainable pace: - Don't bite off more than you can chew. Many Product Managers make a mistake of signing up a lot for the sprint and rushing the team through it. It might be possible to achieve this in one sprint but it won't be sustainable. Team would get worn out and slow down which would impact the velocity in long run. Product Manager must ensure that team has enough work that can be delivered without being over worked.

4. Release everything at once: - It is always advisable to test the water by dipping your toes rather than jumping in the pool. Hence, never target to make a big bang release with loads of features and functionality. Start small, release few features, gather user feedback and work upon them. Always test the market by releasing an MVP with few but important features, collect user reactions on the existing and missing features and build the road map based on that. Product evolving from user feedback is much more sustainable than a product released with lots features and functionalities without taking any user input.

Product Vision: - 

Product Manager should envision the product right from start. He should be very clear on what the product is supposed to do and what it is not supposed to do. End goal of the product must be well defined and communicated to everyone. For example, for a loyalty platform the goal of the product should be to simplify points collection and redemption mechanism. Product Manager must have this vision in mind and must bring everyone onboard with this. Sharing the vision with everyone involved is very important, business stakeholders must know what are they marketing about and development team must be aware on what should be the final outcome.  

Product vision must be brief and broad. Product Vision must not include granularity and details. There must be enough room for creativity. Hence, it is important that Product Manager shares a broad and unified vision of the product with everyone involved.

Backlog Grooming: -

Once the MVP is identified, features or requirements outside the MVP goes into Product Backlog. Product Manager is the owner of that backlog and it is his responsibility to keep grooming that backlog along with the development team and other stakeholders. New items must be added to the backlog and existing items must be modified or removed depending on the product evolvement. Product Backlog must be dynamic and must adapt to user feedback, market reaction, technical changes, etc. It is also important to prioritize the backlog regularly. A high priority item in the backlog may become low priority few months after the release and a non existing item may get highest priority. Hence, it is important to make appropriate changes to the product backlog from time to time. Some teams like prioritizing the backlog for every iteration, some do it every release.

In conclusion, product manager in an agile world is like a glue that sticks together everyone involved in the product development. He has a clear vision of the product that he communicates to everyone. But he also accommodates needs of the business and development team. He works closely with business stakeholders, yet he is part of the development team

                                     

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 our 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, re-usability, 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”.