3 Quick Thoughts About Graph Search

Facebook recently announced a new feature which will let users perform powerful and expressive queries of the Open Graph using natural language syntax. Furthermore, these queries are context aware and seemlessly integrate everything that Facebook knows about a user into his query so that two users who perform the same query will see different results.

Some of the examples of queries that Facebook demonstrated include:

  • “friends who work at my company and like to ski”
  • “restaurants in London my friends have been to”
  • “people who like cycling and are from my hometown”

The feature hasn’t yet been widely released but here are some of the things I’m curious about and will try to answer when Graph Search becomes available to me.

What is the potential for abuse?

The average Facebook user still doesn’t understand the importance (and wide range) of the various privacy settings that he can configure. How does Graph Search exacerbate this problem? Will queries like “people who recently bought expensive electronics and who aren’t home right now” be possible?

Will a user’s Graph Search queries become part of the Open Graph?

Will I be able to learn what other people are looking for in their Graph Search queries (e.g. “friends who recently searched for divorce lawyers”)? If Facebook allowed marketers to query for that demand then they most likely would allow users to opt out of having their queries be captured in this way but then again people would have to be aware of that privacy setting and actually use it.

How recursive will Open Graph queries be?

If a user’s queries themselves become part of the Open Graph, then how many levels deep would Facebook allow queries of those queries (e.g. “people who searched for people who searched for divorce lawyers”)?

How Amazon Views the World

I’ve answered questions and also asked questions about Amazon that have received some attention.

This post is a longer (and more accurate) explanation of Amazon’s philosophy than is currently being offered on other blogs. There is quite a bit of speculation about Amazon but most people outside the company don’t understand how Amazon views the world and how that view shapes its products.

 

Earth’s Most Customer-Centric Company

It is difficult to overstate Amazon’s customer obsession and I imagine that the intensity of this obsession is difficult for some people to comprehend. Amazon values its customers *only*. That’s it. There is no higher goal and Amazon (and all of her employees) understand very clearly that they serve at the pleasure of the customer.

One of Jeff’s most famous quotes came from an employee all-hands meeting 15(!) years ago. Barnes & Noble had just launched their website and several analysts had declared Amazon dead. Jeff 

Also, it is important to note that Amazon now has many different customer groups (e.g. AWS “developer customers”, FBA “fulfillment customers”, Amazon.com “retail customers”) but for purposes of this post, you can think of any or all of them because Amazon treats them the same.

 

Cheaper, Bigger, Faster

If the Olympic motto is “Higher, Faster, Stronger”, then Amazon’s motto is “Cheaper, Larger, Faster”.

Specifically, every product and service Amazon offers is continually refined according to the following principles:

Lower prices

Bigger selection

Faster delivery

 

 

“Even well-meaning gatekeepers slow innovation.”

Jeff Bezos recently gave some insight into Amazon’s current strategy with his recent letter to shareholders. This was his money quote and quite concisely summarizes Amazon’s philosophy with regards to its partners. 

 

Fulfillment by Amazon, Amazon Web Services, Amazon.com are all self-service platforms. Yes, Amazon is a retailer too but it doesn’t care if you buy the product from Amazon the merchant.

 

Amazon doesn’t hate publishers any more than they hate companies that make toys or kitchen appliances. Amazon hates gatekeepers and that is exactly what publishers are looking like right now.

 

The thing about publishing, however, is that the tools for creation, distribution and consumption have evolved so quickly that (given Amazon’s background in books) it makes perfect sense to kill the gatekeepers.

If publishers think that Amazon is a tough negotiator with them, they should sit in on some of the meetings Amazon has with its shipping partners.

 

There is an easy way to tell who will be the loser in any debate about business and competition (like the current one about e-books monopolies): it is the one who never makes the case about how his strategy is better for customers.

 

 

My Most Productive Year

Almost one year ago I left my software development job at Amazon.com in order to pursue a more entrepreneurial life. If I were still at Amazon I’d currently be preparing for my annual review. This process involves comparing my achievements against my goals for the year, identifying things that I could do better, and setting goals for the upcoming year. This post is my annual review of my first year as an entrepreneur.

Goals

When I left Amazon, my plan was to spend about six months exploring potential business ideas, learning a bunch of new technologies that would be helpful for building web applications, and developing my personal network among Seattle’s startup community.

After the first six months, my hope was that I would have found one or more projects that seemed like viable startup candidates. If I hadn’t yet become fully engaged in my own startup at that point then I would also consider joining an existing startup or finding work as a consultant while continuing to experiment with my own ideas.

Achievements

Shortly after leaving Amazon I was presented with an opportunity to help out at TeachStreet. They were looking for someone to tackle some of the development tasks on their backlog and I was looking for an introduction to Seattle’s startup scene. The time I spent there proved to be a really great transition for me and because they were really open about how everything worked I was able to gain valuable insight into the daily operation of a successful startup.

