Consistently delivering on time, a guide for new Product Managers
Delivering on time with 100% predictability.
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.
Why Product Management is so cool… but can be highly stressful
As I was starting a new career as a Product Manager in a promising Tech company, something quickly struck me: how complex the role was. It was unlike anything I’ve seen before. A mix of many jobs gathered in one. Name it entrepreneur, consultant, manager, sales… A PM is all over the place, doing many things at once.
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
While the engineers in my team were hard working on features, the Product leadership kept asking me questions like “when is this big feature going to be released?”, “why does the roadmap keep on being delayed?”.
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 short term, I was delegating the current project timeline to my engineering team. Merely attending the SUM to provide answers for blocking points, I was not involved in the current project delivery. And the project timeline kept on shifting over and over.
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
So I had to deep dive on what was wrong. I started to try to understand how it worked at the core. And I tried to map how a roadmap for a feature team should look like:
- 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
Being able to accurately estimate the work of the team at the daily level for the next 1 to 2 months requires the proper retro-planning:
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
And I felt completely powerless. What was going wrong? We did all the classic rituals (SUM, retros, etc) but we still didn’t feel in control of the delivery time. I tried policing the team on the JIRA tickets but that wasn’t a good thing: I felt like an authoritarian product owner who’s role was blaming if tickets weren’t well estimated. And most of the time they were well estimated, with some delays of 1 day here and there. It didn’t seem to be the source of the problem.
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
After chatting in depth with my Engineering Manager, he shared with me a key graph that I saw before but didn’t really care about. This graph lays out what % of time a software engineer is dedicating to the development of the 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
When we estimated how much time a task would take, we realised that we weren’t clear about how we calculated the estimation. When we said it would take 3 days, did it mean 3 days at 100% of an engineer’s time or 3 days at the team level? It turns out each engineer had their own gut feeling for estimations. And the first few times we discussed about it we couldn’t simply align on a shared methodology. We needed several discussions to finally align.
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
As Bugs and Tech tasks take 30% of the time of an engineer, it surely is important. Instead of trying to estimate days to deliver feature tasks that account for both feature and bugs, separate the two: the feature tasks on one side, the bug tasks on another side. Way more transparent and simple.
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
Releasing a feature isn’t just pushing your feature to production. There are key engineering tasks that goes along it. Depending on the complexity of the Sprint, these additional tasks can make up for 10 to 30% of the total amount of work in the Sprint.
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
Now it’s time to apply what we’ve learnt to create a project timeline. No. Not just a project timeline. The best project timeline (yay, let’s do it!). This timeline, once finalised, should be clearly understood and owned by everyone in the team. This way, no room for systemic delays. No more useless stress. And a happy team 😄
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.
How we use it in the team
Everyday during SUM, after reviewing our JIRA board, we go on the timeline for 3 minutes and we make sure we’re on time. Here I would question why tasks aren’t validated on time, in a benevolent way of course. We would also tick tasks that are done to make a contrast between what’s been done and what hasn’t. And we would discuss briefly upcoming tasks and planning.
How to read it
Well, it’s not just colors and shapes. There’s also maths behind 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:
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
What you need:
- 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
- Get ready to be flexible. Bugs can take 4 days to solve instead of 2 initially planned. Just skip the next bug ticket of 2 days.
- 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.
