Lean Startup in practice at PHP Fog

I’m going to show you lean startup methodology in practice by walking through a set of iterations and experiments we followed with PHP Fog to ship a new feature.

We are a PHP PaaS  (“cloud-based PHP hosting service”) and customers host their sites on our service.  Potential and existing (and lost) customers asked if they could use their own SSL certificates for their own domain name, a feature we called “custom SSL”. We needed to build this feature, we just didn’t know the details.

This was a highly uncertain feature. There were many things we didn’t know: (1) if people were willing to pay for this, (2) how much they were willing to pay, (3) did they need to update, or was creating/deleting sufficient, (4) whether they needed them for root level domains (foo.com) or sub domains (bar.foo.com) or both. Asking these questions wouldn’t yield great results, we had to design experiments to test our hypothesis.

Here it goes…

Iteration 1: Are people willing to pay for support of SSL certificates of custom domain names?

Our hypotheses was that people wanted “custom SSL” and they were willing to pay $20/month. You’ll never get a good response when you ask a customer how much they want to pay for a service. The true measurement is their behavior when they have an opportunity. Ask me how much I’m willing to pay for an iPhone, I’ll say “no more than $200″; I just spent $450 to get the iPhone 4s.

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.

Iteration 2: automate SSL certificate uploading

In iteration 1 we learned that customers were willing to pay for the service. So in this iteration we automated the process for creating custom SSL certificates. This orchestration was actually quite complex and it took two weeks to implement this feature into production. In other words, with only 1/2 day of work in the first iteration we bought the insurance we needed to invest the two weeks to build this feature.

Iteration 3: Do people need to modify and terminate those SSL certificates?

Our hypothese was that people needed to modify them and delete those certificates. Now you might be thinking “wait a second, you mean you added the ability to upload certificates but not to delete or modify them”. That’s exactly right. This may sound crazy, but this is where we were surprised.

The experiment was to automate the process of uploading them, but to delete or modify them customers would have to go through support channels like chat, email, or our support app. We expected to get mildly cranky and impatient to have to go through the slower support channels as opposed to doing it themselves through the UI.

We learned that our hypothese was actually wrong. As people started using SSL certificates it was actually quite rare that they needed to modify them and delete them. The few times we did have to delete them was when a customer uploaded the wrong values, but that was relatively rare. Deleting and uploading a new one was a good way for modifying, we didn’t need to explicitly support modifications.

Iteration 4: implement deletion of SSL certs

We implement SSL certificate deletion because it was only a week worth of additional work. Since previously this was a manual process that customers had to initiate by reaching out to support, we know what the long term custom was going to be to support this manually; it wasn’t going to take long for us to get the return on investment.

We did NOT implement SSL certificate updating/editing. Instead, customers can delete and then create as needed. We could have chosen to implement updating SSL certs with no downtime and it would have costed us a week or two, but there has been no demand for this yet. Deleting/Creating with very little downtime was good enough.

 Iteration 5: do people need SSL certs on the root-domain?

Our hypothesis was that our customers would want SSL certificates for root level domains (e.g. foo.com) and for sub-domains (e.g. bar.foo.com). Technology only allowed us to support the sub-domains and not the root-level domains. We could have added support for the root domains too, but that would be a few more weeks of work. This was a hypothesis we were hoping was wrong.

The experiment was to explicitly spell out these restrictions on the SSL uploading page and to give opportunities to provide feedback. Typically this doesn’t suffice as a good experiment because it assumes that if something is not working that customers will voice this; more frequently they’ll walk away from the service without a word. However, we’ve have an AMAZING track-record with our customers providing feedback about shortfalls so we felt like it was sufficient proof.

We learned that our hypothese was wrong again, just as we had hoped. Turns out that customers were willing to work with SSL support for sub-domains only.

 

Share this post

Try AppFog: The new PaaS Hackers love