While working inside a large company I often felt that I lost sight of advancements in the outside world of software development. In order to regain this perspective, I wanted to begin attending conferences and events where I’d get a chance to meet developers with different backgrounds and hear about the challenges and opportunities that they encounter. In addition to getting to my first SXSW this year, I was also able to enjoy a couple of trips to SF and Boulder for conferences like TechCrunch Disrupt, GoGaRuCo, and Defrag.

I met developers from all over the world at these events and one thing that really became clear to me during these conversations is that software development is splitting in two directions: prototyping and building for scale. I’d had several opportunities to do the latter (everything at Amazon needs to be built for “web scale”) but until this year I really didn’t have much experience with the former.

In order to improve my prototyping skillset I also began regularly attending “rapid development” events (e.g. hackathons and Startup Weekends). I discovered that I really enjoy the process of delivering a working version of an idea during a compressed timeframe and I have a strong feeling that this ability will become increasingly important so one of my goals for the next year is to spend even more time honing these skills.

Hackathons are also significant to me because it was during a hackathon event that I built the first version of Kindlegraph. Although Kindlegraph began in much the same way as many of my other projects, for some reason I couldn’t simply put it aside. As my six month self-imposed deadline approached, it became increasingly obvious that there was something compelling about the Kindlegraph product as more and more authors continued to sign-up for the service and promote it to their readers.

I’ve now incorporated a business (To the Reader, Inc.) around the general idea of building software for e-books and e-readers and I’m actively working on Kindlegraph as the first product.

Areas for Improvement

Now that I’m running a new business, I basically need to learn everything there is to know about running a business. As an example, I haven’t yet found a great way to manage all of the things that I need to do and as a result I’m constantly shuffling my priority list (although I don’t know if that is always a bad thing).

Another thing that is really difficult for me is asking for help. It’s not that I’m too proud but rather that I don’t want to bother other people with (what will certainly appear to them as) trivial and inconsequential challenges. However, I recognize that in order to be successful I will not be able to do it by myself and so over the next year I’m going to make a dedicated effort to enlist the help of others.

Summary

I feel like I’m still just getting started on the entrepreneurial path but I’m pleased with what I’ve accomplished this year. I continue to be encouraged by all of the opportunity that I see around me and I’m really focused on making progress everyday.

The best way I can describe the transition from working for a large company to becoming an entrepreneur is that when I worked for someone else, I sometimes wished the days were shorter. As an entrepreneur, I always wish they were longer.

The Lazy Startup

lazy lion || Fauler Löwe

‘Fast’ is the most overused adjective in startups today and it has been used to describe just about everything that startups do: move fast, fail fast, hire fast, fire fast, get big fast, etc.

Speed by itself is a fine quality but in the context of startups “fast” really means “go fast all the time”. Unfortunately, all that speed comes at a tremendous cost. I’m proposing that “constant high-energy activity” isn’t the most desirable quality for startups. In fact, it’s opposite (laziness) is actually much more preferable.

Let’s start by observing nature and specifically those animals that sit on top of the food chain. These animals (e.g. lions) all share the same qualities: predatory, strong, fast. However, the animals at the top of the food chain are also among the laziest in the entire animal kingdom. They understand that their survival depends on their ability to conserve energy until they spot an opportunity to kill. Only then do they transition into an extremely high-energy state and relentlessly pursue their prey.

What does this mean for startups? Don’t spend any more energy than is absolutely necessary. Especially don’t fritter away energy doing things that have no impact on customers just because that’s what startups are expected to do. For example, raising money, overengineering infrastructure, and writing too much code in advance of customer feedback are all things that many startups think they should be doing but can consume great amounts of energy and distract from things that actually matter to customers.

The problem with doing anything fast is that speed isn’t free. Spending massive amounts of energy just to go fast when the objective isn’t clear means that you won’t be able to accelerate when your prey is in sight. True predators understand that their energy levels are finite and failing to catch their prey just leaves them that much more exhausted and close to starvation.

Wantrepreneur to Entrepreneur

Mark Suster’s appearance in the Pacific Northwest last week set Seattle’s startup scene all abuzz about how we can improve the environment for entrepreneurs. In particular, Suster spoke about startups as a funnel which takes in entrepreneurs at one end and spits out real companies at the other end. As a first step, Suster said that Seattle needed to widen the funnel at the top (i.e. simply get a larger number of people who have an interest in startups into the system).

As a recent Amazon alumnus and new entrepreneur, I’d like to offer some observations about how people (particularly software developers) inside big companies view the startup scene and clear up some of the misconceptions that startuppers have about software developers inside big companies. Finally, I’d like to propose one solution for how to entice those people who work inside a big company but have an interest in startups to actually make the leap.

It might surprise some people to hear it but there is a strong entrepreneurial tendency among software developers at big companies. We (software developers) are naturally curious about new technologies yet most of our day jobs don’t allow for us to learn and experiment with these technologies and the ideas they generate. As a result, almost everyone I worked with at Amazon was involved in one or more side projects and most of these people hoped their side projects would turn into something more.

During my last couple of years at Amazon, I developed a very strong desire to pursue something more entrepreneurial and so I made an effort to start attending many of the startup events around town. I felt like an outsider at first and when I explained to people that I still worked at a big company their responses made me feel that I wasn’t taking entrepreneurship seriously since most of them never believed that I would leave the safety of my day job.

