“The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job. In some cases, this kind of debt can be incurred unknowingly, for example, your company might acquire a company that has accumulated significant technical debt that you don’t identify until after the acquisition. Sometimes, ironically, this debt can be created when a team stumbles in its efforts to rewrite a debt-laden platform and inadvertently creates more debt. We’ll call this general category of debt Type I.

The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future. “If we don’t get this release done on time, there won’t be a next release” is a common refrain—and often a compelling one. This leads to decisions like, “We don’t have time to reconcile these two databases, so we’ll write some glue code that keeps them synchronized for now and reconcile them after we ship.” Or “We have some code written by a contractor that doesn’t follow our coding standards; we’ll clean that up later.” Or “We didn’t have time to write all the unit tests for the code we wrote the last 2 months of the project. We’ll right those tests after the release.” (We’ll call this Type II.)”

While a Lean Product Development, evangelized by Eric Ries and Steve Blank, appears to be the latest business fad it has several key concepts that apply to any business. The Minimal Viable Product and Steve Blank’s Customer Development concepts are really common sense elements that many organization’s, large and small, ignore. Definitely check it out.

We use the web in almost all aspects of our lives today. In fact I can’t remember when the last time I needed driving directions and didn’t turn to a browser. This ubiquity gives everyone a frame of reference to suggest ‘How’ something should be instead of defining the problem. You’ll know your in a ‘How-Wow’ party when the ideas and examples are flowing but you don’t have a solid problem statement. And while brainstorms are great it can be distracting and take you off target.

Keep things on target by grounding your team in problem statements and measures. Saying, “Let’s focus on the what not the how” and using open ended statements such as “This program will be successful when…” can be helpful. When all else fails ask for discrete numbers. Nothing is as sobering as numbers, especially these days.

Make it the present tense and that’s what we do daily.

10 Books To Make You A Better Product Manager

Berkun Top ten reasons managers become great

The Unintended Consequences of Startups

Why Iteration is a Powerful Way to Build a Startup

Calculating Customer Lifetime Value – the Quick and Dirty Method

What school of thought does your organization follow?