Yes, Agile can speed up the development and improve the quality of small features.  But it’s too often at the expense of the Big Important Work — the heavy lifting, multi-month market analysis and architectural work that lead to REAL customer value and REAL competitive differentiation.

I magnanimously offered my perspective on agile, boiling it down to the key points of:

• Do the most important things first
• Be prepared to reprioritize on a regular basis as the environment changes

Or, “spend your resources on the 20% of capabilities that will get you the best return.”

So far, so good. Can’t argue with that as an approach, not just for developing software, but for living life itself. And for the self-help industry, which generates tens of thousands of pages on the Pareto Principle every year. And I’m sure CPM, as we call her, is super-happy that I clarified that.

In contrast, the old way (aka “waterfall”) is more like:

1. Figure out what you want to accomplish
2. Determine the most efficient way to accomplish it

It’s easy to see waterfall’s problems when characterized this way:
a. You have to know up-front what your end game is – which makes it hard to respond to market changes
b. The most efficient way of building the full product is not necessarily the one that front-loads the value, so often low-value items are completed and high-value items end up deferred
c. You do a lot of work up-front to document things that the developers never get to

Notice that’s not how agile talks about itself. The agile manifesto talks about working code vs. documents, and interactions over tools (it does cover “responding to change”). In fact, agile, as far the methodologies and manifesto go, is solely focused on programming. (This is changing some – I just listened to Kent Beck’s talk at the Ruby On Rails conference last year, and he’s come up with a very different characterization of the goals of agile: it provides accountability, responsibility, and traceability.)

Now, given my characterization of agile’s – indeed, life’s – key goals, you can then look at agile  methodologies simply as one way to accomplish those goals. But what if, as CPM fears, the most important capability (call it The Big Dog) takes longer to deliver than a sprint or two, and requires visits to lots of customers to understand their problems, and lots of reviews with customers to see if we’re solving their problem?

Clearly, you still have to do the Big Dog. CPM should be able to tell you why. And if the methodology doesn’t give you a way to do it, then the methodology won’t work for that product.

But chances are the 80/20 rule applies to the Big Dog, just as it applies to everything else. And this large monolithic capability can be broken down sensibly into multiple passes through the “smallest thing that could possibly work” approach. Does this require the PM to keep ahead of the development organization? Yes. Is that any different from the old days? Yes and no. The PM needs to figure out the most important part of the Big Dog (the 20%), and make sure it’s understood, there are good user stories, it’s designed, architected, etc., extremely well. After all, that’s where most of the value is going to come from.

But the PM doesn’t need to document the rest of the 80% until later – if at all. In fact, it’s likely that finishing the 20% of the Big Dog prioritized to the top of the project leaves something else – the Medium Kahuna – as the next important item to accomplish. There may be some additional Big Dog-related capabilities that are “nice to have” – and they’ll be prioritized into the rest of the project, if there’s time after getting the Medium Kahuna delivering its value.

“Now wait,” you (or the CPM) say, “I can’t live with only 20% of the Big Dog – I need 100% of it – or at least 80%” And I say this is where the beauty of the agile mindset comes into play. If you’ve completed 20% of the Big Dog, and have the rest of the Big Dog as well as the Medium Kahuna in your backlog, at this point you can decide which is more important, and decide which one to do. You’re already delivering 80% of the value of the Big Dog – now you can decide if you really need to take that up to 90%, and leave the Medium Kahuna on the table, or vice versa. You have control.

Agile is not a silver bullet, and it’s hard to get right, but if it helps you focus on putting first things first and executing on the 80/20 rule, it’s done its job.

…Edison changed the image of the sole inventor by converting innovation to a process with recognized steps practiced by a team of inventors working together…

Definitely an inspiring opening – I guess if Edison could do it 120 years ago, we should be able to do it now!

I got this Innovation Management Overview link via the Innovation Tools site (which itself has a lot of great information on innovation, including a feed of innovation-related news).

By the standards of six years ago, those things are free now. Of course, it’s never free as in beer, because in fact we’re now using all the bandwidth, storage and CPU power we thought we’d never need, doing things a lot of us though we’d never be able to do in real life, like watch streaming live TV on our laptops (and our phones).

Today, I listened to Jeff Hawkins’ talk at ETech a year ago, Why Can’t a Computer Be More Like A Brain?, where he announced the Numenta Platform for Intelligent Computing. I think the idea now is, “If you’re not planning for how you’ll use human-like pattern recognition in your system, you’re not planning.”

What are the possibilities? Jeff listed a few, but there will be lots we’re not even thinking about now (or think are impossible – like we thought watching TV on mobile phones would be). It’s “human-like,” but not human. It can do things we don’t have time or patience for (just like a computer can do arithmetic all day that would drive us bonkers, even if we could do it as fast). And it can do pattern matching on patterns we can’t see – whether those are in infrared, or in huge piles of data that we just don’t have the sensory apparatus for.

Here’s an example. I have a product that manages requirements and their relationships to customers and customer requests (among other things). I talk regularly to customers, and take notes on these conversations. They often mention desires or usage scenarios that are outside the scope of the topic of the conversation at the time, and that aren’t seem related to the product planning I’m doing. Two years later, when I’m actually considering adding features related to those comments, I don’t necessarily remember the conversation. Or if I remember it, I don’t remember which customer made the comment. Currently I use Google Desktop to help me find the appropriate notes, but it’s a pretty rough approach – I have to use my best guess at the appropriate key words, and I end up spending a heck of a lot of time combing through my notes again and again. I’d love to have a human-like agent do this trolling for me – on a weekly basis, review all my old notes against my current requirements and tell me where there are overlaps. And while we’re at it, maybe it can read my blogroll and find related articles I could be referring to.