But here’s a secret, the only reason I didn’t make the leap to entrepreneurship earlier wasn’t the pay cut. The bigger leap was moving from a place where I was surrounded by people just like me to something that was much more isolated. I needed to land someplace that would help me learn about all of the issues surrounding startups but more importantly I needed time to think about and try different ideas.

So what would the perfect landing pad be for someone leaving a big company? It would be a place where you could go everyday to find an open desk with fast network access and be surrounded by other people who are at the same stage in the process of thinking and building.

It would look a lot like a coworking space combined with some of the mentorship resources of programs like TechStars and YCombinator. It would have open enrollment as well as a maximum length of stay to provide a sense of urgency. It would encourage collaboration and team building and rapid prototyping.

It would be an ongoing series of Startup Weekends and hackathons. It would be a place where experts would come to give talks about new technologies and trends.

And it would be completely free.

So how much would this cost? Let’s estimate $500 per person per month for space, internet, and office supplies (note: every hacker already has a computer setup they would want to use). If you had a space that could accommodate 100 people and you limited each person to a maximum stay of 3 months, you could get 400 more entrepreneurs into the funnel every year for a cost of around $600k.

I think this place could exist mostly without rules or boundaries but I might propose two modest suggestions:

1. One day a week, everyone has to give a presentation of what they are working on
2. One day a week, everyone has to work on someone else’s project (Reverse 20% rule)

Please tell me why we couldn’t build this place in Seattle or why this idea wouldn’t work.

 

How to Succeed at Startup Weekend

For years I’ve heard amazing stories about Startup Weekend but I’ve never been able to attend because they always seemed to be scheduled on weekends when I had previous engagements (like the birth of my son). This past weekend I finally had the opportunity to participate in a Startup Weekend event in Seattle and I was not disappointed. The organizers were fantastic, Madrona Venture Group were wonderful hosts and the attendees were all top notch people. In the end, my team and I built a platform for community sorted data called Crowdsort.me and we were awarded first prize for the weekend.

If you’ve been considering attending Startup Weekend, I would highly recommend it and I’d like to offer the following pieces of advice so that you too can have an awesome experience.

Find a great team in advance

I had previously met several of the other Startup Weekend attendees and I had even previously worked with a small handful of them. After hearing the opening pitches on Friday night, I looked for the best combination of a compelling idea and a team of people with whom I felt comfortable. Ultimately, I joined a team comprised mostly of guys with whom I had already worked and that turned out to be a big benefit. Not only are those guys (Hi Matt, Joe, Scott, and Harold!) straight-up ninjas but they are also among the most humble guys I’ve ever met. We were able to be amazingly productive and collaborative at least in part because we didn’t lose any time arguing or engaging in petty squabbling. We made decisions quickly and we trusted each other’s instincts.

Simplify, Simplify, Simplify

When the weekend got started, we were all starry-eyed about the amazing things we’d be able to do with our product once it was built. Daydreaming like that is great fun but you should very quickly return to reality. The first task shouldn’t be figuring out all the cool features you could add but rather how many features you can strip out before you simply don’t have a product anymore. One example from our team was whether we wanted to require users to sign-up for Crowdsort.me before they could use it. We talked briefly about the benefits of having user accounts (e.g. customer segmentation and data security) but we soon realized that we didn’t really need them for our simplest possible version and in fact we never ended up adding them to our product at all.

Get it working ASAP

One of the biggest points of emphasis of Startup Weekend is “customer validation”. The faster you can get to a working example, the faster you’ll be able to show it to potential customers and get their feedback. We had our first (extremely crude) version of Crowdsort.me running by 5pm on Saturday. Not only were we then able to start demonstrating our product but when we reached that milestone it provided a huge jolt of energy to our team. Our idea was alive and we could now start talking about where to take it next.

 

How Twitter Can Win Back Developers

Twitter kicked developers in the teeth last Friday with the announcement that third-party clients were no longer welcome. Many projects have already been abandoned and it’s impossible to estimate how many planned projects will now never see the light of day.
So what can Twitter do to win back the people who have played such a large role in its success? Twitter should reduce the restrictions on the creation and running of bots.

There are still several rich areas for experimentation in the Twitter ecosystem but perhaps the most fertile is in the area of allowing automated replies to tweets. There is so much latent demand being expressed on Twitter and up to now there has been no easy way to interact with this demand.

So how can Twitter open up the floodgates while keeping a lid on potential spam and other problems that come along with allowing bots to operate more freely? Obviously we need a framework within which these bots could operate.

Here are some simple guidelines for such a framework:
1. Bots should be clearly identified as bots. I’m proposing the introduction of a second type of Twitter account that developers can use specifically for this purpose.
2. People should have the ability to opt out of seeing bot replies and they should have tools to mark bots as spam.
3. People should have the ability to mark helpful bot replies as helpful.
4. The replies from bots that receive a high number of helpful replies should be ranked higher than other bots.

I’d love to have a conversation with anyone who wants to more fully explore this idea.