The tripod for getting your ideas on the level

Self-directed projects are liberating. To be the one to decide what to do–and how to do it–means that you can keep your idea intact. You can explore what you like. You don’t have a schedule unless you impose one on yourself. And, with increasingly better tools for doing it yourself (whatever “it” happens to be) you have shortcuts to achieving it. It’s easy to forget that this increased ability to do it yourself is a relatively new phenomenon. It wasn’t that long ago that the media we consume now, the audience we can reach, and the level at which we can tailor goods to our wishes was only within reach of professionals, and only those working within organizations prepared to invest in that infrastructure.

So…you have the power now, but consider how it may affect what you create. That DIY drive to get something made will get you to the practical puzzles quickly…which can cover limitations that may be far more subtle. Did you push yourself to define what you set out to do clearly enough? Did you think through what your assumptions about your audience or users truly are? Did you allow the comfort of using the tools you know shift you away from your original vision?

You need other perspectives. You need the tripod.

I had not heard a name put to this until discussing it with my product management partner, Ian McCarthy. In the middle of 2010, we were discussing some of the early thinking that shaped our approach to “open” groups on LinkedIn, and at some point we reached a disagreement on a particular point about content. It was at the end of one of those exploratory conversations that makes you feel like you’ve been on a trip and have just seen a glimpse of home–long, worthwhile, but also a little exhausting. We knew it was unresolved, but were pretty much talked out. We decided to pick it back up once we had a chance to run it by James Richards, the engineering lead. The next day we described the dilemma to him, and while he saw the valid uncertainty there, he thought through the impacts on the architecture, and how much ability we would have to adjust our approach as we learned more. It was enough for us to pick a direction we’d be comfortable with to learn more, to think through the problem further and gather more feedback without blocking the engineering efforts. After more investigation I identified more clearly what led to my concern–a more specific nuance about handling existing content–that ended up being pretty easy to sort out once we narrowed in on it.

This became a regular thing for tackling challenging problems. If two of us believed in the approach, the third would accept that it was worth finding a way to make it work. Sometimes I was challenged to expand my thinking about virality, to make the design “lean forward” in promoting particular features or actions more than I chose to do on first blush. Sometimes it challenged Ian to leave a particular feature on the table for the sake of streamlining. Sometimes it challenged James to put resources towards solutions of particular importance for a particular experience goal, even if it was achievable with an alternate design.

It was never the same reason twice, but we knew that it would always see through to a result that worked. With a tripod, there is never a tie. And with that tripod in particular–business, design, engineering–each perspective is unique, valid, and necessary to the success of the product.

There’s a mystique around the sole creator, the purity of a visionary/implementer who conceives and creates an idea from start to finish. It’s impressive to imagine that level of insight and skill, let alone that force of will, in a single person. What that approach lacks is that gut check of someone (preferably two!) that have unique perspectives and are equally invested in its success.