Help, Even When it Hurts

We are a consultancy. Not a big secret. Our job is to do one of the following, generally in this order:

  1. Help our clients kick ass. Work directly with their devs, accomplish awesome stuff, and hope we leave their internal ecosystem in better shape than we found it.
  2. Kick ass on our clients' behalf. Work off to the side, accomplish awesome stuff, and hope we leave them with code and artifacts they can use far into the future.
  3. (and here's the weird one) Help our clients find a better way to kick ass than work with us.

That last one is pretty bizarre, since a business is in business only because it manages to attract revenue from somewhere. And learning that a prospective client can be better served by another vendor (or technology or strategy or timeline or whatever), could easily be in conflict with the mission of the business. But not if the mission is to help the people you meet find the best solution to their problem. When that's the mission, #3 is perfectly natural.

We had an example recently where a rather large, recurring customer of ours came to us with an idea. The idea seemed fairly well-formed and researched; they'd done some initial research on open source code and/or standards we could leverage to get the project moving, they had target customers and a revenue stream modeled out, and we had the capacity to start immediately. We signed off on the contract and invited them down to the office for an Iteration 0.

After a single day of the Iteration 0, nobody felt good about the project. There were more competitors, with more advanced features, already in the marketplace than the customer had realized. The revenue model seemed out of sync with what the market would bear, and frankly, the overall spend seemed light compared to the dawning realities of the need. Everybody went home or to the hotel that night thinking that maybe this project wasn't such a great idea, that the funding mismatch might be too much to overcome, but nobody was willing to just write the project off.

The next day, we decided to do something a little radical. Our customer started the day with the statement, "we don't think we should do this." Instead of that being the end of it, we scrapped the proposed agenda for Day 2, and our CTO (Mike Nygard) ran them through a two-hour business canvas session. (If you haven't been exposed to it, you should: start here). Sitting around a whiteboard version of the above canvas, the team discovered a vastly different approach to the problem at hand. The revenue stream would have to be different, but the potential revenue under the new model was a lot bigger. The up-front investment would have to be bigger, too, and would have to come from other sources. And Relevance may or may not be the right partner to build it. But the team left Day 2 confident that they had a grasp on a much better solution than they started with. Our Iteration 0 worked exactly as it was designed, leading to a well-informed "go/no-go" decision. Most of the time, you get "go". Sometimes you get "no-go", and every now and then, you get "wow, that's a WAY better idea."

Consulting shouldn't be limited to trading hours for dollars. It should be about engagement and collaboration and problem solving. The outcome for Relevance in this case is that we did exactly what we are supposed to do: help our customer solve a hard problem. It is just that the problem was answering the question "Should we pay Relevance a lot of money to build this system this way?" The answer, it turns out, was "no", or at least "not yet", which is a perfectly reasonable solution.