25x52/2014: End-of-Year Retrospective

Observations and Lessons Learned from 25x52

During the Summer of 2014, I embarked on a personal mission to launch 25 projects in one year (52 weeks) — hence, 25x52. With the year’s end, I thought it fitting to reflect on the journey thus far.

(1) Release brittle systems…on purpose. Don’t over-analyze. Many years of product experience had conditioned me to design for scale and to never release products that weren’t feature-complete. But this is a different context and I had to retrain myself to NOT think about scale or longevity right out of the gate. Those are different problems that warrant a different approach — if warranted at all. Instead, just deliver the essence of the idea. Nothing more. Since I committed to releasing a lot of projects in short intervals of time, my strategy was to find lightweight ways to validate whether the project matters to anyone in the first place. If no one cares, I learned something and simply moved on. If it does matter, your audience will identify — and, on occasion, even volunteer to patch — the valued elements of the project that need help.

Wiley Cerilli once shared a story of how one early release of SinglePlatform included a button that, when clicked, did nothing but announce the feature was “Coming soon.” The reason? If people didn’t click on it, then clearly there was no user interest and wasn’t a feature worth wasting resources to build in the first place.

(2) Incompleteness and the feedback sweet-spot. Ever get a nagging feeling when you see something that’s unfinished? Turns out, that urge to finish something that’s incomplete creates the optimal opportunity to invite user involvement and feedback. In essence, you’re tapping into the human tendency toward getting closure [see Zeigarnik Effect, Gestalt Law of Closure ]. The key is to offer the right level of incompleteness where it’s inviting enough for someone to want to fill in the rest, yet not too informative that it already seems resolved.

Unfortunately, for many of us, inclusion in the (product) development process would often start at the nearly-resolved stage where majority of the foundational decisions have already been determined. If you present work that’s open and seemingly incomplete, you’ll encourage more involved, collaborative participation. If you present something that already seems resolved — even if it’s just a rough prototype — you’ll encourage critique and increase detachment. We tend to care more if we think we’re part of the solution.

(3) The opportunity cost of busy-work. Our brains aren’t wired for analytical thinking by default. Majority of the time, our brains operate through reflex thinking systems. This meant that, in order to acquire new knowledge, I had to rely less on rote skills.

For most of us, engaging in rote processes and busy-work (doing work for work’s sake) gives us a satisfying sense of accomplishment. We feel productive. Yet, often, this amounts to running around in circles, logging a lot of activity, without actually getting anywhere. To-Do lists are false proxies for mindful work. Stop extolling busy-work and cramped calendars. Learning and comprehension comes from slow-thinking.

Tech tinkerer, design analyst, ITP alum. I manage TechStars NY HackStars; @wefestival Twitter custodian; teach Entrepreneurship at Parsons @mfadt

Tech tinkerer, design analyst, ITP alum. I manage TechStars NY HackStars; @wefestival Twitter custodian; teach Entrepreneurship at Parsons @mfadt