Go Ahead: Push the Red Button

I’ve spent the last few months amid the chaos of building another start up. There have been lots of mistakes, of course, but I was surprised by one of the largest of them. I’m grateful to my co-founder who so clearly brought it to my attention.

As a co-founder, it was vital for me to be involved in the very early stages of defining the features and usability of our product. What I didn’t understand was the importance of allowing the initial push of development to happen, and to let it happen unhampered by the creeping, insidious list of minor tweaks that I kept adding to my wishlist. Each micromanaging tweak caused an equivalent wrench in the works, and although each was rooted in my drive for a better user experience, a simpler product (blah, blah, blah), each change would have, if left unchecked, set back our product launch by vital weeks or months.

Marketing guys like me are the worst for the development stage because we deal primarily in words and ideas. Words and ideas are infinitely easy to generate, but far more difficult to realize in lines of code. We marketers extend ourselves the luxury of changing our minds and refactoring, and expect that developers will be able to easily follow suit. The reality is confusion, misdirection and potentially crippling delays.

The lesson here isn’t about delivering a sub-standard product quickly. Instead, the lesson is about having the discipline to _productively_ participate in the early stages of planning and design. Those early stages are fun, exciting, invigorating. But in retrospect my error was to trivialize it, thinking of it as endlessly iterative. It’s always possible to refine the concept, streamline the feature set and theorize a better product, but what really counts is having the discipline to shut that process off to allow the development team to deliver on Phase One without confusing them with the limitless potential of Phase Five.

At Gaboogie we use Lighthouse (http://www.lighthouseapp.com/) to submit and manage trouble tickets. It’s a great tool for documenting bugs and requesting new features. But it’s also dangerous in that it can so easily transmit my actual indecision about what is truly urgent versus what is important to a team whose job is not to prioritize my ad hoc requests or to interpret on-the-fly shifts in focus.

As with any start up we’ve had a few bugs and glitches since “pushing the red button’ and launching the service to the earliest group of users. These issues have been relatively minor, but significant in the sense that there is only one opportunity for a first impression. I really learned my lesson when I realized (or rather, when my co-founder rightly shook some sense into me) that my continued focus on what could come next, and what might be cooler or better in terms of features, was getting in the way of our primarly goal: making the product we already had work the way that it was supposed to.

Now I know that it’s important not to confuse perfectionism with success. Endlessly pursuing the perfect product can mean never delivering a good product, or the right product. Successful start ups are about effective use of limited resources. While it’s critical never to limit the vision of what the company can be, having the discipline to package that vision into manageable pieces is perhaps more important still.