Vulnerability theory and the product manager(owner)

The PM/PO is responsible on the project because he sets the priorities of what to be developed, comes up with deadlines, controls the budget, and in same time he is accountable on customer acceptance.

In this post I shed the light on how a vulnerable PO can be instrumental in delivering what the customer truly wants in Agile set-up.

A non vulnerable PO would avoid facing the development team without having first detailed requirements and probably documented use cases. Her strive to be perfect will preclude the project from the tremendous opportunity which can only happen if the “PO changes her mind”.

Non vulnerability will lock the PO on himself before jumping to the arena and avoids involving the team very early. Changing the PO mind is the the key for experimentation because it is based on the axiom that I am vulnerable, therefore I seek to validate the requirements and I am open to change my mind based on findings in-order to deliver what the customer truly wants. Despite the presence of many unknowns, the non vulnerable PO will still seek control and predictability!!

Baking requirements and then presenting them to the team is a common practice which is anti Agile because of:

  1. Development team has not been involved in requirement development, therefore, the team members’ understanding of the application will be low.
  2. Project risk is directly proportional to the quantity of requirements. The larger the requirements, the more non-validated learning with the end customer, which means very high risk because we are developing software to be thrown away.

Even when the development team is involved early, the non-vulnerable aspect of the PO can be barrier in having him understand what the customer truly wants which can happen only if he is open to pivoting and to change his hypothesis.

In a recent project a key architect from a prime vendor complained that there are no detailed requirements to use as basis for her development work. The PO was attacked and became so defensive and got even feeling of shame. Despite the project was so dynamic with many changes happening daily, still they demanded from the PO to provide detailed requirements!

After some coaching, the PO said bluntly “I do not know the requirements”, I only know to some extent “what I want” to be delivered in the next release after 2 months. The development team should elaborate on ” what I want” to arrive at stories in their own jargon  which are at a detailed level enough to carryout both the development and testing work. I will review sprint-wise the software which the team produces to check:

  • Are there changes required?
  • Is that software worthy or we should get rid of it?
  • Was I wrong on what I stated and should make changes or even change direction?
  • Have the end customer to concur on the findings and use his input to change my mind.
I will be daily involved with the team to answers their questions, if I can, or I probably  will need to check with the end customer before answering team questions. I might cancel the sprint as a worst case if there is no way I can make it right. We will learn from this experiment and decide together how to improve. I even can change my mind about the release itself, I will communicate that change to the team once “I have even slight doubt”.
The previous approach has worked. For me this is true leadership and the key motto here is vulnerability.
The previous text in blue can come only from a vulnerable PO who understands the true spirit of being Agile. Vulnerability is strength and not weakness. Creating detailed requirements is indication of defense and lack of guts to deliver meaningful outcomes to the end customer. Vulnerability will allow us to realize that requirements are merely guesses which will lead the PO to communicate the minimal requirements to the team and only after customer’s validation.
Let me conclude this post with the following statements from Dr. Brene Brown:
– Vulnerability is our most accurate measurement of courage.
– For organizations vulnerability is the birth place of creativity, innovation and change.

2 thoughts on “Vulnerability theory and the product manager(owner)

  1. Sameh : Nicely written, although i have been away of SW dev for quiet a while now (forced to start thinking of it once again by the rise of the Dev-Ops Concept an integral key i think in the evolution of IT services ) it thought it was a brilliant idea/concept pretty much applies to any areas…

  2. Thanks Walid for your comment.

    For product development organizations, it is usually easier to implement the idea in this post than if the set-up were a regulated IT because:
    – The role of product owner can be hampered because of excessive communication needed with end users to get their approval on what we produce.
    – Turf battling can be high in IT which sometimes can lead us to produce service or product of less business value to the end customer. Team formation is affected by departments’ boundaries and having all required skills on the team can be challenging.

    Also, I think it will take some time before the business analyst in IT becomes in charge of the project instead of the project manager.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s