Handling ambiguity in a Product Manager role
Whether it is B2B or B2C or B2B2C, Today a product development company has the required team in hand to do the data analysis, business analysts to derive meaningful insights from the data crunched and then you have got the Big Data Engineers to handle the scale and clean the junk.
However, ambiguity still flows across the teams when a new feature is initiated. Product Managers stand with ambiguity on the insights derived from Market and User research, Developers stand skeptical with the requirements provided and face challenges in accommodating knee-jerk changes.
It is the Product Manager, the Janitor of the product who is responsible to handle ambiguity and instill confidence across all stakeholders.
Homework
For a Product Manager ‘homework’ is something different.
Clarified Ambiguity — Sounds confusing?. Well yes, a clarified ambiguity is more about understanding the ambiguous data points to be in scope and the ambiguous points which should be ignored.
Impact Analysis — These ambiguous data points are now the silos which impact the feature altogether. Jot down the impact and dependency percentage based on data points and intuition. Understand the level of disaster it may bring in.
Identify Gaps — A product with an exact solution to one specific user’s need is never a product. Certainly, there would be gaps between the feature and user solutions. It is about positioning the feature in a way to narrow down the gap or having a facility for customized solution above the feature to bridge the gap.
Data on Fingertips — Keep all data handy and comprehend the data to present the details to the team with clarity.
Be prepared for open-ended questions
The toughest part as a Product Manager is presenting an ambiguous feature with confidence to the team. Get ready for the open-ended questions which are shot back to you. It is here as a Product Manager to identify and pick the right points which add substance or clarity to the identified ambiguous points.
Plan for a rollback in case of a disaster
For a complete feature, sub-features are delivered periodically in a continuous delivery model. As a Product Manager, it is better to plan independent sub-features to rollback in case of any disaster. Check with your developers on the impact of the rollback technically. Is that a low impact or high impact rollback. Few times, the rollback would not be possible and the feature could turn to be irreversible. In these cases, it is wise to evaluate the risks before the sprint deliverable and document them in Functional Design.
Smaller Iterations or Huge ones?
Theoretically, we expect developers to help PM s to deliver smaller iterations but in reality, with Agile process on developers are so much on delivery pressure. So as a Product Manager it is one’s responsibility to empathize with developers and plan the User Stories to ensure their work-life balance is not impacted even during ambiguity.
Iterate your metrics
Change is the only constant in the whole process
In a Continous Delivery model, metrics are to be revised at each phase to measure success and receive feedback. Re-define your metrics to do both quantitative and qualitative success measurement at each iteration because caterpillar’s growth is measured on the basis of its metabolism to digest leaves while a butterfly’s health is measured based on its intake of nectar.
Identify the feature dependencies, upstream and downstream impacts and metrics to be identified to calculate 360 degrees impact for the feature delivered. It is important for Product Managers to ascertain on the metrics or KPIs formulated before rolling out at each stage.
Test, Test and Test
Generally speaking, the world has a perception that the Product Manager role pauses at requirement and again resurfaces at the metrics to measure success. However, in reality, Product Manager changes position in the development lifecycle and has to be alert at every stage of the lifecycle.
Though Quality Assurance team tests the deliverable from the context of Functional Design, It is the duty of the Product Manager to do Business Driven test cases to identify the issues and plan the next sprints accordingly. I would be writing more in my next article about Java Cucumber, a BDD driven testing suite for REST and can be integrated to Selenium.
These tests and results formulated will help the Product Manager with not only understanding how effective his vision is converted to a feature but also to be prepared on how would this feature deliverable have an impact on the product altogether and plan the next sprint.
Be calm and stay confident
Stakeholders respect the Product Managers who are confident in action and also help them understand the high picture along with letting them know the impact their deliverable will create. Staying calm in crisis and turbulence doesn’t mean to be indecisive, It is all about taking a decision.
Ensure there is transparency across different stakeholders but it is also the responsibility to ensure any impediment or jolt doesn’t bring the team’s morale down.
Be Responsible for the failure
Sometimes with constraints around or some unexpected change may land the feature into a failure. Step up and take responsibility for the loss. Learn from the failures but do not take the failure to heart and feel guilty. Always believe you are the Superman! who was able to handle the failure with a less negative impact.
