post

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Successful product management in companies where it’s least understood

Measuring critical user journeys – Javier Andrés Bargas-Avila (UX Director, Google)

A new way to look at applied experiments

Product survey findings: Only 15% of users are embracing AI features 

Building high-performing product teams: The PDLC approach

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Overcoming the 20% feature usage challenge

Product Management

Three product leaders to learn from at #mtpcon inside Pendomonium

Product Manager at <a href="https://creativemarket.com">Creative Market</a>, photographer, designer, and <a href="https://twitter.com/secondfret">guy who tweets</a>.

Josh Johnson

<p>We’ve all been there: two months into a two-week project and the end still isn’t anywhere in sight. Sometimes a good project goes bad, you learn your lesson, and move on. But sometimes the issue is deeper than that, and it’s not a one-off fluke, but an institutional issue that keeps repeating itself. It’s so frustrating to see teams at other companies pull off seemingly unbelievable feats where nothing goes wrong in magical two-week sprints. Why can’t your team do that?</p>
<h2>The Blame Game</h2>
<p>You start by blaming the people on the front line. This developer never takes deadlines seriously, that designer is constantly late, maybe it’s time for some changes. You hire some talent, you let a few people go, everything is going to be better, right?</p>
<p>But the problems still persist. What gives?</p>
<h3>It’s not you, it’s me</h3>
<p>As much as we’d all like to point the finger elsewhere, chronic deadline issues are often the result of poor management, not poor execution (it’s easy to spot the latter and totally miss that it’s caused by the former). If you find yourself in this situation, you need to examine the culture and framework of your project teams.</p>
<h2>Why it’s so Hard to Change Deadline Culture</h2>
<p>If your culture isn’t already deadline-focused, then it’s extremely difficult to suddenly make shipping quickly a priority that everyone works towards.</p>
<p>You can probably relate to a few of these hurdles:</p>
<ol>
<li>It’s trendy at the moment to have a chill corporate culture. Many managers want to be the antithesis of the hard-ass boss who constantly pushes everyone to work harder and faster.</li>
<li>Setting deadlines is hard. Will that new feature take three hours or three weeks to code? As a product manager, it’s often difficult to tell.</li>
<li>People hate providing time estimates for their work. Ask a team member how long it will take to build something and they’ll talk for 10 minutes solid and never mention a real timeline. Dig deeper and ask for a ballpark figure and that’s what you get, a random number and a shrug. Feature-rich product work is tricky to quote, especially when you have an existing code base that never fails to offer up surprises as you dig into it. Even the best talent will struggle with this.</li>
<li>Deadlines are difficult to enforce. Should you punish people for missing deadlines?</li>
<li>Your team will push back and say that great product work takes time. There are often trade-offs between speed and quality, but this shouldn’t be a get-out-of-jail-free card for every missed deadline.</li>
</ol>
<p>Overcoming these hurdles is difficult, but not impossible. Let’s explore some steps you can take to tackle your deadline culture issues.</p>
<h2>Decide On a Timeline Before Choosing a Solution</h2>
<p>If you’re in a culture with runaway project timelines, you may be thinking about project scoping all wrong.</p>
<p>Here’s how far too many people scope a project:</p>
<ol>
<li>Identify a problem</li>
<li>Figure out the best solution</li>
<li>Guess how long it’ll take to implement that solution</li>
</ol>
<p>This seems to make sense, but it leaves out a critical variable: the value of solving the problem. You could be working on a project that affects a small percentage of users, but you dream up a solution that will take months to implement. Is the solution really worth that much time and effort?</p>
<p>Try this instead:</p>
<ol>
<li>Identify a problem</li>
<li>Figure out the value of solving that problem</li>
<li>Decide how much of your team’s time and resources you can justify dedicating to that problem</li>
<li>Explore solutions that you can pull off in the time allotted to solving the project</li>
</ol>
<p>Using this model, you can more easily scope out solutions that are appropriate. It’s tempting to chase every single problem with the best possible solution, but the simple truth is that some problems only merit a one-week fix.</p>
<p>This process works perfectly with project sprints. Identify a problem, then ask: “How many two-week sprints can we justify dedicating to solving this?” From there, you can scope out a solution that fits your timeline.</p>
<p>Try using an impact vs. effort matrix to compare your project ideas and make sure you’re focusing on the right things.<i> </i></p>
<h2>Stop Juggling too Many Projects</h2>
<p>Do you give your team dedicated, heads-down time on projects? Or are you constantly pulling team members off of one thing to put them on something that’s suddenly more urgent? If you find yourself assigning “out of the blue and suddenly due” tasks regularly, then you can stop looking elsewhere for your deadline issues, they’re your fault.</p>
<p>Multitasking is an enticing strategy for product managers. Why work on one project at a time when you can queue up three? Unfortunately, this often leads to messy, half-baked projects with extended timelines and questionable results.</p>
<h3>Context Switching is a Very Real Threat</h3>
<p>Product work is cerebral. Whether you’re writing up project specs, working on a comp in Photoshop, or writing code, you have to get into the right headspace. If you pull your team members out for constant meetings and fires that need to put out, this can totally destroy their productivity. Even if the interruption is quick, it’s not easy just to jump back in.</p>
<p>This is well-trodden territory with lots of great articles and research:</p>
<ol>
<li><a href="https://www.linkedin.com/pulse/context-switching-developers-paul-graham">How Context Switching destroys Developers Productivity and how to fix it</a></li>
<li><a href="https://insights.sei.cmu.edu/devops/2015/03/addressing-the-detrimental-effects-of-context-switching-with-devops.html">Addressing the Detrimental Effects of Context Switching with DevOps</a></li>
<li><a href="https://www.petrikainulainen.net/software-development/processes/the-cost-of-context-switching/">The Cost of Context Switching</a></li>
</ol>
<p>The tricky part for product managers is breaking the habit. It’s one thing to acknowledge that context-switching isn’t great, but another to commit to implementing organisational changes that reduce its occurrence. Until you have a bulletproof plan for how to deal with these situations without messing up existing project resources and timelines, you’ll never stop falling into the multitasking trap.</p>
<h2>More Responsibility, not Less</h2>
<p>If the people on your team constantly miss deadlines, a natural assumption might be that they’re irresponsible. So you dig in. You put them on probation, micro-manage their every move, and reprimand every mistake.</p>
<p>Of course when you treat people like they can’t be responsible, it becomes a self-fulfilling prophecy. Try this instead: give them more responsibility. Let them share your burden of leadership and see how it affects your deadlines. This starts with scoping.</p>
<h3>Everyone Scopes</h3>
<p>When I first started as a product manager, I thought it was my job fully to scope out projects, so that’s what I did. I’d plan out every little piece of the project, then hand it off to be built. I found out pretty quickly that this didn’t work well. The result was always the same: UX holes that I didn’t spot, technical hurdles that I couldn’t have foreseen (leading to extended timelines), and low job satisfaction from team members who felt like they had a lot more to offer.</p>
<p>The people building a given project often hadn’t even heard anything about it until a finished scope popped up in a task assigned to them. Is it any wonder that deadlines were being missed? Why should teams to feel ownership over project timelines when they have no ownership of the projects?</p>
<p>The simple answer was to stop doing everything myself. I now lead a cross-functional team where everyone is involved in every step of the project. I guide the process but I rely on the expertise of everyone on the team to decide up front how the project will be structured.</p>
<p>Under this model, I’ve seen commitments to deadlines drastically increase. When we all share a vision for a project and we all set goals for completing it, we all work much harder to make it happen.</p>
<h3>Delegating Means Trusting</h3>
<p>This doesn’t stop at scoping, it affects everything you do. The more I learn to delegate and trust my team members with critical tasks, the more they rise to the challenge.</p>
<p>This all hinges on trust. The primary excuse I hear managers giving for not delegating is a lack of trust: “I just can’t trust anyone else to do it right!” I think too many product managers imagine themselves to be the only people in the organisation capable of doing anything correctly. In reality they’re failing to set up and empower their teams for success.</p>
<h2>Publicly Commit to Deadlines</h2>
<p>When deadlines are missed across the organisation, they can be tricky to start enforcing. You can’t simply fire everyone. The best incentive I’ve found for this is simple: public commitment. If project teams are failing in private, there’s little reason to improve.</p>
<p>“Publicly” committing to deadlines means both with each other (in the core project team) and with everyone else.</p>
<h3>Daily Standups With Your Core Project Team</h3>
<p>Just about everyone does standups, and everyone I’ve found uses a variation of the same three questions:</p>
<ul>
<li>What did you do yesterday?</li>
<li>What will you do today?</li>
<li>Is anything blocking your progress?</li>
</ul>
<p>I found that these were a good start, but they’re sorely lacking communication on deadlines. This opens the door for team members not only to miss deadlines but also complain that they were never aware of them in the first place.</p>
<p>Worse, I found that team members often knew very early in the week that they weren’t going to make a given deadline, but failed to communicate that to the team.</p>
<p>To address this, I added two questions to our daily standups:</p>
<ul>
<li>What deadlines are you working against?</li>
<li>How confident are you that you’re going to meet those deadlines?</li>
</ul>
<p>Every single day, everyone on my team (including me) has to acknowledge publicly the deadlines they’re working towards and whether or not they think they’re going to hit them. If anyone says that they don’t have a deadline, that’s a call out to me that I need to fix that, and I work with them to set one up right away.</p>
<p>In terms of having a huge impact with a tiny effort, you can’t beat this in my experience. I highly recommend that you add these questions to your daily standups. It will quickly start to change your team’s attitudes towards deadlines.</p>
<h3>In Larger Team Meetings</h3>
<p>If you have a weekly or monthly meeting with your organisation or sub-group, make sure you mention all of these:</p>
<ol>
<li>The projects your team is working on</li>
<li>The deadlines you’ve set as a team for those projects</li>
<li>Whether or not you met the deadlines you talked about in your previous meeting</li>
</ol>
<p>This puts both you and your team on the spot. No one wants to go back next week and tell everyone they dropped the ball, and everyone loves reporting on their successes. Do both with your team and you’ll start to see people working harder and pulling together to keep their commitments.</p>
<p>When your team works hard and does the impossible, call them out in front of everyone, specifically and by name when possible. When a project slips, absorb the impact and use the word “we” a lot. “We didn’t hit our goal of launching last week, but we’re digging in and doubling our efforts to make sure we launch before the end of the month.”</p>
<h2>Keep Your Eyes on the Prize</h2>
<p>Remember that you’re not pursuing deadlines just for the sake of checking a box, remind yourself and your team what you’re working towards. Whether your team is motivated by competitive pressure, pushing out a new feature before a big event or demo, or making a positive impact in the lives of your users, working both quickly and efficiently helps you to meet those goals.</p>
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

How to fix Runaway Project Timelines

Josh Johnson

Comments

Read next