Commitments, deadlines and plannings

Many product teams, and especially Product Managers who breath agile, don't like the process of planning, nor sharing those plans with stakeholders, nor committing to deadlines. They feel they are losing flexibility, and they want to avoid uncomfortable questions and challenge from stakeholders.

In most agile teams, when you mention commitments (like knowing what you're going to launch and when it will happen), you get reactions ranging from squirming to denial – Marty Cagan.

In the current cycle of OKRs at Ontruck, product teams have committed to achieving 100% of some Key Results. Those projects are critical to enabling new product and business improvements, so we want to make sure we deliver them entirely this quarter. We asked Product Managers to have a detailed plan to discuss internally and organize the rollout with business. The rest of the KRs have the regular goal of achieving at least 70% of the ambitious target. The change wasn't so smooth, of course.

The intention of avoiding commitments and plans is common and can lead to misunderstandings and frustration between product and business teams. However, it doesn't have to be that way.

When to make commitments

Good product companies minimize commitments. They usually work in the uncertainty, trying to disrupt a sector while validating the value proposition. They need to learn while building the plan. That's why the agile methodology works better than the waterfall methodology in these type of projects.

However, once you have certainty, there are always some real commitments you need to make to effectively run a company. Marty Cagan wrote an article on High-Integrity Commitments which reflects well on this topic.

The key is to understand that the root cause of all this grief about commitments is when these commitments are made. They are made too early. They are made before we know if we can actually deliver on this obligation, and even more important if what we deliver will actually solve the problem for the customer.

The question for product teams isn't if there should be an estimated deadline, it's when are you ready to commit to a deadline. The best practice is to do enough product discovery to validate the approach, then control the risks and plan the execution. At that moment, you will be more willing to commit to phases and dates, which will help our business colleagues to do their jobs as well effectively.

For example, Ontruck product teams have committed to achieving 100% of five Key Results in Q2. All of them had a related KR in the previous quarter. Those projects were different in many aspects, but their target was to validate the approach to solve the problems before investing more:

• We validated the Unique Value Proposition of a new external-facing product we're launching.
• We validated the technology of a third-party tool we're going to use to replace a business provider.
• We validated with Sales that a new engine can solve all their client cases.
• We validated a new tool that uses a data science model to suggest actions to business.
• We designed and aligned with operations, a complete revamp of one of our critical internal processes.

Once we proved the approach was valid, with internal and external users, we removed most of the uncertainty. It's now an execution game, so we can and should commit so business departments can prepare in advance.

Have different versions of the same plan

One of the learnings Product Managers need to experience is that their team, their stakeholders and themselves may have different planning needs. The success comes from aligning everyone on the same plan with different level of information.

PMs who don't like planning may advance well without a detailed plan:

• However, their engineer and designer colleagues may need to see the full picture in detail to make decisions thinking in the medium-term. Without a plan, they can quickly become a feature product team without a product vision.
• On the other side, stakeholders need some certainty to make decisions (hiring, process changes, sales pitch). Without a plan, they will complain about lack of visibility, lack of commitment, and sudden changes in the products.

PMs who do detailed plannings – former project managers usually– may need to have everything under control.

• However, their engineer and designer colleagues can't give them clarity when there is still uncertainty. They can't commit to deadlines in advance as they need to get user feedback from the first releases.
• On the other side, stakeholders won't be able to process the full planning. They need the dates and scope of each feature release.

Mediocre PMs don't have any plan, good PMs have a plan and great PMs have different versions of the same plan. I may need A as a plan, but my team may need B and my stakeholders C. I communicate the same information in different ways.

One way of planning is doing roadmaps. As an example, these are the different roadmaps we've done at Ontruck in the last month with the same information (Q2 OKRs):

• Investors roadmap – by CPO, one slide, for investors. We focus on eye-catching new features we will do over the year.
• Outcome-driven roadmap – by CPO, several slides, for management. We focus on the key themes and outcomes we aim to achieve the next two quarters. It serves to get feedback and prioritize next OKRs.
• Feature-driven roadmap – by CPO, an email, for business. We focus on the key features they are expecting, separated by departments to assure they read it. We explicitly indicate if something is an experiment or has high risk.
• OKR cycle roadmap – by PMs, a spreadsheet, for product teams. To decide the OKRs, we plan the potential quarter. It acts as an internal double-check during the cycle. A useful tool is to calculate the Cost of Delay of each potential KR.
• Internal roadmap of a project – by PMs, a notion page, for product teams. Once we have certainty, we scope the different phases of the project, and we plan the work that we need to do.
• External roadmap of a project – by PMs, an email, for business. We communicate the releases of the different phases of the project, so business can give feedback and prepare.

You can read more about Outcome vs Feature-Driven roadmaps in this Produx Labs article.

In conclusion, the best practice is to understand the level of uncertainty, do product discovery to validate the approach, manage the risks, commit to a deadline, and plan accordingly. Hence, all the departments have the right information when they need it and they will trust you.