The IT folks have broken a lot of barriers in their adoption and innovation within the realm of process. Things like Agile methodologies have been instrumental in changing not just work practices but ways of thinking. Marketing departments are still struggling with this.

While I agree with the “learn to fail fast” approach it is also important to plan for success. Too often projects/startups can be taken by surprise and find that there is simply no capacity to cope with the demand.

Totally agree Mark that this is a concept that is valuable in marketing as it is in product management, product strategy and i’m sure other aspects of business. Certainly any area of business that depends on “new ideas”.

I’ve been a big proponent of marketing adapting this approach vs. the “campaign” mentality that it currently has. We don’t know what is going to work or take off until we try it and trying more things has an impact in and of itself.

I’m a big fan of the 70/30 concept. 70 percent of your efforts should be on your core deliverables, 30 percent should be dedicated towards “logical” innovation.

As I see it there are two types of innovation:
- Lowest Hanging Fruit
- Breakout Innovation

Determining the proper balance between the two will be the subject of today’s post of at http://jburg.typepad.com/future .

Good thoughts – my first reaction is that you need to KNOW that the cost of deciding is larger than the cost of doing it. That’s a problem in itself. It assumes the organization can identify theses costs across the board (I have not seen that happen in organizations working in this context (fast turn-around web/app focus). And as it becomes larger over time, the organization knows less and less about what’s going on across the board – obviously a vicious circle of rising costs and lower internal awareness/communication.

Organizations with shared resources for example (like matrixed services and business units) struggle with “being fast” because the decision-making process is slow or problematic but that’s not because the cost was identified that way. It’s because they see a long project duration and inability to go to market quickly. Effects are obvious, causes are nebulous. Misdiagnose results in trying to fix the wrong problem (for example, cutting user research and validation because “it takes time”).

You hit the nail on the head in managing projects as a portfolio (whether experimental or not – I think that’s a different facet, perhaps better aligned with a business’ core principles). But projects are only managed as a portfolio if you have a criteria for projects to get started in the first place. That’s not what happens in my experience (very few places have concrete criteria that is shared knowledge across the organization). Managing a portfolio also means you compare a project to another – when people can barely create criteria to decide what to work on, they definitely don’t have the bandwidth to compare projects. Yay waste of resources!

Prepare to fail in public – I agree and I think it’s central to this type of environment, but getting an established company, one with serious worries about the cost of customer service for example, to think this way is such a leap of faith that it’s hard even starting a conversation about it.

More severe a problem than being ok to fail in public, is being ok to fail internally. People don’t think failure is ok (and I think that’s a US-centric sentiment mostly), so killing a project that’s not successful is even more difficult. People don’t want to admit they failed because they don’t feel it’s ok to fail – so they continue to fail and keep hemorrhaging money on dead-end projects. Oh the pain…

Lastly, the problem of ‘technology focus’ over ‘people focus’. Creating a beta culture implies doing things quickly so they can be exposed to real users early so the organization can spend the most amount of time possible cheaply learning from users. Companies that are in the business of creating products, not in the business of making people happy, struggle getting into this model because it requires a focus on people not on technology. Even if they are truly interested in putting things out quickly, it’s usually a half-baked plan, putting some app out in the world without a way to capture how people are feeling about it, for example. And that is not only a money sink but breaks the organization trust in the model of putting things out fast.

Anyway, just some thoughts, I really appreciate your perspective and the points you extracted – I just wish there was a method to communicate these value to an organization with the constraints and challenges I mentioned above and actually get it done. I’m looking for a way, let me know if you find first