Wednesday, April 10, 2013

Chamath Palhapitiya (VP of Growth @ Facebook) on focusing on the right things

I've started focusing more of my time and attention lately on the concept of growth and specifically growth hacking. I came across this Udemy course from the Growth Hackers Conference in San Francisco in 2012. The opening keynote presentation is by Chamath Palhapitiya who was the VP of Growth at Facebook. His presentation is very entertaining and struck a cord after reading a ton of information about "optimizing for virality (k factor)" and feeling that this wasn't the right place to focus on. 

Chamath emphasizes many times that ultimately its about building a product people actually want to use instead of some shitty concept that sounds (and maybe looks) good but is poorly executed. This can  be very challenging but when done right its incredibly rewarding. His full presentation is available on YouTube and is just under 40 minutes long. His presentation really helps to refocus on building quality products and cut out much of the so called "lore" and "gut feeling" that is common place in many organizations. 

He also mentioned a simple growth framework that originally started at Ebay and it looks like the following:


Chamath was adamant that his team (or anyone else's for that matter) should not focus on the last element, virality, as that element happens organically if you've focused and executed correctly on the first 3 elements of the growth framework. Given that Chamath and his team were instrumental in Facebook reaching 1 Billion users in 2012, this strategic approach for growth is well worth paying attention to.

I'm heading to the Growth Hackers Conference in San Francisco on May 3rd, 2013. If you're heading there yourself get in touch and we can meet-up.

RESAAS Mobile App Released for iPhone and Android

My engineering team and I at RESAAS recently released both an Android and iPhone App a number of weeks ago. We built it using Appcelerator's Titanium framework. It's one of the many write (almost) once and run anywhere frameworks. After producing a prototype over the Christmas break we saw that the framework met our needs in terms of feed scrolling performance and so we embarked on an new mobile app. Our team is thrilled with the end product and its now available via the usual mobile store channels:


Saturday, January 19, 2013

Software is about to eat the NYSE

The renowned VC firm, Andreessen-Horowitz, formulated a hypothesis in 2011 that "software is eating the world". Their hypothesis has since spawned many versions such as software eating fashion, software is feeding the world and, my personal favorite, Jack Dorsey is eating payments. Software however can have less of an appetite depending on where you do business in the world.

New York City's financial businesses have always been harder to access for software startups due to a number of factors (of which, I'm sure, culture and incentives play some part). One such man, Jeffrey Sprecher, appears to have broken through that divide and was profiled in the New York Times on Sunday, January 20th, 2013. The NYT article is a great story on business success, but embedded within it is the notion that software is currently "eating trading" (that is, the art of human trading within exchanges) and software will eventually eat the vast majority of this human activity over time. An important consequence of all this trading exchange gastronomy is that wealth gets redistributed more quickly to the victor... in this case, it is Mr. Sprecher and his firm ICE: IntercontinentalExchange.

After reading the NYT article, I'm reminded that the best software products aren't always enough for success. Technology alone conquers nothing; timing and deep market insight are the other essential pillars which, when combined with technology, create a powerful catalyst for creative destruction. As markets begin to shift, new opportunities arise. Those of us who see these opportunities more clearly (and that's really the hardest part) have the ability to act by finding a software-based solution that fits that opportunity. This software then has the ability to eat just about anything in its path towards profitability.

Monday, December 10, 2012

Prototyping with Google's Prediction API, Python, SQLite and some JSON APIs

:: Introduction

I've been playing around lately with the car2go API v2.1 as I was curious about how easy it would be to ingest it's vehicle location data over time and then try to accurately predict certain outcomes using machine learning algorithms.

I've had quite a bit of success in the past using Google's Prediction API for spam comment detection but this "spam" problem was using classification values and not regression values. Regression values  would have to be used in this type of geo-coordinates based problem.

The last time I used the Python programming language was when I worked at Toshiba in Edinburgh, UK a number of years ago. I was interested to get back to using the language as I remember it being a really elegant language and it also seemed like a great fit to prototype things out. I was using a Macbook Air, which had Python pre-installed, so this made it pretty easy to get up and running. I knew I'd need to query the API, parse out the necessary values and store these to a datastore of some kind. I opted to use Mac OS X's built in SQLite database at it integrated well with Python and it provided a great interface from the command line to test out various SQL queries.

:: Inserting Records into SQLite with Python

The following Python program illustrates how to connect to a SQLite database called car2go.db and insert a single data record into the Vehicles table (Note that the Vehicles table schema needs to be pre-defined and created before the code will execute successfully):

#!/usr/bin/python
# -*- coding: utf-8 -*-

import sqlite3 as sqlite
import sys

con = None

try:
    con = sqlite.connect('car2go.db')

    cur = con.cursor()
    
    cur.execute("INSERT INTO Vehicles VALUES(<INSERT_VALUES_BASED_ON_SCHEMA>)")
    
except sqlite.Error, e:
    
    if con:
        con.rollback()
        
    print "Error %s:" % e.args[0]
    sys.exit(1)
    
finally:
    
    if con:
        con.close()

As you can see this code is really lightweight and easy to get up and running when you have a machine with Python installed. 

:: Requesting API Data and Parsing Values with Python

The next step was to query the JSON based API and parse out any necessary vehicle values:

#!/usr/bin/python
# -*- coding: utf-8 -*- import json import urllib2 import sys # Note that you'll need to replace <SECRET_KEY> & <LOCATION> with the appropriate values car2goVehiclesApi = 'https://www.car2go.com/api/v2.1/vehicles&oauth_consumer_key=<SECRET_KEY>&loc=<LOCATION>&format=json' # request vehicle data in json format webReq = urllib2.urlopen(car2goVehiclesApi) vehiclesJson = json.load(webReq)

The vehiclesJson object now has the JSON data from the web request and can be queried directly given the appropriate keys/indexes. And example to output the address of the first vehicle is:

print vehiclesJson['placemarks'][0]['address']

:: Outputting SQLite Query Data to CSV

Once these basics where done I then had the foundation to expand upon it further. I eventually extracted all the necessary JSON vehicle data from the web request and inserted it into my Vehicles table in my car2go.db SQLite database. From there I crafted the specific SQL query I wanted and output that query data to a CSV file using the following sqlite3 command syntax (simply run the SQL query after setting these values):

.headers off
.output vehicleData.txt
.mode csv

:: Using the Google Prediction API

Setting up your Google Prediction API the first time can be slightly tricky so be careful to follow Google's directions carefully. I won't go into these prerequisite details here as Google has already done a great job explaining them here (and will most likely keep them up-to-date in the future). 

After setting everything up the vehicleData.txt file was then uploaded to one of my Google Cloud Storage buckets where it could be queried directly by Google's Prediction API. Note that depending on the data you upload you may need to wrap the strings in double quotes according to Google's specified training data format. After uploading, the first task was to train my model which can take anywhere from a few seconds to a few minutes. Once this is complete (querying for the status will inform you when its complete) you can begin to ask for regression predictions from the predict HTTP request. Note that depending on what you are predicting the outputValue or the outputMulti[].score values can be retrieved from the JSON response and used to interpret your intended outcome.

(Note that I was using Google's Prediction API v1.5 for this prototype).

:: Conclusion

I'd highly recommend giving the Python language a try (if you haven't already) for your next prototype project. Integrating it with a lightweight database, JSON web requests and Google's Prediction API was pretty easy and my overall impressions with the language and available libraries are that its still a pleasure to work with.