I know there are a few products out there that (claim to) do some of this already, and perhaps they work (I haven’t tested them). If so, they are the vanguard of this new set of capabilities, and in a few years they will have been overshadowed by realities we’re only dreaming about now.

How are you planning for the technical capabilities – human-like pattern matching or whatever it might be – that we’ll have at our command in five or ten years?

Doug Hall, unlike most business consultants, makes quantitative claims in his book Jump Start Your Business Brain. According to his research, he can predict the effect of certain basic marketing techniques on the success of a business. For example, he says that businesses that articulate “an overt benefit, a dramatic difference, and a real reason to believe” have about a 47% chance of success, while having only two of the three gives about a 30% chance of success.

Today I just ran across another interesting set of quantitative data about success factors, from the Journal of Product Innovation Management, Success Factors in New Ventures: A Meta-analysis, by Song, Podoynitsyna, et al. (I believe the link I provided is free, although most issues of this journal are behind a paywall.)

Based on a meta-analysis of a number of other studies about successful and non-successful new ventures, the authors determined that eight factors – out of about 20 candidate factors – were the best predictors of success. The candidate factors included items like:

• A low-cost strategy
• Prior startup experience
• Patent protection

Interestingly, the eight success factors did not include prior startup experience, or what they call “product innovation”. Instead, the factors were:

1. supply chain integration
2. market scope
3. firm age
4. size of founding team
5. financial resources
6. founders’ marketing experience
7. founders’ industry experience
8. existence of patent protection

The article is a bit vague on some of these – for example, it doesn’t suggest the ideal size of founding team, just that it’s a success factor. And isn’t is obvious that a successful new venture will typically be in business longer than an unsuccessful one? As the authors acknowledge, to a large degree the article leaves more questions open than it answers.

So, getting back to the original question, if you are starting a new venture, or thinking about doing so, will you pay attention to the research and make sure you have all your success factors in a row? (Or that you have an overt benefit, dramatic difference, and real reason to believe?)

There are a lot of good resources up there, including a number of active blogs, weekly live presentations (that are archived), forums, and many articles, such as these:

• Enhancing User Experience By Employing Collective Intelligence
• Project Management and Business Analysis: Dependencies for Success

Tom himself has a great blog – latest article is on Twitter, which I ended up installing as a result (I’m nilsie).

In his latest post, Requirements, shmequirements Forrester’s new Product Management Tool analyst asks “How big a collection of functionality should a requirements tool embrace?”

The canonical answer, based on everything we know about successful products (including, of course, the iPod) is “less than we think.” Products that do more tend to do it less well than products that do less. On the other hand, you do have to make sure you do enough. The 80% solution is often good enough, but the 60% solution usually is not.

Jason Fried and 37 Signals are the current acolytes of this “less is better” approach. They’ve even written a (small) book about it.

My product philosophy holds that two critical factors for a product to be successful are a) that it has to work – to do what it’s supposed to do, and b) it has to be engaging – people should look forward to using the product. The “good experience” concept covers both of those factors. Hence, naturally, I want to continue to get information and inspiration about good experience.

There are other aspects to beating your competitors, but these two particular points seem pretty obvious to me. I’ve always been amazed at how many products don’t do well on either score. With my last product, we would go into head-to-head evaluations with our competitors, and our product would work in the eval, and theirs wouldn’t. Competitors failed along a continuum – from not being able to complete an installation in the first place, to not successfully performing the basic functions, its reason for being.

Some products failed later than others, but even if the other product didn’t fail, we almost always won the evaluation anyway. That’s because our product was better, in a key sense – it was more engaging to use. In that particular product space, most products approached the problem in a certain way that was, you might say, the “standard” approach. Our product approached the problem in a different way, one that turned out to be easier for customers both to understand initially, and to work with over time. So we not only won the evaluations because we worked, but because the customers liked us. As Kathy Sierra puts it, we made them feel like they rule!

But I thought Martin’s most interesting comment was the following, which ties into the Tyner Blain article I blogged on Monday about tying requirements management and interaction design together:

The next most common situation is that product management is put in the engineering organization. While this has the benefit of putting the people that invent and design the product next to the people that build the product, this can also be problematic because engineering organizations are really designed to focus on building a product right, rather than building the right product.

There seems to be a battle brewing on the design front. Do PMs do design or is that a job for the engineering organization? According to Alan Cooper, there are three key functions – 1) interaction design (which he does), 2) an engineering organization focused on finding technical solutions to design problems presented by the first group, and 3) another engineering organization focused on creating production code based on the technical solutions found by the second group. Setting aside this interesting bifurcation in the engineering organization itself, you’ll notice that product management doesn’t show up in Alan’s taxonomy. But if we make the logical mapping of PMs <==> interaction designers, it does align with Martin’s implicit assertion highlighted above – that PMs are responsible for design, as well as requirements.

We can then tie it back to Michael’s Ten Tips for Writing Better MRDs, tip #2 of which is Use Screenshots, “Use screen shots or mockups to explain what you mean. Most of us have heard the saying “A picture is worth a thousand words”. When it comes to writing MRDs, a screen shot is worth a thousand words!” But aren’t mockups what we PMs often get in trouble about – that it’s overstepping our purview into design? I’d be curious to hear what people think about this

Technorati :