Consistently delivering on time, a guide for new Product Managers

Delivering on time with 100% predictability.

Félix Revert
May 4 · 11 min read

In this article I am going to write about two things: why managing project timelines is a must for Product Managers and how to leverage tools to achieve it with high confidence.

An example project timeline for my Product Team I made on asana

Why Product Management is so cool… but can be highly stressful

And with that you come to realise a harsh truth. If you want to succeed, you cannot rely on your strengths to counterbalance your weaknesses. You have to be at least decent in all the tasks that fall upon your shoulders. That’s how you get people to see you as reliable. Because above all, Product Management is about building trust.

And I had a clear weakness: managing to deliver on time. Or I should say, understanding what it takes as a PM to guarantee that the team delivers on time.

The elephant in the room: the product roadmap

Indeed there was a problem. Tasks were harder than expected. We were solving problems no one in the company had ever solved before so we were taking the toll on having to align and rely on many stakeholders outside the team to meet our objectives and timelines. I was postponing key things, like defining the specs of a big feature that would take me days of intense focus, because the shifts in the current project timeline were more urgent to solve. At that time, I didn’t understand how much delay I was going to bear. Stress was high.

In the end we managed to sort it out, ship the intermediary features that were blocking the others, align on the new specs, and work out the big feature. With 2 months of delay.

But one thing changed for the better: how we managed our project timelines. And it was at that moment that I really took responsibility for it, that I started owning my team’s project timeline.

Looking back at how it started, there were clear dysfunctions

On the long term, to please the Product leadership team, I had a product roadmap that was convenient to them:

  • Feature 1: 4 weeks
  • Feature 2: 4 weeks
  • Feature 3: 6 weeks

But when the engineers estimated them, it was more like:

  • Feature 1: 10 weeks
  • Feature 2: 12 weeks
  • Feature 3: 10 weeks

Over-promising on one hand, pressuring the delivery team on the other hand. A clear recipe for failure.

Understanding what a Product roadmap is about

Certainty in the capacity to deliver

  • A phase of clear certainty on what will be delivered in the next 1~2 months
  • 2 phases of unclear certainty on what would and could be delivered in the next 3~12 months

The urgent problem was the first phase. How could my team consistently deliver features with high confidence in the next 1 to 2 months?

Reverse engineering the phase of high certainty for perfect preparation

Everything that happened before the project was well handled. Indeed, Product planning was my strength: I love to talk to users, analyse usage data, pinpoint problems, federate the team around a mission.

Tech planning was great too. The engineers worked hard to deliver high quality technical specs, with JIRA tickets that were between 1 to 3 dev days. The project timeline seemed to be good too, put into Excel, very transparently, by the Tech team.

Everything seemed to be alright.

But once into the project delivery phase, our timeline consistently shifted

So I had to look somewhere else…

One day, the Engineer Manager in my team suggested that I should do the project timeline for our next Sprint as the engineer responsible for it was too busy with another issue at that time. That decision changed everything…

The pitfalls behind Project timelines

To start doing our project timeline, I was given the blueprint made by an engineer from another team. The timeline was made in Asana and looked like that:

If the tasks were neatly arranged, it raised some interrogations for the new PM that I was. Why are bugs and tech tasks counted in the timeline? And how many engineers were in that team?

Well, there were 3 software engineers in that team. And bugs and tech tasks were taking the time of a full engineer…

Key learning #1: an engineer isn’t working 100% of the time for your feature

The key figure was

A software engineer is dedicating 50% of his time to the development of features

I was kinda taken aback. 50%? Isn’t it a full-time job? Well, when building a product, it turns out you cannot focus 100% of your time for new features. Instead, you have to dedicate some time to solve bugs, work out technical tasks no related to your current project, commit to be on “duty” where few days each year you’re responsible for monitoring the release of all features in the product, etc.

Key learning #2: estimations are wrong if the methodology isn’t clearly displayed

Also, there was a bias for software engineers to estimate in days accounting for 100% of their time, to go faster in order to “solve” our current delay. But during the project, the Engineering Manager was here to make sure the engineers worked to solve bugs etc, increasing the actual time taken compared the original estimation. Which delayed even more the current project…

Key learning #3: take bugs and constraints into account in your timeline

On top of it, putting the Bugs and Tech tasks in our project timeline would allow us to dedicate 30% of engineering time to them with certainty.

More has been written on this topic: Handling bugs at Doctolib

Key learning #4: don’t forget internal and external constraints that will impact your delivery

Internal tasks [10–30% of total Sprint time]

  • Creating a feature switch [~1 day]
  • Performance audit of the feature [~1 day]
  • Embed usage tracking [~1–3 days]
  • Feature documentation [~1–2 days]
  • Writing Technical specs for next sprints [~3–5 days]
  • Last iterations on the feature, based on feedbacks from product team or early testers [~3–5 days]
  • Removing the feature switch once feature is released [~1–2 days]
  • Refactoring code + tests [~2–5 days]

