Prototypes and Deadlines for Software Teams
A prototype is worth a thousand words. A goal without a deadline is just a wish.
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 often driven by the numerous other priorities that already exist, the fear of the unknown, and the risk of investing significant time in initiatives that may not ultimately deliver a return on investment. All companies experience this the same way just with more or less 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 if they're “soft” most of the time, they establish a boundary that keeps the team focused and provides a rough timeframe for completion. They’re not intended to punish anyone; rather, they serve as a valuable tool for alignment, decision-making, and prioritization. While deadlines may shift, not having them at all makes it significantly more difficult to plan and move forward effectively.
From my perspective, with any software project, you have four possible scenarios – choose one.
- Fixed Scope, Fixed Deadline
- Fixed Scope, Flexible Deadline
- Flexible Scope, Fixed Deadline
- Flexible Scope, Flexible Deadline
From my experience, the third option strikes the best balance for everyone. It allows the scope to evolve based on new insights while still maintaining clear boundaries. Options one and two can be challenging for engineering teams because project scope often shifts as they learn more. Meanwhile, option four is usually less desirable for product teams and leadership, as proceeding without a clear timeline introduces significant risk to budgeting and roadmap predictability. Even if you miss, you likely end up close to the original timeline.
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.
One strong recommendation I always have for any project is to develop a prototype as early as possible. If you have the conviction and the ability, make the time to build it yourself - create a draft PR to get feedback from the team, or create another repository to show a demo outside of your current codebase. We are all busy, but doing so will move the needle. If you don't have the ability, bring in someone to help champion the project as early as possible. A person who shares your vision and can help you drive the project forward.
This tangible prototype of the product can address the multitude of questions that often lead to analysis paralysis. It also helps overcome the “chicken or egg” dilemma by showing the team what the product could look like. Some stakeholders will care more about the details than others, and this approach will calm their fears of beginning the project in the first place. I've also seen it bring excitement projects. Presenting something real encourages the team to move forward and builds the momentum needed for success.