Background
Although I do less consulting than analysis, research, or programming, I usually come away from a consult feeling like I’ve made a more profound contribution.
I categorize consulting into reactive and proactive.
Reactive
I’m sometimes asked by a client to look at an analysis done by another vendor, determine what went wrong, and recommend how to proceed. As an example my first work in advertising was trying to determine why a vendor’s carefully-developed (and expensive!) predictive model to identify prospects who would become buyers did worse than not using the model. There were many problems with this model (too many to explain here) but generally a recurring theme is developing the model using data from the past prior to a big shift in the marketplace.
Another type of reactive consult I’ve done is to audit a business’ marketing plan and communications and make strategic recommendations that either could be very cursory or essentially be a detailed 5-year full marketing plan. One of the reasons I’m sometimes asked to do this, when I’m not a pure marketing expert, is that I can often do a good job of quantifying existing problems ad putting into place good metrics for the future.
I often consult on Web or application programming. It’s as likely, when developing a typical (medium-sized) Web site, that a project runs in to very serious problems and the client has to change vendors, as that the client is happy with the work the first time. Most often the problem is that the client uses the vendor with the lowest bid for the site, and that vendor might be an individual programming her third site ever. With two previous successes on a much smaller scale she might be confident that she can build a large custom CMS and CRM using an unfamiliar database, and she therefore bids way too low to pay her rent for the 4 extra months the project ends up taking and takes on too much extra work or just quits.
Another very common Web site problem is a vendor trying to make too many client-driven changes in the middle of development and not setting up a good version control system or at least a good ongoing backup method. All but the smallest Web sites should be carefully planned by client and vendor, have copy, design, layout, and site map approved in advance, and should be carried out with almost military precision and order to truly minimize the likelihood of serious problems.
That’s not to say that clients shouldn’t make changes, but ideally those should be put on a list (and prioritized) for after beta testing. If, as a client you find yourself waiting to see the Web site in your browser before deciding whether or not you like the look, you might consider asking the designer to export the design to a single jpeg and put it online. Make a final decision if at all possible at that stage.
Proactive
Every once in a while I get to consult about product development at an early stage. My long-held belief is that too many companies develop a product primarily because, to the organization’s management, it sounds good in theory or it’s "sexy." Once they have some reason to worry about customers liking the product they have to use qualitative research to figure out a way to sell something that customers don’t want or don’t want to pay more for.
So my advice is often pretty simple and boring: do some product development qualitative research in advance, discussing the existing product or products in the product category in question. Discuss problems with existing products and ideas for improvement. This is a good example of where a well-run focus group can be advantageous over individual interviews.
The best way to structure that research, in my experience, is to find a similar product category which everyone is familiar with and which has recently seen significant improvements (e.g., cell phone category [iPhone], foods [organic], cars [Prius], televisions [LCD], restaurants, clothes, washing machines, refrigerators). Discuss what products each participant has purchased and why. What impact have the improved products had? Why were participants willing to upgrade or pay more? When didn’t they upgrade or pay more? Ensure that their ideas about the researched product category are consistent with their behavior in other categories.
Product development is difficult partly because you can’t really know how well a new product will do until people are forced to consider buying it. It’s hard to fully trust people’s feedback about whether they’ll buy a new product because they are rarely given enough information about it: how it’s going to be marketed, exactly what it will cost, where they can buy it, what the packaging will look like, what kinds of associations might emerge.
There are ways to both learn about people’s actual behavior around an emerging product and to get consumers to contribute to its development without their having to speculate.
If a Web site were the new product then a great way to do this is to present two slightly different versions of the home page randomly to visitors – versions too similar to the existing home page to cause a novelty effect – until one version was reliably clicked through more often. That would become the new existing home page and two versions of it would be presented.
Using this approach, with guidelines to avoid "local maxima," the Web site could be "evolved" into a version that had proven to get more click-throughs and along the way the business would be changing subtly to match what it’s visitors wanted instead of losing customers who didn’t want change or missing the mark with potential customers. (I developed the full guidelines to this "Webvolution" approach in 2000 for MyPrimeTime.com and we were ready to begin implementing it when their second round of funding fell through.)
It’s a fairly simple example, but if the measurement system is in place very similar processes can be implemented offline.
