Open Source for Profit

November 6, 2012 Entrepreneurship / Random Thoughts
No comments

I was recently asked whether Launcher was open source. This warranted a bigger question, “why should for-profit companies open source”?

Companies often open source for a variety of reasons. Here are a few. However, I firmly believe that open source is a great strategy to help the bottom line. The gold is in the ecosystem. Here are the reasons why I think companies should open source and how it helps them reduce costs or generate new revenue.

No vendor lock-in is a competitive advantage. When building any kind of service people (companies in particular) are worried about lock-in. If your product is open source, you can tell your customers ”We provide the best service, but if you don’t like it, you can run it yourself”. This will force you to think about your value proposition too. It’s generally not a good idea to consider your code or IP as your unfair advantage (unless you are in pharma).

Creates promoters. Customers are the best marketers and you don’t even have to pay them. You have to turn those customers into promoters. This can be done with any product, but there additional ways of turning those customers into promoters as an open source solution. You need to enable the community to contribute (this is very hard and I see this screwed up all too often). But if you do, you will have created champions out of those developers.

When customers win, you win. This is one thing that WordPress kicked ass at. Look at the huge ecosystem WP has created. There are businesses formed around WP, like plug-ins and themes. If you enable contributors to win (financially), they will bring you the customers. You should always think about how you can help your customers win, open source happens to be a great option.

Outsource development. If you build the right support framework, you can get the community to contribute to your product. This is huge. Developers are expensive and yet there are developers who will do this for free (as far as money goes). This is tricky because you do need to support them technically as well as giving them the social credit.

Outsource support. When a product is open source, many people try it out. They will find bugs, they will find solutions, and they will discuss those solutions. StackOverflow is an awesome community for such developers. So when you have a customer who stumbles across a problem, they won’t need to depend on you exclusively for help; they can ask the community.

Taking the big leap

October 29, 2012 Entrepreneurship
4 comments

I’ve been preparing for this almost my entire life. I am leaving AppFog to start my own company.

As a new beginning, it’s an end to something that was already great: working at AppFog as the Director of Product.

Back in November 2009 I was planning my exit from Microsoft to start my own company. It was around the same time I read a TechCrunch article about PHP Fog getting their Series A round. As a guy who helped build the PaaS offering at Microsoft (Azure) and a former PHP developer, this was right up my ally. I knew I wanted to be a part of it. Through mutual connections I got an introduction to Lucas, and not long after I had joined the company as the first non-engineering employee.

It was the wild west. I was wearing dozens of hats: community manager, business developer, marketing, product manager, everything. There were hundreds of people at the time using the service, and a few thousand on the waiting list. I saw a lot of things happen in the evolution of the company since then…

Through the process I learned more than I could have fathomed. I learned about customer growth, honing product/market fit, positioning, pivoting, actionable metrics, hiring, hacking, team culture, and a whole lot more. Most of all, I learned by working with some of the most talented people in the industry. Of all the things that I’ve done in my life, working at AppFog for nearly 2 years has prepared me more than anything else.

What’s next? I have an idea in mind which I will soon share and launch after getting more customer validation. One thing I can say for sure: I will be playing to my strengths by scratching my own itch in the developer and cloud computing market.

Rule #4: Just say ‘no’ to feature lists

October 23, 2012 Entrepreneurship / Lean Startup / Product Management
No comments

Feature lists have yo-yo-ed in and out of my career throughout the years. I kept them for products that had a several year release cycle. I also kept them for products that were highly iterative. In retrospect I realized that regardless of the shipping cycle, they actually provided very little value but a ton of overhead. The list also made me feel like the product was just such a tiny fraction of it’s potential and that it was just underwhelming. I finally got over feature lists and feel great without  them. Here is why I don’t need feature lists…

If you need to write down the feature list it is a red flag. This means one of two things. Either you are introducing feature creep and adding more that is really unnecessary. This can also be an indicator that your release cycle is way too long. If you work off a feature list and it takes you so long to work through the list, chances are that list will be irrelevant by the time you are done shipping.

