Constraints have a great way of bringing focus to work. They have also been shown to have an effect on creativity. Having unlimited options and possibilities, in fact, makes it harder for us to make decisions (decision fatigue). When we create a product plan, we are dealing with a number of options and have many decisions to take. These can range from something as high level as what feature to build, to something as finely detailed as where to place the purchase button.

When faced with so many decisions, and many of them being in the speculative zone, setting up a constraint can help to bring focus. Time is a clear, tangible constraint that has an intense effect on our psyche. Time lost cannot be recovered, but our tendency is to keep extending time. If we're not ready, then we say, "Let's give it another day." If we find something new and cool, then we say, "Let's take time to explore and retrofit to our product." So, we grant ourselves the liberty to bring in last-minute changes. We let ourselves obsess over details, which may not be critical to the product.

If there is one discipline that we should incorporate into our product cycle, then it is to keep time (deadlines) as a non-negotiable aspect. This is probably raising the eyebrows of folks who would rightly argue that it will lead to overworking, 24/7 schedules, and a lack of time for personal life. However, that's where the fine line comes between someone dictating a deadline and a team finding a timeline based on desired outcomes. In some cases, when demanded by the market, release dates may not even be in our control. We have to launch when we have to launch. For instance, if you're selling diyas (lights) for Diwali, then you can't wait until Christmas to make your diyas. So, we must take into account either market priorities (launching ahead of a competitor or in time for the festival season) or internal consensus to set a date (we will launch on October 7th, one week before Diwali), or a schedule (we will release updates every Tuesday or we will release them every day). We need to strive to meet outcome-driven timelines.

Now, we must make every decision with the intent to meet the outcome-driven timeline. Any obsession about details that will make us miss the deadline is not worth it. Any last-minute changes that will delay our launch must be rationalized and justified, backed with data, and have a compelling reason. Otherwise, we go with what was agreed upon. There is much more to learn from how the customer adopts our product than we will ever learn from our own opinions of what's the best product to build. So, getting the product out of the door should be our intent. Setting time-bound outcome goals will create that focus, and discipline, for us.

In the classic iron triangle of scope, budget, and time, when time is fixed, there is limited flexibility to increase scope or budget. Since budget is already spent, and because of Brooks' law ("Adding human resources to a late software project makes it later"), any tweaking on budget is out of the question:

So that leaves scope. When forced by the constraints of meeting a non-negotiable date, scope prioritization becomes very creative. We critically evaluate every change request, and every functional aspect. It becomes much easier to identify things that need to go into a product by that launch date, things which can be pushed to later, and things we shouldn't even be building. Question every change in scope by asking, "Is adding this scope worth missing the deadline?"

Let me recall an incident narrated by a friend on her experience with time-bound goals. Her team was gearing up to build an online e-commerce platform for niche handicrafts made by women who ran small home businesses. Right from the start, they had tried to match up with every functionality that platforms such as Magento, WooCommerce, or Shopify offered. There had been a lack of focus due to many competing priorities, since they wanted to build everything under the sun. The team continued to build without focus, until there was a sudden deadline imposed due to pressure from investors. They had to go live in two weeks.

With two weeks to go, the product lead threw up his arms in despair. Many functional flows were incomplete. No one had tested anything. Panic set in! The first instinct was for everyone to request that they move the launch date because we were not ready. Yet the investors did not relent and the team was forced to evaluate how they could meet the deadline. The net result was that the team mercilessly cut down scope, looked at the key outcomes that the investors were looking for, and identified the critical functionality that could best meet those outcomes within the time constraints.

Having unlimited time wasn't really helping the team. Even though a two-week timeline may not have been the optimal time needed to carve out the Impact Driven product, the point is that a constraint like that forces teams to evaluate and redirect all their resources to meeting an outcome, under the given constraints. The constraint of time is great antidote for teams that strive for perfection.