Prototypes and Deadlines for Software Teams

Resource fallacy

Regardless of a company’s size, whether a global enterprise or a small startup, resources are always limited. Even Fortune 50 companies with hundreds of engineers and product managers often lack the capacity to take on new projects. This scarcity is usually driven by competing priorities, fear of the unknown, and the risk of investing significant time in initiatives that may not ultimately deliver a return on investment. Every company experiences this reality, just with varying levels of people and process.

Boundaries

When it's time to prioritize a new project, many feelings can arise across the teams involved.

Anxiety - The unknown of what can happen can be stressful.
Fear - Based on past experiences, the team may have scars that can be triggered.
Excitement - It could be a product that the team has been asking for over months or even years, or a new technology that may drive a lot of value.

From my perspective, deadlines are extremely helpful. Even when they are “soft,” they create boundaries that keep teams focused and provide a rough timeframe for completion. Deadlines are not meant to punish anyone. They are tools for alignment, decision-making, and prioritization. While dates may shift, the absence of deadlines makes planning and forward progress far more difficult.

Choosing Constraints

With any software project, there are four possible constraint models. You must choose one.

Fixed Scope, Fixed Deadline
Fixed Scope, Flexible Deadline
Flexible Scope, Fixed Deadline
Flexible Scope, Flexible Deadline

In my experience, the third option offers the best balance. It allows scope to evolve as new information emerges while still maintaining clear boundaries. Even when teams miss the target, they usually land close to the original timeline.

The first and second options are often difficult for engineering teams because scope almost always changes as understanding deepens. The fourth option is typically the least desirable for product teams and leadership, since operating without a timeline introduces significant risk to budgeting and roadmap predictability.

Friction between teams often occurs when you are trying to set a date on a project that is yet to be defined enough for comfort levels. Therefore, you should focus on the necessary questions that need to be answered in order to get to a reasonable timeline–of course not all questions can be answered. This is really about understanding what success looks like for stakeholders and customers. If there is misalignment at the start, there will be misalignment at the finish. Don't let this happen.

Prototypes Create Momentum

One recommendation I consistently make is to build a prototype as early as possible. If you have the conviction and the ability, carve out the time to do it yourself. Create a draft pull request to gather feedback, or spin up a separate repository to demo the idea outside the existing codebase. Everyone is busy, but this effort moves the project forward in a meaningful way.

A tangible prototype answers many of the questions that often lead to analysis paralysis. It helps resolve the classic chicken-and-egg problem by making the idea concrete. Some stakeholders care deeply about details, while others care more about direction, and a prototype speaks to both. It reduces fear, builds excitement, and gives the team something real to rally around. Presenting something tangible creates momentum, and momentum is often the difference between a stalled idea and a successful project.