If you need to write down the features on a list, chances are that they aren’t important enough to remember. If someone needs it badly enough you should be hearing about it non-stop from customers. If you aren’t hearing from customers at all, chances are you have a bigger problem on your hands: not having communication channels with your customers.

You are in the business of solving problems, not building features. That’s what customers pay for. Having said that, the features are actually not that important. It’s the problems you need to understand.

Lastly, don’t bother with feature lists. In fact, you probably don’t even need to try to remember any features at all. Instead, there is one very important piece of data you should know at all times: top 3 customer pain points.

The case for “good enough”

October 23, 2012 Entrepreneurship / Lean Startup / Product Management
No comments

We’ve all done it. We’ve all debated the design of a feature to get it right before shipping. We’re all guilty of thinking we know what the customers wanted based on anecdotes. And we’ve all been wrong doing it. Processes like agile development, and lean startup are designed to alleviate the risk and focus on shipping and iterating. But for those that don’t drink the cool-aid, you need to make the case for “good enough” to ship. The naysayers will poke holes in your “good enough”, but not “perfect” solution.

  • This is the solution that will get us to market the fastest.
  • This is the first iteration. Here are 3 more options on how we can improve on this in the future.
  • Buys us time to deliver on the bigger and better solution.
  • We won’t be disqualified when customers are looking for the “Supports [x]” feature when evaluating us as an option.
  • The feedback and what we will learn will be more valuable than us debating in isolation. Just about all the decision’s we’ve ever set we had to revisit and adjust.
  • If a customer comes and converts to paying, we win. If a customer comes and leaves because the feature isn’t good enough, then we will have lost a customer; however, we will have won a hell of a great qualified lead.
  • Winning this customer now will get us on-board for the long sales process.
  • We might not win big on this one, but we will now have an opportunity for cross-selling.

Don’t miss your 14,000 eyeball opportunity like I did

September 5, 2012 Lean Startup / Product Management
No comments

TRY SCOREPROMOTER

…it’s what this article is about.

Last Tuesday an hour before going out to dinner I wrote a blog article “Legal warning in under 6 hours after launch of ScorePromoter” and posted it to HackerNews. 5 minutes before leaving for dinner I had over 300 hits. By the time I got to dinner I was nearly up to 1,000. 12 hours later, I had over 7,000 visitors come to the site (that’s 14,000 eyeballs). Wow. That’s a lot of eyeballs. I missed my opportunity and I don’t want you to miss yours.

The timing was perfect. I had just launched ScorePromoter, a service to make setting up, running, and analyzing/segmenting NPS surveys easy. The article was about a little funny incident I had with it. I needed people to register for the service so I could start interviewing them for some feedback.

Unfortunately I had no idea that this article would blow up like that and I totally missed this huge opportunity.

The failure: Of the 7000+ people who visited the article, about 400 went to the ScorePromoter website, and of those only 6 people registered. I think that is one of the worst conversions I’ve ever come across in my career.

The problem(s): There were a few key problems in this scenario. First off, the distance between my end goal and the entry point were too damn far apart. Secondly, the conversion from visits to the website to registration was WAY too low which probably means my messaging is why the fuck off or entry point was not the target audience. Obviously I couldn’t have predicted such popularity, but there were a few lean-startup lessons I should have followed.

In retrospect, here is what I should have done. I’d love other suggestions too. I write this article so you don’t miss your opportunity.

  • Add a “Register button” to the blog.
  • Added that button to the side bar, and at the begging and end of the article.
  • Better yet, embedded the registration form, not just link to it.
  • Setup split testing on the homepage to experiment with different messaging. With so many eyeballs I could have tried many different types of messages; I can think of at least a dozen to try. Perhaps it’s never too early to start split testing. In this case the audience was a bunch of hackers, not product-managers/marketer types.

If you haven’t already…

TRY SCOREPROMOTER

Legal warning in under 6 hours after launch of ScorePromoter

August 28, 2012 Entrepreneurship
13 comments

First, let me start by saying that I totally deserve the legal warning and I already addressed the issue. But the story is fun nonetheless.

