From Scott Ambler:

One of the great debates raging within the IT industry is whether or not agile software development techniques work.  My experience, and the experience of thousands of others, is that they do.  One of several reasons why agile techniques are so effective, in my opinion, is that they reduce the feedback cycle between the generation of an idea (perhaps a requirement or a design strategy) and the realization of that idea.  This not only minimizes the risk of misunderstanding, it also reduces the cost of addressing any mistakes.  In this article I explore this idea in detail. 

Good information architecture article by Donna Maurer.

Donna characterizes information seeking as happening in one of four modes (from the perspective of the seeker)

1. Known-item
2. Exploratory
3. Don't know what you need to know
4. Re-finding 

Article compares different approaches to testing the workflow of an application - specifically a web application.  Detailed analysis of the maintenance & skill level tradeoffs for each approach.  Also touches on Selenium and Watir approaches.

When you define a product roadmap, you also define the release dates for your product. Change happens. Your market changes, your customers change, your requirements change. Unpredictable events happen. Your competitors release a new killer feature, your developers have an epiphany (or run into a roadblock). Should you change your release schedule?

Deep analysis of the tasks that must happen in an iteration - development, analysis, testing, etc.  Focus on the problems with staggering them too much, and suggestions on how to properly organize the team around those tasks.

Peter Morville on information architecture and the user-experience honeycomb

I've been practicing information architecture since 1994, and from Gopher to Google have seen dramatic changes in the landscape of organization, search and retrieval.

Through these ten tempestuous years, I've found the infamous three circle diagram to be a great tool for explaining how and why we must strike a unique balance on each project between business goals and context, user needs and behavior, and the available mix of content.

 

Product roadmaps can be powerful assets to leading a technology business – buy only if they are created and managed in the context of appropriate policies. In fact, the product roadmapping process a company uses can be as important to its business as the roadmap itself. In the Product Strategy Network’s roundtable meetings on product roadmapping, field-tested practices and policies are presented in detail by PSN Members. Here are a few of the highlights:

…Is another man’s treasure. There are many different ways to document requirements when developing software. And there is a proliferation of requirements documents - MRD, PRD, SRS, FRS and design documents. Everyone has a perspective on what each document represents, and each person on the team has a unique perspective on what questions the document answers.

An article on testing strategy for non-functional requirements that stimulated a fantastic discussion about functional vs. non-functional requirements. Great points are made both to eliminate and to highlight the distinctions. The strategy for developing a test plan is good, and worth reading alone, but this article is fun in that it went in a completely different direction with a very well informed debate.

Okay, we're getting somewhere with our question. "Soul" seems to be the essence or the actuating cause that decides how someone or something behaves.

Does Your Product Have a Soul?
This brings us to the single most important question in this article: