“I have been impressed with the urgency of doing. Knowing is not enough. We must apply. Being willing is not enough. We must do.” — Leonardo da Vinci
In Ten Commandments of Product Development, urgency does not mean haste. It does not mean long hours, panic, or a culture of constant firefighting. It means maintaining disciplined forward motion by confronting the hardest problems while time, resources, and options are still on your side.
Why Easy Wins Can Mislead You
One of the most common traps in product development is to begin with simple, familiar tasks. It feels productive. It creates visible progress for stakeholders, and it feels safe. Fear of the unknown reinforces the habit. Teams naturally gravitate towards work they already understand and know how to execute.
But that sense of progress can be dangerously misleading. When you defer difficult technical challenges until late in the project, you are not managing risk; you are gambling with the outcome. Those challenges may involve a new circuit topology, an unfamiliar material, or a complex software construct. By the time problems begin to surface, your schedule is tight, your resources are depleted, and your options are limited. The result is predictable: overruns, quality compromises. This is called the “Student Syndrome”—the habit of leaving the hardest work until the submission deadline is staring you in the face.
The Commandment in Practice: Do the Difficult Things First
Every new product contains unknowns. The practical implication of this commandment is simple: confront them early. When you resolve the hardest uncertainties first, you create space for a lot of simpler, more predictable work later. Teams may still need a final push near the end of a project, but that effort should go into polishing the product—not rescuing it from critical technical surprises.
In practice, you may need to balance resources between difficult and easier tasks. The right allocation depends on the experience, competence, and problem-solving ability of the team. Some early progress on simpler work can help maintain momentum and morale. But it is unwise to commit all your resources to easy tasks while postponing the difficult ones that will ultimately determine whether the project succeeds.
What Maintaining Urgency Looks Like in Practice
To maintain real urgency, you must front-load effort. The strongest projects reduce technical risk early rather than carrying it quietly into later phases. A sound product development effort should be structured using a Phase Gate approach. Within that structure, the Concept Phase is where this commandment is either honored or ignored.
Figure 1 shows three common project trajectories—and why only one of them consistently leads to predictable outcomes.
Steady Progress: The middle line, represents steady progress—a fixed amount of work completed per unit of time. That is rarely the reality in product development, although it may describe some manufacturing environments or highly standardized projects, such as road construction over normal terrain.
The Student Syndrome: The lower curve shows a team spending the early part of the project on simple tasks, hoping to make up time later by solving the difficult problems under pressure. In product development, this pattern rarely ends well. It leaves little chance of finishing on time, and even less chance of finishing with the required level of quality.
Front-Loaded Development: The best trajectory for a product development project is the third one: tackle the difficult issues in the opening phase—ideally within the first 20% of the planned schedule. During this period, it is critical to assign highly capable team members who can surface technical risks early and judge whether the proposed approach can meet the required quality level in a predictable way. In practical terms, this means:
Aim for 80% Certainty in 20% Time: Use the Concept Phase to tackle your most significant “known unknowns”—new architectures, material challenges, or complex software constructs.
Validate with an MVP: Do not wait until the end to find out whether the product actually works. Build a Minimum Viable Product early—one that embodies the most critical and riskiest features. Getting this MVP into the hands of users allows you to validate assumptions while you still have roughly 80% of your resources available to pivot.
A common—and dangerous—mistake is to equate MVPs with HMI or UI demos. Critical features are rarely cosmetic. In most products, real risk lives beneath the surface: hardware choices, system architecture, firmware and software algorithms, performance limits, reliability, and integration.
An MVP that demonstrates only screens or dummy hardware may look impressive, but it does not establish product viability. Worse, it creates false confidence—inside the team and with customers. Stakeholders may assume the product is nearly finished and expect rapid delivery, when the hardest problems have not yet been solved.
Maintaining urgency means using the MVP to expose uncertainty early—not to hide it behind polish.
Assign Your Best: The first 20% of a project is the most intellectually demanding. Assign your most experienced team members to the initial phases. They are the ones who can look around the corner and identify the risks that will derail the project months later.
The remaining 80% of the schedule can then be used to complete the broader set of requirements—work that should be far less likely to produce fundamental surprises. With this approach, the team gives itself a much better chance of finishing predictably, without last-minute drama.
Build Urgency into the Plan
Product development projects consist of many interdependent tasks, and those tasks often compete for limited resources. That is exactly why urgency must be designed into the plan rather than left to personal heroics later.
In many cases, project planning is built on a network of tasks organized into chains and sub-chains that show the dependencies between them. The overall project timeline is then estimated from the duration of individual tasks and the relationships among them.
You cannot maintain urgency without a rigorous planning framework. Whether you use Critical Chain Project Management (CCPM) or another methodology, the goal is the same: create a predictable flow of work that protects the critical path from the inevitable delays of “Murphy’s Law.”
I have found that frameworks like CCPM, based on Theory of Constraints developed by Dr. Eliyahu Goldratt help teams focus on the true constraint of the project rather than getting lost in the noise of individual task estimates. Whatever methodology you choose, the real test is whether the team understands it and accepts it. When the team sees planning buffers as tools for predictability—not as hidden slack—it is far more likely to sustain a focused, professional sense of urgency.
Key Takeaways
- Front-load the hard work: If a task is difficult, tackle it early.
- Do not mistake activity for progress: Finishing easy tasks does not reduce late-stage technical risk.
- Use the Concept Phase to kill risk: Do not be satisfied with just documenting the proposed solution. Do it.
- Urgency is strategic: It is about resolving unknowns early so the rest of the project can be executed with confidence and predictability.
In the next post in this series, I will cover Commandment 4: Collaborate and Ask for Help. If this commandment is about attacking the hardest problems early, the next one is about making sure you do not try to solve them alone. Product development is a team sport, and success depends on transparency, shared problem-solving, and collaboration across organizational boundaries.
I would love to hear how your teams handle urgency, technical risk, and early MVP validation.
“How does a project get to be a year late? One day at a time.”
—Frederick P. Brooks Jr., The Mythical Man-Month