Build a better product by spending less time planning.

I’m a morning person. I enjoy rising early to plan my day and anticipate what I’ll accomplish. This routine provides clarity of thought and a hunger to act. It challenges me to be alert, prepared, and persistent toward the day’s priorities. Ultimately, it provides an energy and momentum that nourishes me throughout the day, and that—through my action—helps to nourish my team and the software projects we’re responsible for.

Indeed, I’m happy to be a morning person, except on the first Thursday of each month. On these miserable mornings, waking up is a chore. On these mornings, I feel helpless to intercede in the unfortunate events that will invariably unfold in the hours to come. On these mornings, I’m not happy.

On these particular mornings, the mornings before our monthly 8-hour strategic planning meetings, the sun always rises too soon. To me, a 30-something middle-class software guy, it may be the closest I’ll ever feel to walking the Green Mile. Alas, with my force of will, I clamber out of bed and steel myself for the ritualistic dance that is to come.

Upon arrival at the office, I start my usual routine. I make a cup of Lipton Black Tea, the kind you get for free in the lobby of a Motel 6, and I start to take a mental roll call. The usual product owners are there as well as the heads of each development team. An executive often drops by for a bit as well. All in all, I count 17 people on this day.

That’s when I did the math: 17 people, for 8 hours, at an average bill rate of $150/hr equals $20,400. Twenty-thousand, four-hundred dollars. For one meeting. For the majority of folks in attendance, this price is fair, even a bargain, because they believe in the myth that projects should be scoped entirely up front. But for those folks like me in the room, we see the truth: it’s burning money.

I don’t care who you are; that’s a lot of money. I lived on less than that my first year as a software entrepreneur. My company and I have launched successful startup products for less than half of that sum. I spent less than that on my first 3 cars, combined. Seriously, do you know how much software you can build for $20,400?

To my dismay, almost every corporate project we work on starts out with a rigorous planning session like this—always at the client’s behest. I attempt to persuade "the suits" to at least try our approach, which is leaner, user-focused, and biased toward creating functional software as the measure of learning. My efforts are almost always in vain despite the proven track record we have using it. Instead, these middle managers prefer to gather together to conceptualize and document every nook and cranny of the project, chasing every rabbit down their proverbial holes, in the misguided belief that product teams benefit from copiously detailed specifications. Optimistically, their teams attempt to build the product as specified. Inevitably, chaos ensues. But that happens later.

Over the course of the laborious, and somewhat tortuous afternoon, the neat and tidy conference room transforms into the likes of a writing room for The Tonight Show. Notes scrawled on sticky pads adhere to every stationary surface. Attendees gather around whiteboards covered in sketches of wireframes. One by one, participants trade time at the projector, each pitching his or her own wants and needs, which until this point, were held in private. Minute by minute, the planning continues, the line between clarity and confusion increasingly blurring all the while.

Let me be clear; planning is important work. Product creation is a collaborative task, and collaboration requires orchestration. Budgets are at play. Timelines need to be considered. Dependencies must be identified. Done well, planning creates cohesion that gives us the confidence to move forward. But how much planning is too much? And in what form should planning manifest when initiating a software project with so many unknowns?

Trying to control or solve for all the unknowns up front is a fool’s errand regardless of how thoroughly we plan. There will always be gaps in understanding that emerge later that need to be filled. It’s too easy to miss a use case or to underestimate what needs to happen without proper field research. This reality is exacerbated when users create new, valid gaps when they give feedback on early releases. Thus, trying to fill all the gaps at the outset is a fruitless exercise as it is equivalent to guessing and wishful thinking. And in the software world, guesses and wishes are ruinous indulgences clients and their end users can ill afford.

Alternatively, if we consider how gaps are filled when they are missed, we can strategically leave them open during our planning. This fundamental shift in thinking is at the core of our unique approach to product development. Unlike the torturous meetings I find myself in every first Thursday of the month, our model begins with a mission statement for the project. This mission is devoid of features or specifications. It's stated in the language of our users accomplishments:

When successful, our users will be unshackled from their desk. They will be free to walk the campus without fear of missing an alert of life threatening importance.

This mission, at 30,000 feet, is dramatically different from the same user story hovering near the ground:

As a user, I receive an SMS message within 15 seconds of the Nuclear Meltdown Alarm (NMA) metric exceeding the 75% threshold, which says "URGENT: Armageddon may be near. Man your post."

In this latter example, it's likely that the product owner who wrote this is not entirely clued into the specifics of this metric. Perhaps it's common for the meltdown metric to spike during periods of routine maintenance. If this scenario is ignored, much panic would be induced. Plus, SMS is surely not as appropriate of an alert as an audible alarm across the campus. Any decent designer would catch this. If, for the purposes of strategic planning, we stay focused only on the value at 30,000 feet, the developers and designers can contribute more effectively in their roles.

Our team is constantly addressing previously neglected interface designs. This common practice perfectly illustrates the benefits of our model. For example, if the project manager inadvertently neglects to wireframe screens for a particular feature, it leaves a gap that will be identified and filled by a designer later on. The designer is absolutely more qualified than the project manager for this task. Thus, neglecting this wireframe early on in the planning process will actually produce a better outcome downstream as the product comes into final form. The designer is surely faster at this task as well, so in addition to producing a higher quality design, the team will be more financially responsible.

To this end—the complete final form of a product aligned to the end user’s expectations—the product team planning the project should be conscious of what they should be defining, and what they should leave open for others to define. Some items must be planned ahead of time, but the planning of other items will be more effectively deferred to a later course of the project itself.

The key in all of this is to empower development teams to find and fill gaps as projects unfold. As a product owner, it’s okay to leave those gaps open for your team to fill. Not only will that course of action promote a more aligned result with the true need of the user, it will also galvanize more unity and energy within the team. Allowing gaps to remain open will feel unnatural at first, though I promise it promotes a more valuable end product. After enough exposure to this way of working, maybe we can all get to a place where the dreaded daylong meetings fade into memory. And maybe then, we can all wake up enthusiastically on the first Thursday of the month to get to the business at hand: making good software that works.