An idea came to me on my Citi Bike ride home today. It's not throught through but I decided to share anyway.
Advertising as distributed computation power
Include a "Power Pixel" on every ad served. The pixel would fire off a request to a third party Power Platform that returns some computation that needs to be complete. The computation returned can be optimized based on the website / device being used (ads are likely on page for longer on content sites versus photo sharing sites where you just skip from photo to photo). If the computation is completed in time, a solution request is sent back to the Power Platform with the answer at which time another computation request could be returned. The Power Platform also has to determine which computation to respond with based on other computations that are out / unanswered.
Open Questions :
- Is the energy needed to run the Power Platform greater than the sum of all the disparate computations performed by individual PCs? If so, it's make more sense to just run the computations in the Power Platform itself.
- Who pays for this? Is it the company that needs the problem solved? Are they paying the advertiser, the publisher or the user?
- Is it worth it to distribute a problem into such small pieces as to be actually suitable for this sort of a solution? Pretty sure the answer is yes here.
- Will the time an ad is on page be enough to actually answer any meaningful computation?
We recently pivoted away from our consumer facing iPhone application at Rockerbox. It was a difficult decision to make, but the right one. It came roughly halfway through our accelerator program (ERA) which also added many other dimensions to the decision.
Lessons learned :
- Your app needs to be perfect : This is obvious when you think about it, but wasn't top of my mind coming from an adtech world where bugs are endless (or features if you ask some). Consumers won't put up with bad products. They have no patience for bugs, crashing, slowness or ugliness. I don't blame them - I have the same expectations for the apps that I use so I don't know why I expected differently from my users.
- MVP doesn't mean nonfunctional : We're so ingrained to just get a product out and see how it's received. This doesn't mean though that the product can be ugly or crashing. It does need to function fully. It just means the scope of what the product can do needs to be limited. Example : Spending a week adding another feature - bad idea. Spending a week tightening up all of the features you already have - good idea. Spending an hour removing a partially working feature - great idea.
- Distribution is the biggest challenge : This one is obvious but it's hard to get downloads. There are definitely strategies here that can help (search optimization, good keywords, timing of release with events) but overall, it's still difficult. Facebook advertising worked best for us - we were able to get CPIs to around $1.70 through regular FB ads. From what I hear, you can get this down to ~.80 cents with mobile app download ads (we made a mistake not doing that much earlier).
- Social features need to be authentic : We tried adding an "invite a friend" screen after every X number of swipes. These just failed. As before, this makes sense. I would never invite a friend just because it's asking me to. I wouldn't really even do it if they offered me something (except for Dropbox where I've done this). If you want people to share content, you either need a workflow that's inherently social (e.g. snapchat) or a mechanism that's genuine (for us, it'd be something like "share an outfit that you think a friend will want").
- Your story matters : Rockerbox is founded by 2 ex AppNexus employees. We had spent years in advertising. We had never made an application before, never made a consumer facing product before and had no background in fashion. This doesn't mean that we couldn't succeed (in fact, our usage numbers were pretty good). It just meant that the story that we told (to potential customers, investors or mentors) didn't really make sense.
- Getting press is hard : It's doable, but takes a lot of work. I now give more credit than I used to to PR / marketing people.
- FOCUS : For us, all that really mattered is building the best product we could have because that's what actually gets users. Everything else that I did was a waste of time.
I believe Rockerbox could succeed. Our usage numbers tell me this (some people would go through thousands of products in one session - obviously, an extreme, but on average we were seeing good usage too). Our users were reaching out to us and saying how much they liked our product (tweets like 'Just started and no one can make me stop'). However, it wasn't the best place for us to be given the opportunity we're currently in with our accelerator program.
Final product :
Lean is in. Releasing early is the rage. Getting feedback as quickly as possible on your product has become an axiom of startup development.
One thing that this doesn't address though is what should be included in your first release. For your product itself, the typical answer here is the MVP - that is, the narrowest product scope that conveys your vision while allowing you to gather user feedback. This makes sense for the product itself as features are endless -- you can quickly get sucked into a black-hole of adding more and more without ever releasing.
However, if the core value of your product is to act as a conduit to data (hopefully in some new and innovative way), how do you define the MVP of the data set that is made available via your product.
There are three approaches that I see.
1) Shotgun - Include a small percentage of data about each entity within a set.
2) Sniper - Providing a lot of data about one entity within a set.
3) Shotgun & Sniper - Including all of the data on all entities within the set.
For a concrete example, lets say I have an awesome new way to visualize sport data. I made a product MVP - it implements 10% of my visualization idea, enough to let users know where the product will head but not nearly polished to my desire. Sounds right to release from a product MVP perspective to me.
What data should be included with this though? Using my three approaches from above, I could
1) Shotgun - Include one top line metric about every athlete in every major sport in America.
2) Sniper - Provide 80% of the data on one league (NBA).
3) Shotgun & Sniper - Get all the information on every athlete, team and sport out there. Obviously the best, but will take too long to do in any MVP type fashion.
I've been thinking about this a lot lately and am leaning towards the Shotgun approach. I think it's better from a feedback perspective in that you'll not only get feedback on your product idea/implementation but you'll also see which sport users are engaging with most (continuing the example from above). This will allow you to focus your energy on the most converting sport initially while you continue to build out your product and data set. This also allows for a more focused user acquisition strategy.
In essence, the Shogun approach allows you to more intelligently know where to Sniper next (Shotgun -> Sniper) as opposed to just picking the Sniper blindly. There are obvious alternatives here that probably should be done to aid this process (asking users, making different signup pages for each league and seeing which converts best etc…).
Also, the sports example isn't that great because the datasets are somewhat limited (probably a naive assumption but I'm going with it) and there's likely one source/API where you can pul all the data from. When the data set gets larger though (e.g. wanting to be a portal to all the products in the world - TVs, Guitars, Shirts, Cars), you can see how this problem grows quickly and solving it becomes even more relevant.
On March 1st I left my job at AppNexus.
Leaving was a very hard decision to make. I had been there for 2.5 years. During that time I saw the company grow dramatically in every dimension : employee count, QPS, number of clients, amount of money flowing through the platform, bottles of Sriracha ordered per week ... the list goes on and on.
I learnt more during those 2.5 years than I ever expected prior to joining. I got to see a nascent industry develop right before my eyes. I worked with some of the smartest and most passionate people that I've ever met. I witnessed the highs and lows of being at a company that's moving at light-speed - both sides of which teach you valuable lessons. I had the opportunity to take on many different roles - account management, technical account management, starting a team, hiring, product management. I got to partner and work with some of the biggest companies out there (I vividly remember how excited I was the first time I got to go the Google and Facebook offices).
It was a great experience and I have many people there to thank (normally, one would list those people right here but I'm going to skip that step as they know who they are).
When I came to AppNexus, I told my parents "I'm using this job as my MBA." As I've never got an actual MBA, I can't say whether or not that statement has any validity. At the same time, I can say that because of AppNexus I believe I'm substantially more prepared to venture out on my own than I was prior.
So why did I leave? 1) To put my "MBA" to test. 2) It was simply time for my next adventure.
That next adventure is Rockerbox. It's still very early but take a look (and sign up!).
I've recently become interested in Airbnb and how to effectively set your apartments rental pricing.
I've only used Airbnb once to date (it was while I was on vacation for 21 days this past December). During this time I was able to earn my entire months rent. Not bad for 14 days worth of work.
I'm not actively looking to rent my apartment. At the same time, I'm interested in how much I could theoretically get if I were to rent it. I guess my economic background (college major) is coming back to me.
I put up my apartment on Airbnb for $95 a day. How did I get to this number? I started by looking at apartments of a similar size / quality in my area. It seemed like the going rate was ~$100. I figured I could undercut the market, steal all of the demand and book my apartment throughout the month.
Experiment 1 : $95 - 12 rental offers next day.
I'm in business!
Experiment 2 : $140 - 14 rental offers next day.
This seemed strange to me. I raised my price and the demand went up? My friend Eric commented that "accommodations are one of those things where low prices scare some customers" - I think he's right here.
Experiment 3 : $190 - 0 rental offer next day.
I got too greedy.
Experiment 4 : $180 - 1 rental offer next day.
Back within the realm of reason. However, still too high.
Experiment 5 : $170 - 4 offers next day.
I've kept my apartment at $170 since then. I'm getting a steady stream of offers every day (between 3 and 5). Broadly speaking, it seems like I've found my price point.
This whole process made me realize that an Airbnb pricing optimization company should be built (or Airbnb should do it themselves - the problem is which side of the market should they serve? The sellers or the buyers?).
Things pricing optimization startup should do :
- Put some sort of tracking pixel on the apartment's Airbnb page. This would allow the company to track how many more / fewer people are getting to the apartments page as the price varies.
- It would be great if they could pixel the search results page. That is, allowing the company to know how often the apartment is coming up in searches based on how they change the apartments price.
- Automatically adjust prices based on the pricing of other apartments in the area.
- Automatically adjust prices based on availability of the other apartments in the area. If you're apartment is in the East village, and all the other apartments in the area are booked, your apartments listing price should rise.
- Take into account holidays / weekends.
- Do some analysis on photos of other apartments in the area to determine a relative quality index.
- Factor in amenities available veruss others in the area. How does adjusting these amenities change price?
- Airbnb allows different fees (a cleaning fee comes to mind). Would a buyer that's not willing to pay $180 a night pay $170 with a $20 final cleaning fee?
- Another thing that matters is how often does the seller actually want to rent their apartment. In my experiments above, I did get 1 offer at $180. If that one offer is at the right time, why lower the price?
What would the companies pricing model look? They could just take a flat % of the final rental price but they would need to be able to prove to the seller that they're making them more money. Also, would this become similar to the realtor problem where the realtor is incentivized to sell a house quickly (and make some commission) rather than wait out for small gains in the price?