Better Project Management: Discovering What Can Go Wrong So You Can Get it Right

If there’s one certainty in software product development, it’s that projects will almost certainly take longer — and involve more roadblocks — than you plan for. Hut 8 Labs co-founder Dan Milstein explains why product owners must be able to translate the business case of each project and uncover unknown challenges before they become disasters.

Let’s say you’re a developer at a high-growth software company that has just accepted a round of funding and is preparing to build out new features for a particular target market. One day, the CEO and CTO call you into a meeting, present a handful of new functionality they want built into the product, and then drop the hammer — all of that functionality must be ready to go live in six weeks.
Naturally, you panic. The new features sound valuable, but the specs are vague and it isn’t very clear who will be using them. Even worse, the deadline doesn’t sound realistic, particularly when you factor in that software development almost always involves the unpredictable.
So, what do you do?
According to Dan Milstein, a former Principal Engineer at HubSpot and now the co-founder of software development consulting group Hut 8 Labs, the best thing to do is take a step back and re-frame the project’s purpose.
“If the project focuses on vague specs and unrealistic deadlines, then the most likely outcome is that it blows up in your face,” Milstein explains. “You have to remember that there’s always a chance for software to explode in a surprising way. You have to factor in the unknown — and that’s not something many leaders consider with big software projects.”

A Better Approach to Managing Software Development: “Prove Me Wrong”

In order to best manage the unknown, Milstein suggests leaders take a unique approach to product development projects.

“Instead of saying, ‘Here is the project and this is when I want it done,’ you could say, ‘Here is the business objective I’d like to accomplish — I want you (the technical team) to aggressively search for anything that might put that outcome at risk.’” — Dan Milstein, Co-founder and Principle at Hut 8 Labs

“I recommend an approach that allows the product developers to proactively search for impediments or potential issues that you might not have considered,” Milstein explains. “If the plan survives a ‘prove me wrong’ process, then it’s probably a good plan. If it doesn’t, then everyone should work together toward a new one.”
Granted, Milstein admits that it will take some time for developers to trust that you actually want to hear potentially bad news, but you have to stick to that. Doing so also requires company leadership to place a lot of trust in its engineers — a step that some managers aren’t willing to take.
In fact, at some levels, Milstein says he’s even seen leaders take pride in not trusting engineers.

“Their thought process is that engineers or developers will always overestimate the time they think it will take to complete a project, and they can always find a reason to say ‘No’ to a project,” Milstein says. “To combat that, some businesses create a middle management layer of ‘yes men’ whose sole job is to ensure that projects stay on their original schedules — often at the expense of the details.”
Typically, that leads to teams overlooking small details, which can also result in ignoring bigger issues — like burying bad news until it’s too late to pick a new path. Combined, that can very quickly lead to a project imploding.

The Best Project Managers Can Translate Between Executives and Developers

“One of the biggest challenges of creating this line of communication is that the business folks and the technical team aren’t speaking the same language,” Milstein says. “Developers talk about complex technical issues without any connection to things the business people can understand. And, correspondingly, business people don’t spend proper time making sure developers really understand why they’re doing something. Generally, that results in crappy choices about how or why to proceed.”
For product development to be successful, Milstein says companies must implement a system where changes to the reality of a situation — unknowns, impediments, or project issues — make their way swiftly to the executive suite.
Importantly, this doesn’t mean informing executives about every little detail of why something can’t or won’t work. Instead, the idea is to communicate this information in a way that executives understand it.
In Milstein’s experience, the best way to do that is to put a product owner between the executives and the developers who can speak both languages, understand the broader context of a particular goal or project, identify potential challenges, and interpret what needs to get done.
“The emphasis is really on having a person who can be the middle man without being a ‘yes man,’” Milstein explains. “You want someone who can sit down with a project request, absorb the information, uncover the potential problems that need to be addressed by asking good questions, and then work with the technical team to make smart, contextual decisions in a timely manner. This helps reframe the discussion from ‘We need you to build X by Y date,’ to ‘We need you to gather information about whether building X makes sense.’”
Not only does that result in greater clarity and a sense of ownership from the developers’ side, it also allows executives to make more confident decisions and informed commitments.
“For a project to be successful,” Milstein says, “you have to understand the purpose and the risks first. Only then can you accurately translate that into a realistic output and a realistic time frame.”

Agile Development in Executives’ Language

Give management a quick, no-nonsense guide to Scrum that emphasizes what makes it so beneficial to them. Download our free guide:


Photo by: Mike Traboe