Other components to take into account in the timeline:

  • Other teams’ delivery [the PM must anticipate proactively as no one from other teams will join your SUM and give feedback on their timeline]
  • Public holidays
  • People taking days off

You get it, way too many factors that explain why a project timeline shifts.

Alright. We’re all pumped up now. Ready to get our hands dirty and create our project timeline.

The (ultimate) project timeline for feature teams

To create this timeline, we tried Asana, as it was a tool used in our company. I found it hard to use it at first: an unusual keyboard experience (and quite poor in my opinion), constant back and forth between “List” and “Timeline” views… But in the end it provides a really nice display and it is quite flexible for collaboration. Be careful though when moving tasks that are dependent to others, I know what I’m talking about.

Example of a project timeline for a Sprint with 2 engineers in the team

How we use it in the team

How to read it

  • Equation #1: # engineers in the team = sum of 3 rows

Each day, you sum 3 rows together “Bugs, TT and Duty”, “Sprint — Software Engineers”, “Absences”. The total is the number of engineers in the team. If the equality isn’t respected, then something’s wrong. You should make sure that each day there’s 1 and 1 task only for each engineer in the team.

That allows you to methodically parallelize tasks and make sure you’re not over/under promising.

  • Equation #2: story points of “bugs, TTs and Duty” = 30% total project story points

We’ve come up with a reasonable calculation method. A feature ticket is estimated in days. If a ticket is estimated 3 days, then a software engineer should work on it for 3 days. That means he’ll technically spend 1.5 days on it since he’ll be spending 50% of his actual time on it. But in team’s view, it’s 3 days.

In Asana, you can go into the “List” view and do the maths. To follow our example:

14 days for Bugs and Tech Tasks
28 days for Feature tasks

We do the maths: 14 = 33% * (14 + 28)

Sounds good! We’ll dedicate 33% of our time to bugs and Tech tasks in this Sprint. It matches our objective of 30%.

How to create it

  • JIRA tickets with estimated development days (story points) and dependencies to one another
  • A good deal of patience to learn to use Asana

Fill the “List” view first:

  • Add all the JIRA tickets into your Asana board.
    Note I tried to export tasks in csv from JIRA and re-upload them on Asana. It’s not simple. You have to delete many useless columns, re-write story points… I’m better off with my Ctrl C Ctrl V skills, even if it takes 15 dull minutes of copy paste.
  • Add the same dependencies that exist on the JIRA tickets
  • Add story points in a new column (click “add new field”, choose numeric, name the column “Story points”)
  • Add the type column. 3 types is standard.
  • Label each item with their type
  • Add due dates for each task. For now, no need to put relevant dates

Then, fill the “Timeline” view:

  • With great drag and drop skills, make sure tasks are displayed in a linear way. You have to display as many lines in the “Sprint — Software Engineer” list as there are engineers in the team
  • Then display the bugs and TTs above, the absences below
  • And then re-align everything respecting the key rule: # engineers in the team = “Bugs and TTs” + “Sprint — Software Engineer” + “Absences”

Example: the image below shows the timeline for a Sprint with 2 engineers in the team. You can see that on each individual day, the equality is respected.

Last tips

  • Your tasks will almost never perfectly match the 5-day workweek, and many tickets will include 1 or 2 days on weekends. We haven’t found a better way to just let them stay on the weekend. If this happens, we let a free day on Monday. Same if the task goes on both Saturday and Sunday, then Monday and Tuesday will be empty for this engineer.
  • Don’t forget to put your next sprint planning tasks on the timeline, like writing Technical specs, since it’ll take a lot of the engineers’ time.
  • One thing we haven’t tried yet is to add a buffer ticket at the end of the project, like 10% of the total project time, to manage the “known unknown”
  • Another idea we haven’t tried yet is to duplicate the timeline to be able to compare how it went vs you planned it

And that’s it! Your team is now ready to rock 🤘

Hope you liked it. Let us know what you think in the comments. Happy to reply to your suggestions.


Improving Healthcare for Good


Founded in 2013, Doctolib is the fastest growing e-health service in Europe. We provide healthcare professionals with services to improve the efficiency of their organization, transform their patients’ experience, and strengthen cooperation with other practitioners. We help pati

Félix Revert

Written by

PM @Doctolib after 5 years as data scientist. Worked for DataRobot, Capgemini & Accenture


Founded in 2013, Doctolib is the fastest growing e-health service in Europe. We provide healthcare professionals with services to improve the efficiency of their organization, transform their patients’ experience, and strengthen cooperation with other practitioners. We help pati