I recently built ScorePromoter (http://www.scorepromoter.com/), a new service to make setting up, running, and analyzing NPS surveys easier.

For those unfamiliar with NPS, it stands for “Net Promoter Score” and is a very simple loyalty metric system. This all sounds very fancy, but it’s actually really simple. An NPS survey just asks two questions: on a scale of 0 to 10 would you recommend this service, and why/why-not. There is a simple way to calculate the score too. More info here: http://www.netpromoter.com/why-net-promoter/know/. While the score itself doesn’t mean a whole lot, it is a great way to get customer feedback and it is used by countless companies (even startups).

On Tuesday morning around 10AM I made the first public announcement on Hacker News and on Twitter. By 4PM I had my first support ticket opened. It was from Satmetrix and this is what it said…

“I noticed you are using NPS and Net Promoter Score on your website without attribution. If you add the text below to each page where they appear, you’ll be in compliance.

Net Promoter, Net Promoter Score, and NPS are trademarks of Satmetrix Systems, Inc., Bain & Company, Inc., and Fred Reichheld.

Thank you, and let me know if you have any questions.“

 

This just cracked me up. I had a lot of thoughts about this.

  • Obviously I need to fix this.
  • 6 hours?! Damn, that was fast.
  • I don’t have much traction yet and I’m already getting warnings.
  • Are they threatened?
  • …or is that just wishful thinking and they are just being diligent.
  • At least they were nice about this.

Either way, it’s impressive that it only took a few hours to get my first legal warning.

 

p.s. Net Promoter, Net Promoter Score, and NPS are trademarks of Satmetrix Systems, Inc., Bain & Company, Inc., and Fred Reichheld

Rule #3: Fake it till you make it

July 22, 2012 Entrepreneurship / Product Management
No comments

Common sense tells us that you first need to build a product before people can buy it. If you build it first, will they come? Will they want to use it? Will they pay for it? How much?

There are many methods for mitigating such risk, but I’d like to talk about my favorite: fake-it-till-you-make-it.

When you building a product, you measure success of the product by usage and the money customers pay to use it. Wouldn’t it be great to get the validation from customers that they are in fact willing to use the product and willing to pay for it BEFORE you build the product?! That would be amazing. So instead of focusing on building a product, you should first focus on getting this validation from the customer. But how?

To get this validation from the customer you need to do two things. First you need to present them with the value proposition (this is what they are buying), and you need to give them an opportunity to express intent to buying/using it. Looking at examples might be easier.

Example 1: Landing Page

Use a service like Unbounce to build a landing page for your customer. On the page itself you publish your value proposition. In addition to that, you can provide a sign-up form. Once the customer signs up they would expect to use the service, but it is also equally acceptable to let them know that they are on a private beta waiting list. This is how Lucas launched PHP Fog, he started with a landing page with no product behind the scenes and got hundreds of signups in the first few days. This was the validation needed to launch the company.

Example 2: Manual feature

Here is a snippet from the article “Lean Startup in practice at PHP Fog” I wrote a while ago. In this case we weren’t building a whole product, just a feature.

Our hypotheses was that people wanted “custom SSL” and they were willing to pay $20/month…. The experiment is to present the opportunity to create SSL certificates and a method to pay for them. We set a price of $20 per month. Someone could upload their SSL certificate and then they’d be presented with a response asking them to wait 24 hours. Behind the scenes we opened up a story in Pivotal Tracker and sent an email to the tech team to implement this manually. It took only 1/2 a day to implement this feature. We learned that customers were in fact willing to pay for this feature and they were using it.

In this example we got validation for both demand and price all before we implemented the full automation of this feature. The fully automation would have taken weeks to implement. If you read the article, you’ll see we continued to use this method of validation in almost every iteration of the feature.

Example 3: Kickstarter

Kickstarter is quite possibly the most successful platform for putting “fake it till you make it” into practice. Kickstarter enables you to build a few prototypes just enough to demonstrate your product before figuring out how to build it at scale. You can start selling the product as a means for getting the funding. If  the project reaches the funding goal, you get the money to build it. If it doesn’t meet the goal, the project is canned. This platform is used often to build products that are expensive to produce, but it is also used by small software startup projects too (like Walker).

Building Open Jumpstarts

July 18, 2012 Cloud / Entrepreneurship
No comments

Open Jumpstarts is an open and free marketplace for developers to share their open source projects in a way for other developers to easily try and run those apps without the pain of setting up their server environments, configuration, etc. From start to finish you can launch an application in 20 seconds.

Motivation

Open source developers build great and amazing apps. However, the barrier to entry for getting other developers or even end-users to use those apps is huge. The developer who wants to try the app needs to setup a system to deploy that app, which includes setting up the environment, servers, configuration, etc. My motivation is to eliminate those barriers. As an app developer you can build your app to run on Cloud Foundry. Once you do that, you just submit it to the jumpstart directory with a few additional instructions. Thereafter anybody can launch this app on AppFog (or any other Cloud Foundry provider) with a single button. That button appears on the Open Jumpstarts website, but the developer can also add a button to “Try on AppFog” to their website with some simple Javascript.

Guts

The front-end is a RoR app built with Bootstrap, Less, HAML, and CoffeeScript and all of this runs on AppFog. The back-end is the same code-base, but it runs as a Resque job using the Standalone runtime configuration on AppFog. The Redis service is actually running on RedisToGo, as AppFog doesn’t yet support Redis (it’s coming soon). The back-end is responsible for deploying the applications which is about a 20 second process and orchestrates about half a dozen external API calls. Since submission of the job is asynchronous, the worker process provides feedback using Pusher.

Challenges

In the grand scheme of things, the entire process was actually not terribly difficult, there were only a few quirks I had to deal with.

The first was that Less has a dependency on TheRubyRacer gem which embeds the V8 Javascript engine into Ruby. This in hand has a dependency on libv8 which needs to be installed system-wide. Cloud Foundry doesn’t support system wide installation. However, this is actually really easy to work around. When I run the app locally I use Less. When I want to deploy to AppFog I first precompile all assets (‘rake assets:precompile’) which compiles everything and puts them into the public directory. I then remove that dependency from the Gemfile, run bundle install again, and then deploy to AppFog.

The other problem was that instructions for running the resque job wasn’t well defined. I found some documentation which required me to write a manifest file and use that to deploy. The manifest file defines the command parameter which instructs the Cloud Foundry DEAs to run that command for that process, which is how I start “rake resque:worker”. The command-line tools (af and vmc) do not support this as parameters, which is why it has to be put into the manifest file.

Next

The core functionality is all there. But there are opportunities to further improve capabilities of the jumpstarts and the overall experience. Here are things I’d like to improve next:

  • Ability to define arbitrary required parameters when defining a new Jumpstart. For example, if the jumpstart is a FB app, you could say that a “Facebook API Key” is required. When the user launches this app, they will be prompted for that parameter.
  • Create a very simple JS to include in a page to add the “Try on AppFog” button. While it is possible today with some simple jQuery, I want to make it dead-simple.
  • Integrate this with Cloud Foundry providers. I’d like to get AppFog to depend on this service to be able to query the public directory and enable people to launch new apps directly to AppFog from AppFog. I also have a user management model so folks within AppFog have a special permission which enables them to review and approve other people’s jumpstarts so they can be published selectively in the AppFog directory. This too can work for other Cloud Foundry providers, not just AppFog.

Plant monitoring station with Arduino + C + Ruby + sensors + WiFi + Cosm

July 8, 2012 Cloud / Hacks
8 comments

I have never grown a plant from germination to fruition. I want to grow my own produce. But frankly, I know very little about gardening. As I started reading about gardening I quickly learned that my living room was sub optimal (to say the least). While I can artificially change the environment, I first wanted to start by understand what my environment actually looked lik for the plant. Other than gardening my electronics and electronic circuit knowledge is fairly limited, so I wanted to expand on that as well. Two birds, one stone.

To build this monitoring station I had a few things in mind.

  • It had to work untethered to a router for internet (i.e. wireless)
  • Data is collected and visualized over time
  • I want to monitor the soil moisture, temperature, light, and humidity

Here were the parts I used to get this started.

I chose Arduino because it is easy for hacking, that is, getting started without having to deal with much lower-level BS. It is really easy to plug it into USB, write some code, and get the instant gratification.

The IO Expansion board technically wasn’t required; however, I only got it so I could easily connect the sensors to the board. This board turned out to be a great choice.

I also wanted WiFi connectivity. This was kind of a pain in the ass. Turns out there wasn’t any one standard or best choice for this. What I wanted was something like WISP by embdSocail, a KickStarter project. I funded the project, but the project didn’t reach it’s goal. I reached out to the guys behind the project and told him that I was interested in getting the board even at a premium price just so I could get my device connected more easily. In the mean time I needed something. Unfortunately the board the I chose for WiFi was a huge hassle for a few reasons. First off, the communication to the board requires using serial communication. This is the same method used to communicate between the Arduino and the computer via USB. The result is that Serial output in the code can be used to send commands to the WiFi shield or to USB for debugging (but not both), this made debugging the Wifi code super fucking hard. Secondly, there are two sets of jumpers. In one state they are used to enable the computer to control the WiFi shield, in the second it allows the Uno to control the Wifi and in the third (both jumpers out) is used to program the Uno from the computer. I had my sensor shield on top of the WiFi shield. This mean that every time I wanted to release new code I had to take off the sensor shield, take out the jumpers, deploy the code, put the jumpers back on, put the sensor shield back on, restart. OUCH! I bent a few connectors in the process.

Reading the analog signals is really easy. Reading the digital ones from the temp/humidity sensor wasn’t very easy. Luckily I found a library that helped out. It’s not easy because you actually have to read binary data and synchronize it with the clock. Not fun.

With the code I finally got to the point where I could read the sensors. The WiFi was all setup and I could connect to the device. TCP stack is supported; however, HTTP wasn’t supported. Being able to control the sockets is also really difficult. So it was nearly impossible to write a HTTP server or even client. Instead, I just created a simple TCP service. I can connect to it (e.g. “telnet 192.168.2.7 4000″) and it just starts sending me the data in JSON format. Every 5 minutes a new line would appear, here is the sample from the last 4 iterations:
To get the data from the board to the internet I decided to use a little agent that retrieved the data and pushed it to Cosm. The agent sits on my computer and pings the Arduino every 5 minutes to get a reading. The results are formatted in JSON. I used the Cosm gem to publish the data to the Cosm service. Check out my feed: https://cosm.com/feeds/63163. This little baby below is the agent.


It was incredibly fun hacking on something other than fancy we apps. Hardware hacking is great as it’s a rare opportunity to interact with the real physical world.

Rule #2: Don’t give your customers what they ask for

April 30, 2012 Product Management
No comments

Don’t give your customers what they ask for… give them what they need.

First one must understand why not to listen to the customer. Secondly one must understand how to identify what they really need. There are two very good methods for this, the first is to ask “why”, the second is to measure behavior of customers. This excellent quote from the GitHub team explains why you shouldn’t listen to customers when they make feature requests, and how they use the “why”-method to identify the deeper needs. I’ll leave it for another day to explain the other method of understanding customer needs (i.e. measuring).

Tom Preston-Werner wrote this in this blog “Ten Lessons from GitHub’s First Year“:

Here’s a seemingly paradoxical piece of advice for you: Listen to your customers, but don’t let them tell you what to do. Let me explain. Consider a feature request such as “GitHub should let me FTP up a documentation site for my project.” What this customer is really trying to say is “I want a simple way to publish content related to my project,” but they’re used to what’s already out there, and so they pose the request in terms that are familiar to them. We could have implemented some horrible FTP based solution as requested, but we looked deeper into the underlying question and now we allow you to publish content by simply pushing a Git repository to your account. This meets requirements of both functionality and elegance.

 

← Older Entries