The need for speed

In this post, I’d like to talk about using a “co-location” approach for defining and developing a software product, and I’d love to get your thoughts. More about what I mean by co-located product development in a moment. First, some broader context.

As human beings, we want things to be faster, better, cheaper. And that’s certainly true of software development. Many methodologies have been invented to get software out to the marketplace quicker: waterfall, CMM, UML, Stage-Gate, rapid prototyping, extreme programming, user centered design, and, of course, agile. Recently I’ve started exploring the Lean Startup methodology pioneered by Eric Ries, which is a sort of lean software development process geared for startups that uses the principles of reducing waste, iterative development cycles with constant customer feedback loops, and metrics measured outcomes to achieve product/market fit.

One other methodology (if you can call it that) I’ve experienced in the past is a “co-location” approach. I basically describe this as “identify a business opportunity to solve for; then take a bunch of people across the company to represent the business, implementation, operations and IT, throw them into a room, and don’t let them out till they’ve designed the product / solved the problem.” The thinking here is that if we take our best and brightest, and focus them in singular fashion on solving a particular problem under a tight deadline, they’re bound to come up with magic, right? Isn’t that what saved the day in Apollo 13?

I’ll be honest. Whenever I hear co-location, I have a major ugh moment. Here’s why. I’ve experienced co-location twice. Once was a situation where the business problem was outlined, the group ideated for a considerable amount of time, and then quickly began defining the product. Because IT (or IS or Software Engineering or whatever your organization calls it) was also involved, they could provide important system knowledge to ground the conversation technically, and at the end of the multi-week process provide an estimate as to the level of effort (LOE) involved in developing the solution. The LOE would be a pointer to development cost and time to market, a key consideration used by senior management in prioritizing projects. Another was in a war room type situation where due to a large number of quality issues with the software development, the product launch was in critical jeopardy, so an emergency “all hands on deck” situation was called where the entire dev staff + QA + product management were put into a room together to get the software out on time.

Both situations involved a fairly large group of smart individuals working collaboratively everyday over a multi-week period for a desired outcome. Both situations resulted in a shoddy and costly product that received at best lukewarm responses from end-customers.

Here’s why they failed:

  • Focus on the wrong outcome. In my first scenario, the situation was set up with the right intentions, but because getting an LOE was the identified output from the exercise, the focus inevitably and quickly became defining a product with a low LOE, with low LOE being assumed as a proxy for faster time to market. In my second scenario, the focus became a race to production, leading to an inevitable sacrifice in – yep – quality.
  • Lack of product definition. This applies more to my first scenario. The desired product was described in broad strokes (like describing a flashlight as “having the ability to light the room when turned on”), but these broad strokes meant IT was dangerously filling in the gaps, leading to an overly inflated and ultimately discardable LOE.
  • Product definition by committee. Everyone has an opinion. So in a co-located situation, everyone’s opinion is heard, none are discarded, and in the end you have a diluted product that may satisfies everyone’s egos, but doesn’t truly solve the customer’s problem. Pragmatic Marketing Rules #4 and #6 are violated here:
    • #4: “The building is full of product experts. Your company needs market experts.”
    • #6: “Your opinion, while interesting, is irrelevant.”
  • Product definition by the business person. This is the opposite of the above. If one or more business people are in the room (this could be the marketing director, business development or sales guy, or a GM), there is a tendency for everyone else to defer to them. The non-business people will rightfully look at them asking “So what do you want?” The business folks have an understandably deeply vested interest in the success of the product (because after all, they’re paying for it!), and so will want to control how the product is defined. The problems are: (1) business folks are typically terrible at product definition, and (2) none of these folks are market experts, which brings us to the next problem.
  • Lack of market, especially customer, input. This is perhaps the most cardinal sin of all, unforgivable violations of Pragmatic Marketing Rules #2 and #8:
    • #2: “An outside-in approach increases the likelihood of product success.” Co-location strikes me as definitely a tune-out approach.
    • #8: “The answer to most of your questions is not in the building.” Customer research may have been done upfront in defining the business opportunity, but is often neglected in validating potential solutions during the co-location effort.

Another issue I have with co-location is the resource commitment. Co-location requires a bunch of people across the enterprise to be committed to the process for a fixed length of time. That means anything else those individuals may have been working on at the time must be dropped or put on hold. The larger the organization, the larger the ripple effect, as each of these individuals are likely working on other initiatives with others folks across the enterprise not a part of the co-location effort. This means business comes to a standstill for those efforts. This seems inefficient and wasteful.

The Apollo 13 approach may be great in emergency situations, when a creative solution is needed for an extraordinary situation. Co-location may make sense when there is a need to solve a problem that is immediate and urgent. But it does not strike me as a sustainable way to define and develop software products.

So why is co-location used? I can identify two reasons. First, back to my opening remarks. There is a need for speed. We have a business problem, and if we get our best folks to focus on it, we should be able to get to a solution quickly. Voila! Problem solved in a few short weeks!

Second, prioritization. No business can pursue all opportunities at once. Senior management must constantly make difficult trade-off decisions on which problems to solve, products to develop, and projects to fund. An LOE is a critical piece of input into prioritization decisioning. Co-location’s appeal is that an LOE can be produced in a short timeframe to help with that decisioning, and every key stakeholder has been a part of that process.

The problem is this is all an illusion. Co-location gives the perception of speed. The LOE is typically either inflated, because of the lack of proper product definition, or is gratifyingly low only because the product has been so watered down as to render it ineffective in truly solving the customer’s problem. Either way, quality suffers.

Now, I admit this has been my personal experience, and I certainly don’t profess my experience to be a proxy for wider market truth. (My opinion, while interesting, is irrelevant.) So I shall now take an outside-in approach and tune-in to hear from you. Have you ever experienced a successful co-located product development effort? Does co-location ever make sense for software product definition and development? If so, when? Here’s a really fun question: if your management believed in co-location and you did not, how would you convince them otherwise? Are there outcome defined ways, quantitative or measured otherwise, to prove your case?

Like This!

Add to: Facebook | Digg | | Stumbleupon | Reddit | Blinklist | Twitter | Technorati | Yahoo Buzz | Newsvine