Managing The iPLAN Team; The Process, The Lessons, Challenges and Retrospective.

Managing The iPLAN Team; The Process, The Lessons, Challenges and Retrospective.

Collaborating with teams(especially cross-sectional teams) is a key part of a product manager's role, however, it is not a very straightforward task. in some cases, the success or failure of a product lies in the way the product development teams are handled and managed. A good product manager knows how to make sure that members of the team not only work towards the product vision but also work in unison with members of the various teams.

Here are some of the processes undergone by members of the team while building the iPLAN app, lessons learned, challenges faced and a few things we feel should have been done differently

Processes

Brainstorming Sessions, Research Summary Reviews, Meetings, PRD, and Kanban Board are the main ways we managed the teams.

Brainstorming Sessions:

Brainstorming is a group problem-solving technique where teams involved in the development of a product meet to make decisions regarding the product, and because this is a completely remote company, we used Google Meets for these sessions.

Every member of the team brings their ideas on how to make the product great and the entire team deliberates on it till a decision is met

Features, roles, responsibilities, ideas, next steps, and decisions are some of the things discussed during our brainstorming sessions. Notes were taken and relayed to each team after the sessions. So after each session, everyone is on the same page.

Research Summary Reviews:

Research Summary plays a key part in knowing what next steps to take in feature prioritization so when a research result is gathered, we share the summary between teams so that our feature list can be reviewed and in some cases, modified. In our case, the design team handled user research and shared the summary with product managers, who in turn used the data to make a feature list and a low-fi wireframe, prioritizing the features that were selected. These reviews were mostly done using our slack channels.

Product Requirements Document:

A detailed PRD was created by the Product Managers, it showed product features, user stories, success metrics, product details, assumptions, requirements, user interaction, design, and the scope of the product. This document was shared with the Design team so that it can serve as a guide for building and launching the product.

0001.jpg

0002.jpg

0003.jpg

Kanban Board:

A kanban board was created and managed by the product managers to be able to track the workflow progress of all teams visually. It shows task descriptions, tasks, columns that show task status, and the teams assigned.

image.png

Iteration:

The agile method of product development is a very flexible one that supports iteration. Designs and features were corrected and modified, and worked on over and over again till we were satisfied with the outcome. This process was easy to manage using the kanban board.

Lessons

Managing the teams taught lessons that have increased our skills and also bettered our character.

Communicate till the vision of the product is understood:

As a PM, it is important to be crystal clear about the product vision, expectations, timelines/deadlines, process stages, and decisions to avoid friction. Lack of clear and concise communication can cause friction in the workplace, slow down the team and cause a drag in the release of the product

Agree on Team Responsibilities:

In some cases, the design and PM teams might have clashing responsibilities so it is good to agree on who does what and when before the development process starts. For example, the design team went ahead with user research while the PM team found it a bit offensive as they thought that was their "responsibility". So to avoid tension in the workplace, it is good to discuss these responsibilities and roles from the get-go.

Document Meetings:

It is advisable to communicate meeting notes to members of the respective teams so everyone is abreast with all information shared and has a clear understanding of their roles.

Carry the Teams Along:

When the task was given, the design team and product were not in communication as each team started working individually before having a meeting together. This caused a major setback in deliverables.

PS: A PRD is a very important document. Honestly.

Challenges

Working with teams is generally a dicey situation, especially in a remote setting. Our major setback while working on this product was not being able to connect with the dev team. All efforts to reach them proved futile so there's no finished product yet, however, the challenges faced with working with the design team are as follows;

Communication:

Before this task, I had an idea of how important communication was but now I have a clear understanding. We had to have a series of meetings through phone calls and texts to fully understand what our various roles were, how to manage the roles that seemed like they intercept each other, to discuss features and designs, etc

Carrying the Cross-Sectional teams along:

The teams feel like they can work individually alone so it was easy to get carried away and not include the other team in the progress of their process. It took constant intentional efforts to reach out to the other team to make sure they were working according to the vision of the product, to check on the status of their given tasks in the sprint, to discuss the research summary, to review features and design functionality

Handling Inter-dependent Tasks:

Some tasks depend on the completion of another task (sometimes from the other team) before they are done and this in turn slows down the team.

Making Sure Deliverables align with product vision

It is easy to get carried away with our pursuit for perfection, style or even what we perceive might be a better feature or design. This was a challenge because we constantly had to go back to the drawing board to make sure our goals were aligned

Retrospectives

As a team, the entire process was an exciting and eye-opening one for all of us, however, there are a few things we would do differently, moving forward. Which are;

  • Estimating and setting realistic timeframes for tasks and sprints
  • Work hand in hand with members of the other teams from the get-go
  • Thoroughly brainstorm about the product before and after research is done