When two of the really amazing thinkers I admire — Ken Bain and Jeanne Liedtka — both say they admire Carol Dweck, I figure it’s time to figure out who Dweck is. Her latest book, Mindset, provides some fascinating psychological support for the power of play and prototyping, as she says…

People who believe in the power of talent tend not to fulfill their potential because they’re so concerned with looking smart and not making mistakes. But people who believe that talent can be developed are the ones who really push, stretch, confront their own mistakes and learn from them.

Janet Rae-Dupree, writing in the New York Times, reveals an interesting connection between Dweck and the iPhone:

Continue…

The common way that financial people will judge the potential value of a project, or a design concept representing a potential future concept, is by building a model, usually a discounted cash flow model like Net Present Value (NPV). The calculation essentially asks, if we do this project and gain the profit we think we’ll gain, how much is it worth to us right now? That way we can compare it against our other options.

The problem with these models is that they assume the world doesn’t change. The model tries to predict everything that will happen in the project from beginning to end in order to arrive at a single numerical value. But in the technology world, there’s lots of change.

So peeps at the forward edge of product and service development have started using real options to value projects. Real options essentially breaks the project down into a series of decisions. At each decision point a number of outcomes can occur, and for each outcome there’s a probability it will occur. There’s also a revenue associated with each outcome that we receive if it occurs. By multiplying the probability by the revenue we get the value of the option.

This is often illustrated using a decision tree, as with this analysis of a drug in clinical trials…

What’s the big deal? It turns out this is a better way to value investments in Internet services for at least three reasons I can think of off-hand…

1. Versioning: The Web 2.0 way of doing things is to release our work in stages, the public beta being a perfect example. If the beta is a big fail, we stop there and cut our losses, or we go down a different path of the decision tree.
2. Uncertainty: There’s a great deal of uncertainty in our work. Twitter, for example, is a big success, but at the cost of a very tricky technical challenge. Instead of an NPV model that would judge the value of the project to be either simply negative or positive, we can model this reality of “large audience / technologically expensive.”
3. Fast Risk Management: The ease of building betas makes it tempting to skip a big financial modeling activity, especially if it can’t accurately reflect (i.e. predict) how customers will react. Creating at least a simple real options analysis can save a lot of investment before building a beta that is hard to emotionally trash once it’s built. And while it’s tempting to say predictions are impossible so we should just run a trial, few managers with any P&L responsibility will invest in that.

Real options isn’t a perfect technique, however. Proponents claim it supports decisions with “mathematical certainty,” but the probabilities are derived from managers’ experience and judgment which is subjective and imperfect. Getting a group of people to agree on the probabilities may be difficult, and once a project is up and running a team may be unwilling to revise their estimates downward to reflect new information, much less kill their own project. Still, for the kind of work we do it’s better than the old ways.

References:

• Putting Real Options to Work to Improve Project Planning
• Real Options = Real Value

I’m happy the concept design research and development I’ve been doing has received some attention, even though I haven’t had much time to share my work. That will start to change next month when I present some tools for generating concepts at the 2008 European Information Architecture Summit in Amsterdam, where I’ve been honored with the closing plenary position.

Last year’s German IA Conference had a great vibe and a wonderful group of people, I’m looking forward to more of the same in Amsterdam.

Art Kleiner revised The Age of Heretics and the 2nd edition is on it’s way to my greedy little fingers. It explores heretical ideas in management starting in 1945 through several case studies to find that:

• People are basically good at heart; they are fundamentally trustworthy. Only workplaces that give their members the chance to learn and add value through their work will succeed in the long run.
• Aim for quality of work, and money will follow.
• Industrial growth is not always desirable. Sometimes it can be destructive.
• Predictions and forecasts are mechanistic substitutes for awareness, and substitutes for awareness lead to bad decisions.
• There is no such thing as “just business, nothing personal.” Business is always personal, even if it isn’t supposed to be. And we are better off recognizing that.
• Everything in business is connected to everything else. Business is a complex living system with many interconnections. No one can control the system; one can only learn to influence it.

This morning Studio 360 broadcast a piece on Christopher Alexander, A Pattern Language, and the influence of patterns in software development. If you know the story, you know the story. Still, I always like hearing Alexander speak, and this is the first time I’ve heard Ward Cunningham’s voice.

When you create a product or service concept, you should give it a name. Sounds like a no-duh idea, but in the heat of the moment we forget to do this. Sometimes…

• we give them numbers or letters. “You see the change in materiality here in concept 2…” or “Clearly Concept C is a total paradigm shift…” But this kinda sucks. It’s hard to remember how the concepts map to numbers or letters, and that makes it hard for people to reference the concept. “Um, you know, I think it was the second one, the one with the thingie…” And if people can’t reference it, they can’t talk about it, much less buy it.
• we only have one concept, so we name it after ourselves. “Our idea is to…” or “The Bixby Canyon Software System, from Bixby Canyon Inc., gives your plants just the right amount of water…” This feels good at first because you can publicize your company and concept name at the same time, and it avoids those messy, expensive naming exercises. But it falls apart when concepts grow up into products. Say when…
  1. you want to change the product or the product name, but people keep referring to it by your company name. You’re stuck, or you change it and risk lose brand recognition.
  2. you introduce a second product which means you now need three names, two product names and a company name, that need different identities. For a long time Symantec was synonymous with anti-virus software, and they had to work hard to be a company known for more than that.

An exception is when you (intentionally or not) have a naming system. Let’s say your company and your first product name is Super Fantastic. When the next product arrives, you name it Super Amazing, then Super Stupendous, and so on.

Just as you wouldn’t have a baby (or a company) without naming it, don’t birth a concept without naming it either.