A few weeks back I was trying to work out how to analyze a Tumblr’s performance – a long-standing issue for everyone, particularly within the fashion industry. Short of cataloging every note and post by hand, there isn’t any tool out there that solves for this problem and so a few days ago I, along with my colleague Vladimir Pick, set out to build our own. It’s called Numblr. It was conceived, launched, and in use by others in four days. What follows is a reflection on our process.
Fewer Feedback Loops
We didn’t ask for any input during the first iteration of this project. Few people in the office knew it was being created, unless they happen to peer over our desks. Working alone allowed us to build momentum, move fast, and stay focussed and excited on the initial vision we crafted. We were working on creating a minimum viable project; had we invited feedback early on, a ton of solid ideas would have came our way, but with them, a ton of meetings to toil over what feedback we’d accept and what the timelines were for implementing them. We had already decided to launch first, iterate, and accept feedback later. The lesson here is don’t try to build v2 when v1 will do, especially in low-risk environments.
By keeping the entire operation lean and only making small, incremental changes to the tool, everything started to feel like a small victory. Added a new line of CSS? Win. Informal, but frequent meetings no longer than a couple minutes? Win. Revised the structure of a multi-dimensional array? Win. With only small pockets of time to work on this project, we were forced to be focussed on clear outputs. This made small achievements appear as clear victories, meaning every incremental change increased our momentum and drove the project forward.
Define Boundaries You’re Comfortable Working In
Identifying a specific problem to solve for and finding the right people to solve for it is key to a quick success. We never explicitly outlined boundaries when it came to our roles on the project, but given our familiarity with each other, and pre-existing working relationships, we didn’t have to. We knew what our strong suits were and played to our strengths without needing to discuss it. That might sound obvious, but as team size grows and varying degrees of expertise start to overlap, selecting the right person to champion a specific role gets tricky.
Beyond roles, the boundaries of the project were defined by the data provided by Tumblr’s API and the narrative we were trying to craft. Having used the platform for a few years, and having poked around the API once or twice beforehand, it took little time to decide which metrics we could accurately depict, which ones we couldn’t, and how sophisticated we could make our visualization of them for a v1 launch.
Use The Right Existing Assets
Existing assets can help you move fast, but they’re only helpful if you understand them well enough. We used Twitter’s Bootstrap framework, for example, because it’s well documented and we had previous experience with it when we built M.E.C.E. Maker, another Undercurrent project. The same wasn’t true for the charts we wanted to make, though. Despite the dozens of charting libraries out there, we could’t find one that we could quickly learn the ins and outs of, so we built ours from scratch. As a result, making changes to them is easy-peasy.
This project was only born because of the mission and freedom we’re given at Undercurrent to explore the internet and create new knowledge. Without it, we wouldn’t know as much as we do, nor have the time to dedicate to a project like this. Come check out Numblr and give us your feedback. It’s buggy, but who gives a shit.