{"id":78128,"date":"2022-04-19T15:28:58","date_gmt":"2022-04-19T14:28:58","guid":{"rendered":"https:\/\/www.prodpad.com\/?p=78128"},"modified":"2025-01-13T16:25:53","modified_gmt":"2025-01-13T16:25:53","slug":"deadlines-and-gantt-charts","status":"publish","type":"post","link":"https:\/\/www.prodpad.com\/blog\/deadlines-and-gantt-charts\/","title":{"rendered":"Breaking-Up with Deadlines and Gantt Charts"},"content":{"rendered":"\n

Once upon a time \u2013 as a young, naive product manager \u2013 I used deadlines on my roadmap. It seemed like the right thing to do, but actually, it caused me a lot of pain.<\/p>\n\n\n\n

At some point, I switched from a chronological timeline to what was effectively the Now-Next-Later roadmap<\/a>. This improved our work, our morale as a team, and my own relationship with product management. What a relief!<\/p>\n\n\n\n

In this post, I\u2019ll explain some of the pain points and hassles I experienced when I was using timeline roadmaps \u2013 and why I had to break up with them. At the end, I\u2019ll explain how you can break up with them, too.<\/p>\n\n\n

\n
\"Liz<\/figure>\n<\/div>\n\n\n

Why deadlines aren\u2019t a good match for Product Managers<\/h2>\n\n\n\n

I worked in a corporate environment, in a big product management team. It was a high-ticket B2B product, so we didn\u2019t have many customers (dozens rather than hundreds) \u2013 which allowed us to have close relationships with them. That was great because we could speak with them directly on a regular basis and understand their needs. We had accurate user groups with well-defined problems.<\/p>\n\n\n\n

But the downside of the larger corporate environment, from a product perspective, was that we were less agile and slower moving. My role was to set out the product strategy<\/a>, but because I knew no better, I put delivery dates on things because those timelines felt reasonable to me. The company could never meet the deadlines, though.<\/p>\n\n\n\n

So when we had these regular customer interactions, which often included roadmap presentations<\/a>, I would use the same roadmap for months on end, presenting it several times in the exact same form. I just changed the dates because as a business, we weren’t quick at execution. So, like clockwork, a couple of weeks before the next customer meeting, I\u2019d take the last roadmap and simply change the dates.<\/p>\n\n\n\n

Our customers caught on and they weren\u2019t impressed. Thanks to our close working relationship, they felt comfortable telling us exactly what they thought. And they called us out on this repetitive, perpetually delayed roadmap.<\/p>\n\n\n\n

For me as a product person, it felt humiliating. I’d show a roadmap to a room full of people and some would say, \u201cYou literally showed us that same roadmap six months ago.\u201d I had to explain why that\u2019s the case, representing a larger business with many moving parts that I couldn\u2019t influence, let alone control. Plus, I knew they were right! But I had to put on a good face for my company.<\/p>\n\n\n\n

This is what timeline roadmaps and Gantt charts do to PMs. We get stuck in an awful situation where we can’t get it right! And when we\u2019re stuck in relationships like that, it\u2019s time to break up.<\/p>\n\n\n\n

The breakup<\/h2>\n\n\n\n

The process of switching roadmaps required some vulnerability, lots of discussions, and finally some patience and experimentation.\u00a0<\/p>\n\n\n\n

Address the problem<\/strong><\/h3>\n\n\n\n

I had to tell people the pain that I was feeling, explain why the timeline structure wasn’t working for me, and suggest an alternative approach. <\/p>\n\n\n\n

Get support<\/strong><\/h3>\n\n\n\n

Though I initiated the change, I needed to get buy-in from my direct manager, who then helped to socialize that amongst the other 10-15 product managers. Ultimately we all discussed and standardized what we\u2019d try next.<\/p>\n\n\n\n

Choose a new direction<\/strong><\/h3>\n\n\n\n

We opted for a horizon roadmap, one that closely resembled what we call Now-Next-Later. It was three chunks, outlining objectives that the company will focus on in the immediate, short- and mid-term future \u2013 these are the horizons. For example: \u201cNext year our objective is to enter a new niche of the market, so we’re focusing on X<\/em>. And the year after that, our objective is user growth, so we’re focusing on Y<\/em>.\u201d<\/p>\n\n\n\n

Given the slow-moving, corporate nature of the company, these horizons were still quite long-term compared to today\u2019s tech startups.<\/p>\n\n\n\n

But still \u2013 horizon roadmaps changed the conversation completely.<\/p>\n\n\n\n

By letting go of fixed dates and embracing the inherent uncertainty of product work, we opened up new discussions. We could debate whether our ideas<\/a> were actually the right things to do, instead of planning on when <\/em>to deliver what<\/em>. This gave us more flexibility to pivot or modify the roadmap, according to our current strategy.<\/p>\n\n\n\n

Other benefits after breaking up with deadlines:<\/p>\n\n\n\n