Keep Some Goals Fuzzy — Make Others Crystal Clear

Written by Mike Shapiro | | October 22, 2015

I agree with most of what’s been said over the past few years in books like Gamestorming, and more recently in the article, Why Fuzzy Goals Are Essential For Learning about staying loose on goals as a great way to stay curious and on your toes.  It helps you get in — and stay in — a learning mode while you’re on your way to developing a great product people will love and buy.

But believing it means there’s no such thing as failure and that it beats biases might be pushing it too far.

Because there’s one rub in this “fuzzy goals” business:  You’ve got to sell senior management or your funding sources on giving you approval to spend money and commit resources to a product development process.

While you can be fuzzy about the specifics of the end product — its precise characteristics, specific functions and look and feel — you do have to be very precise and clear with everyone, including your management, capital sources and your team, about the problem you’re trying to solve for the people you expect to buy the product.

So, for example, if you say you’re going to help people save time slicing and dicing vegetables, that’s:

  1. Being specific and clear about the customer problem you’re addressing, and you should be held accountable for achieving that goal, and
  2. Reflecting some bias — proceeding from an assumption that using a plain kitchen knife for slicing and dicing is considered to be too difficult, messy, time consuming, dangerous or some combination of those descriptors.  You’re on the hook for making sure that’s true for at least enough people to constitute a market for a product that does it differently.

You can still be open adapting your design along the way, at least until well into the development process about, for example, whether your product will be a type of manual chopper, spiral slicer or mini-mandolin slicer or some other new device.

To get the green light — and the money to move ahead — with virtually any development process, you’ve got to put yourself on the line with a risk of failure — failure to meet a real customer need. And recognize that, in the process of so doing,  you will necessarily start with some biases about the early direction your work will take, though they may dissolve soon after you begin, to be replaced with new ones, and so on.

Resolve to stay in a learning and adapting mode, but don’t let your project fail to get off the ground because you (proudly) announce that your customer need satisfaction goals were “fuzzy.”