T-shirt All Tied Up From Full Bleed via tcritic
Having read this on a post at LinuxWorld it got me thinking:
Google is one of the few large companies that gets one fundamental rule of the Internet: Trying stuff is cheaper than deciding whether to try it. (Compare the cost of paying and feeding someone to do a few weeks of P* hacking to the full cost of the meetings that went into a big company decision.)
So when the cost of deciding to do something becomes much more expensive than doing something, what do you do? Here are a few ideas:
- Empower teams to launch experiments
- Develop a process for manageing projects as a portfolio of experiments
- Evaluate projects regularly
- Killing projects should be as easy as starting projects and everyone needs to understand that, and the criteria
- Start cheaply
- Get ready to fail faster
- Prepare to fail in public and be ok with that
- Create a “beta” culture
- Put basic legal boilerplate frameworks in place that minimize risk, don’t reinvent it each time
Those are just some rough ideas, any more? Anyone facing this issue?
Hey Karl,
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
In today’s digital world, empowering experimentation is more important that ever.
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 .
Smart post. One of the key reasons why I think we need to embrace this post is because of our innability to predict how things will happen.
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.
Wow, great comments everyone, this is a really fascinating topic to me, and the question is almost Koen like
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 love the shirt AND the topic!
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.
Yes yes yes… great post and marching into 2008 is so relevant for bigger companies who need to think this way. Design and prototyping is a creative experiment as much as a business value prop, it cannot be analyized the same way a merger is. “Create a beta culture” is the best one. thanks for this, will share further.