17 5 / 2013
When marketing your (startup’s) product, it’s really important to understand whether the department that will be paying for the cost of your product fits into a cost-center vs. a profit-center portion of their budget.
In other words, does your product primarily save your customer time & money (cost-centers), or primarily generate more revenue for them (profit-centers).
Looking back at products in these segments, the barriers to sale are actually quite different. Cost-center savings oriented products, like product management tools, ERP, etc, generally need to be 10x more cost-effective than the products they compete against, because switching costs are generally high (because of re-training, for example). However, Profit-center increasing oriented products generally only have to be 1% better than the products they compete against; more revenue is easy to measure, and usually switching costs are low.
This generally means that sales cycles are also much shorter for profit-center increasing products, because every customer is willing to try. On the other hand, the barriers to entry are much lower for competing products, so innovation has to keep an incredibly fast pace.
Real life example: Groupon’s sales cycles were incredibly short, and revenues grew like a weed; but they couldn’t keep up the innovation required. Conversely, Square’s sales cycles are comparatively long; but it’s going to be hard to unseat them.
Lesson: understand what mode you’re in. If you’re a cost-center, raise enough money to survive longer sales cycles. If you’re a profit-center, setup the product to allow revenues to grow like a weed, but keep the whole company incredibly agile, so when your product has to change, the organization can keep up.
16 5 / 2013
03 5 / 2013
The more I’ve been using Fork & Pull Requests in GitHub, the more I’m convinced all information should be modified in this fashion. From scientific research to wikipedia (and obviously, for software)
02 5 / 2013
30 4 / 2013
If the 1990’s & 2000’s were about Inter-Personal Computing, the 2010’s will be about Inter-Informational Computing. Where we actually start using the massive amounts of data being collected, and combining them together from multiple sources.
30 4 / 2013
22 4 / 2013
I’ve finally realized what bothers me so much about Google’s AppEngine compared to Amazon’s AWS Suite.
AppEngine is a highly opinionated product; “use our approved stack or use another provider.” Generally, I’m a huge fan of opinionated products, because standards & conventions are fantastic for productivity. That’s why I love Apple products and the Rails web framework.
However, AppEngine is a product for hackers, who love tinkering. For the same reason that the Apple II had to have expansion slots for hackers, AppEngine is just too constraining of a stack to be a product for web developers.
That’s compounded by the fact that the majority of applications on Google’s AppEngine are going to find themselves being forced to also use Google’s BigTable implementation. Well, that’s a pretty huge investment on the developers’ part, because BigTable isn’t really a standard that’s easily deployable on other cloud providers. So if you’re writing for AppEngine, you probably will have to stay on AppEngine or suffer a rewrite of your data logic layer.
If anything, AppEngine is more accurately compared to Amazon Elastic Beanstalk, not lower-level services like Amazon EC2 or Amazon OpsWorks.
AppEngine is a product/service to be sold for hackers, yet is a fully-enclosed-system that can’t be tinkered with. That means they are selling a consumer-like offering to an audience where a massive percentage of it wants to hack the hell out of it!