As Godin points out, marketing programs are key to developing the customer base and that often takes time. You need feedback loops from your customers to prioritize features and evolve your product. Businesses shouldn’t launch a product until it has the required features needed for success.  And what is ultimately the ‘minimal viable product’ should be a business decision, not a programming or technology decision.

It’s time for Product Camp Austin, Spring 2010. If you’re a local product professional and haven’t been, you need to go. A great community resource, it is a great opportunity to get involved as well as network. Find out more Here

Here are excerpts from this article that discusses two types of technical debt

“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.)”

Here is a quote from Getting to Plan B, “The research on new product success and failure indicates that it takes fifty-eight new product ideas to deliver a single successful new product.” I’m reading this book from by John Mullins and Randy Komisar and find it interesting so far. The fundamental premise of the book is that businesses do not succeed with their original business model but rather an iteration of the original. This parallels the recent trends/fads in lean business/product/software.

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.

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