"minimum viable product" entries
What is the “minimum viable product” for urban renewal?
Through an interesting confluence, I recently came across three different instances of the same question: what is the “minimum viable product” for urban renewal? Last Monday, I visited the O’Reilly Media office in the old Pfizer building in Brooklyn, and was struck by how unfinished space was side by side with finished, how the remnants of the old laboratory had not been removed but rather just incorporated into the existing space. It is a kind of urban office-steading, pioneering a gritty frontier, as opposed to a more standard style of development in which the building is stripped, upgraded, and then opened to tenants, perhaps with a bit more character than an all-new building but with substantially the same sanitized promise. I posted photos and some reflections on Google+.
The next day, I sat in on a webinar with Carol Coletta of the Knight Foundation and Andres Duany of the Project for Lean Urbanism. Duany’s idea is for “pink zones,” where, for purposes of exploratory redevelopment, red tape might be thinned out. The goal is to find what regulations really matter — and which don’t — and to start fresh to see if we can achieve urban renewal at lower cost. Read more…
Smart data scientists can make big problems small.
Having worked in academia, government and industry, I’ve had a unique opportunity to build products in each sector. Much of this product development has been around building data products. Just as methods for general product development have steadily improved, so have the ideas for developing data products. Thanks to large investments in the general area of data science, many major innovations (e.g., Hadoop, Voldemort, Cassandra, HBase, Pig, Hive, etc.) have made data products easier to build. Nonetheless, data products are unique in that they are often extremely difficult, and seemingly intractable for small teams with limited funds. Yet, they get solved every day.
How? Are the people who solve them superhuman data scientists who can come up with better ideas in five minutes than most people can in a lifetime? Are they magicians of applied math who can cobble together millions of lines of code for high-performance machine learning in a few hours? No. Many of them are incredibly smart, but meeting big problems head-on usually isn’t the winning approach. There’s a method to solving data problems that avoids the big, heavyweight solution, and instead, concentrates building something quickly and iterating. Smart data scientists don’t just solve big, hard problems; they also have an instinct for making big problems small.
We call this Data Jujitsu: the art of using multiple data elements in clever ways to solve iterative problems that, when combined, solve a data problem that might otherwise be intractable. It’s related to Wikipedia’s definition of the ancient martial art of jujitsu: “the art or technique of manipulating the opponent’s force against himself rather than confronting it with one’s own force.”
How do we apply this idea to data? What is a data problem’s “weight,” and how do we use that weight against itself? These are the questions that we’ll work through in the subsequent sections.