One of the most important skills of a product manager is the ability to manage expectations and commitments.
The hidden responsibility of a product manager is to help build trust and confidence in the product teams with business stakeholders.
In this guide we will explore the purpose of commitments, then look at types of commitments, what a head of product can do to help, what a product manager can do and how to represent commitments to manage stakeholder expectations.
The agile factory challenge
It can be quite a challenge given some of the work of the agile factory has had on people's minds about making commitments and visualizing them.
BOOK QUOTE
"In most Agile teams, when you even mention the word "commitments", you get reactions ranging from squirming to denial." - Â from the book Inspired by Marty Cagan.
As someone who has spent time as a project manager in construction and tech, I am no fan of GANTTs. I have personally created detailed schedules and tracked dependencies across a massive programs of work - even portfolios, in various organizations and industries.
It is an absolute waste of time - not to mention the regular monthly & quarterly planning sessions which is so much extra admin for nothing.
However, when I got into management roles, I realized the importance of planning and expectation management which is something I couldn't phantom as an individual contributor. I then also understood the various ways and alternatives to manage expectations.
The key importance here is to explain to a team its not about estimations and managing them but more so managing expectations and helping drive business outcomes.
The GANTTs & roadmaps
I found that GANTTs a world war 1 artifact used in the waterfall world of project management was rebranded to roadmaps in the world of agile cultists to show a more leaner and UX friendlier version.
A good roadmap is one which visualizes the upcoming quarterly priorities for stakeholders and the customer but doesn't go down into the rabbit-hole of details.
The purpose of commitments
Commitments are required for 3 major reasons:
- Alignment on prioritization of efforts
Businesses have multiple departments, functions and people. To align everyone to focus on a particular effort it requires some planning. This requires an agreement on priority which can come from effort analysis and estimation process which gives a business an understanding of when something will happen. - Highest business value items are the focus
Business leaders want to ensure that the teams they are managing are working on the highest value items to ensure they are profitable and meet business objectives. If they understand that something takes longer then maybe they might another decision. - Partnership/ business agreements require date based commitments
Every business has agreements with other businesses which quite often require time based commitments. It is almost impossible to build a partnership without this commitment.
Types of commitments
There are 3 main types of commitments and they are based on predictability and confidence that a product manager must communicate to the management team and stakeholders.
Pro Tip: Confidence levels are important to understand and communicate. They should be made explicit and not assumed. (ie: Spell it out that something is probably going to be 40% probable, it will help people make decisions if they want to invest in something or change and explore other options).
- High integrity commitments
A commitment where the confidence levels of the product team and product manager are high at 80-90% based on a clear understanding of the challenges involved and what needs to be delivered.
It's normally important for a product manager to explore the risks and options available here to deliver on this type of commitment.
To get to this type of commitment, it is important to spend time on discovery efforts and validate the solution space to minimize schedule risks caused due to the uncertainty in technology development. - Roofshots
Intiatives with 60-80% confidence levels on delivery and there is a risk that its still something that could blow out by a margin of 20 - 40% due to dependencies, lack of time on discovery, unknown effort for recovery.
Pro Tip: When presenting the roofshots a product manager must have some options available to ensure that stakeholders can make a decision on if they want to progress with that option or go for something with higher confidence levels. - Moonshots
These are typically R&D initiatives with very high unpredictability. They are the sort of high reward high risk initiatives most of the time, but may actually be high risk and low reward. They may also lead to businesses making massive losses and going bankrupt or having to shut down business units.
It is very important the product manager understand the confidence for anything below 50% is a moonshot. As with roofshots, the product manager should come up with some options for the stakeholders to make decisions.
The product leaders should understand the risk involved here before agreeing to go down the pathway.
IMPORTANT: Quite often in the world of technical debt in software, product managers might find themselves in a tough spot with some very easy initiatives being moonshots simply because of the tech debt. In these circumstances, it is critical that the PM calls out the reasons for low confidence and explains why it is a Moonshot that must be addressed.
Management 101 - what you can do as a head of product
- Provide direction and guidance on what, why & when
As a manager, providing guidance to a product manager will allow them to inspire and evanglise the business vision and eventually product vision with the product teams, aligning and motivating them.
I have seen all too often that many executives keep these details up their sleeves and the teams run around without direction just seeking it.
The head of product needs to coach the business leaders on sharing the vision and details so that this can trickle down into the product vision and strategy and teams can benefit from this direction. - Reduce the number of commitments with high unpredictability
As with the number of initiatives to embark for a team to manage their work in progress, the number of commitments with low delivery confidence should be reduced.
This allows the team to be successful for delivery. That builds trust with other stakeholders.
This is literally the most important thing for a manager to do.
Help a team build trust and confidence.
PM101 - What can I do as a product manager?
- Confidence rating framework
Have a confidence rating framework and set high confidence for the ones with assurance on delivery date. - Discovery
If the confidence is low ask for more time on discovery to determine options and risks. - Communicate
Over communicate, it is always safer to over communicate than under communicate. - Checkpoints
Regular checkpoints and updates on progress is super critical to keeping things on track. - Celebrate
Celebrate wins! Celebrating helps build confidence and trust while also motivating teams. As a product manager one of your key roles is to help build trust in the teams and stakeholders. You are the glue between the engineering & design teams and the rest of the business.
The curve balls to watch out for
- Dependencies
There are different type of dependencies, from another product team to a 3rd party vendor to a business partner.
It is important to keep a watchful eye on the dependencies and have regular checkpoints.
Don't forget to over communicate on progress of these dependencies. It helps drive trust and confidence. - Risks
As with dependencies, there are risks with different levels of impacts and options to mitigate. Understanding and planning for these is critical. - The Resource Trap
While on this topic, if we consider what Fred Brook said in 1975 about the observation he made on software project management, according to which "adding manpower to a late software project makes it later".
This he stated was due to ramp up time, communication overhead & limited divisibility of software development work.Funny enough, 40+ years later a very senior engineer I worked with, called the phenomena of having too many engineers "Merge Hell".
This was on a team with 10 software engineers & 5 QA engineers on a single codebase on a product which was on a "project lifecycle" and 2 years behind its schedule not to mention a few million over budget! (it had CICD, microservices architecture, automated testing and all the buzz you can think off from a technical standpoint - but the one thing it didn't have was good product management!)
In my opinion and experience, to avoid delays and large amounts of technical debt, the perfect size and type of product teams per product stream should be from 7-8 individuals including analysts, designers, product managers & engineers (Dev & QA).
Adding more isn't going to speed things up and improve confidence levels, it will just provide an illusion of that while creating some big problems. Beware you have been warned.
How to represent commitments
Depending on the tools you are used to using and tracking progress with - there will be different ways and views to represent these commitments.
A product manager must understand there is commitment by confidence matrix and then there is the roadmap.
The simpler the roadmap and delivery dates expressed the easier it is to consume and explain to stakeholders.
COMMITMENTS
Value to Confidence matrix
Similar to the value to effort matrix I shared earlier in the below article, the value to confidence matrix is a good way to get stakeholders aligned an make decisions fast.
KJ Sethna
ROADMAPS
There are 2 main ways of showing roadmaps:
1. Time based - aka Timelines
Listing the feature or initiative by delivery timeline.
This is something that can be used for high integrity commitments.
2. Priority based
Listing the feature or initiative by priority of when it would be delivered.
I prefer this for moonshots and roofshots.
Be sure to tune in for more guides, research papers, comics, tips, tricks and lessons in product, business & tech.
If you haven't subscribed, be sure to - its free!
References
Inspired - Book by Marty Cagan
Empowered - Book by Marty Cagan
