The most comprehensive bank Interview Answer Review tooling available online.

A good product manager must be

Customer centric - A good PM will always keep their customers at the heart of every decision. It is essential that the product team is working on features as per real user needs. In order to do this, PM should be able to be able to work through customer feedback, reviews, analyze these data to understand their true pain point and prioritize the right features for delivery.

Clear communicator - Clear communication is of utmost importance for this role. It is essential that a PM is bale to articulate a complex problem in a simple manner. A PM deals with various stakeholders and needs to be able to communicate in a clear manner to be able to align all the teams towards a common goal. 

Strategic thinker - A good PM should be able to think several steps ahead, planning actions strategically aligning with the business goals. This includes planning a clear roadmap, anticipating risks, and making decisions that balances short term and long term success.

Good problem solver - Problem solving is very central to a PM. There is problem solving in every aspect of the job. A PM should be able to break down a complex issue into smaller manageable problems and employ effective approaches to address them. A PM should also be very resilient under pressure and work in ambiguous situations.

When I joined my new team , I took lead on a new project which was complex in nature, had many unknowns and our team had to work on new framework, techstack, data models. The team was following agile methodology and will start with the work in first sprint. there was no concept of zero sprint or story grooming prior to the start of first sprint.

with the existing approach I envisioned some issues:

1. Because the number of unknown were high, the chances of doing wrong estimations for development were high.

2. There were high chances that the prioritisation is not right and we might have to revisit the features again and again.

3.  We might find out about unknowns while we are in the development process and that might cause delays.

To overcome these issues, I suggested some changes in our approach:

1. Increase the planning for one more release cycle and group the features as now, next and later.

2. For the features planned in the now group , prioritise them for the next release and complete the research and PRDs for them one sprint early. That means dev and QA will have 2 weeks extra to go through the stories, find out the dependencies and share the feedback. This helped in identifying if we need POCs for any feature or we can right away start developing them. Or if further modularisation is required.

3. I suggested to track the features related to new project in a different group, because to begin with the pace of the delivery will be slow.

When we begin, we took one complete release only in the RnD and understanding the new framework and doing small POCs to validate our understanding.

From second release, when we as a team were ready with good understanding on the expectations and other tech dependencies we started delivering and we could complete 2 full flows from end to end.

We had very less amount of spillover and could complete almost everything in the backlog, which was a big issue in earlier releases.

Conducted a group brainstorm on problems we should be solving in the coming year 

Organised a team wide hackday with presence to leadership 

Encouraged the team to host brownbags and invited team globally to attend

Organised a team sport 

Disaster management app will have two goals: how to be aware of potential solutions before a disaster and how to be an active participant in supporting post-disaster efforts.

There are three main users of this app:

1. The staff of olympics committee: These people are insiders and are well-trained through the process of disaster management. They also know different responsible heads of the committee and can seek their advice for any situation. They are familiar with the venue and surrounding areas. They can be our champions during disaster management exercises. They may have complete access to the venue.

2. The participants of olympics: These people are outsiders and are totally new to the concept of an Olympics organization. They neither know the organizers nor the location of their residence. They may also have language barriers. They may have limited access to the venue

3. The temporary staff of olympics: These people are relatively unaware of the committee and venue. They may only have limited access to the venue where the services are required. However, since they may be local people they can come to rescue if more resources are needed.

Broadly the main pain-points include:

1. Lack of awareness of the venue and the associated emergency exits. 

2. Lack of training on natural or man-made disasters

3. Language barriers

4. Low access to responsible people

To solve these problems, we can create a disaster management app with components that may provide education and support on these above mentioned painpoints

1. Landing page or homepage. This will have a set of CTA for the other surfaces, latest weather updates, latest local news widget and announcements sections

2. One surface with a digital maps version of the venue. This surface will have well-explained iconography to make it easy to adapt

3. One surface with a chat version where one can chat with the olympics committee heads. This chat would be protected with permissions for privacy issues.

4. One surface for gamified training modules that all the participants and staff needs to complete.

5. One surface for account and profile information. The committee can also use this surface to allocate digital currency so that athletes can operate in a post-disaster landscape if they lose their money.

MVP for Maintenance module where all maintenance work was tracked for the vessels. While it was lift and shift but challenge was identifying the gaps and prioritizing correct features to provide MVP. For example, I brainstormed certain features like equipment maintenance, work orders, were most important than some reports.. I also realized that some authentications, system preferences were also missing which holds highest importance. There was also a feature where it would automatically tell which maintenance work is upcoming. I developed a report of my findings and came up with high impacted features that were missing. The effort was estimated, and high impact low effort took first seat in the roadmap followed by high effort features. Early Adopter mechanism

Result: There was 80% parity achieved w.r.t. legacy system for high impact features and 30% of targeted adoption was achieved for Maintenance module.

What I hope to achieve in my product management career is creating lasting value for the planet. I hope to have a significant opportunity to create technology and release innovation that improve's the quality of people's lives, the efficiency in which we move, exist and advance humanity as a whole.