April 29th, 2013
I just finished our fourth week of the Microsoft Accelerator power by TechStars. These are the top things I learned in this first month which I think might be helpful for other entrepreneurs in accelerator programs.
1. Own the intro
“The intro” is one of the tools you need to master. A few basic rules. Every meeting should end with an intro to the next person. Learn to craft a good forwardable email, one that includes your intent, basic info about your company, and makes it as easy for the forwarder to loop in the next person.
2. Talk to customers, then talk to more customers.
The only way you will learn is to talk to customers. When you get all the customers you can handle, schedule even more. You need to talk to at least 30 before even suggesting an MVP.
3. Turn assumptions into facts.
Draw your business model, identify assumptions that need to be true for your business to work, and turn those assumptions into testable hypotheses. Prioritize them based on risk and start testing away.
4. Listen to your managing director’s advice.
Your managing director of the accelerator has seen countless startups evolve. They know what it takes to succeed.
5. Help your peers
Support your peers in whatever way you can. You are on a lonely journey but you have comrades. Share what you learn, what works and doesn’t work, and help out with intros.
6. Be aggressive
This means you have to follow up on every introduction immediately, always ask for introductions in meetings, ask your mentors to help with specific challenges, keep track of your relationships, demand help from your program, send update emails to your mentors, etc.
7. Start raising now
Closing a round can take 6-9 months. Do you want to raise a round after demo day? If so, you need to line up the investor interest now.
8. “Tell me the last time you…” and “why?” are your friends
Instead of asking “would you [x]” you ask “when was the last time you did [x]”. Then follow that up with “Why” five times. This way you will learn what people actually have done, not what they would do in hypothetical situations and you will learn what motivates them. You can use this technique with customers, business development, investors, etc.
9. Plan your demo day now
The phrase “if you build it, they will come” is equally untrue for customers as it is with promotional marketing. Start building your army of fans now so you can make a big splash at demo day.
10. Sport your brand
Every single day I wear the green Factor.io t-shirt, black hoodie with the logo on the back, and matching shoes (that last one is a coincidence). If you aren’t your biggest fan you can’t expect others to be either. I got enough shirts for the accelerator staff, customers, investors, and advisors. We now have fans just because people love the gear. Just from the last four weeks I am seeing tangible results.
We are also supporting a local Portland-based smal business making these 100% made-in-the-USA t-shirts.
It’s called an “accelerator” for a reason.
You will be doing in 3 months what typically might take you an entire year. Clear out your calendar for these three months so you can take full advantage of this opportunity. I recommend going into a program in a city that isn’t near where you live. It is emotionally tough being away from your loved ones, but my wife supports me 100% in this venture and I couldn’t do it without her.
April 1st, 2013
It was officially announced by Scott Guthrie, President overseeing Microsoft Azure, that Factor.io has joined Microsoft Accelerator for Windows Azure, powered by TechStars. (known to some as “TechStars Azure”)
Why join the Microsoft Accelerator?
Our decision to join the program didn’t come lightly. First off, we were bootstrapping and it was working out quite well for us. Secondly, our list of incubator programs we considered joining was incredibly short. The most important criteria were: (1) access to amazing mentors, (2) great track record, (3) focused on our target market, (4) directly helps us build new partnerships. This program hit all of our priorities spot on.
What will Factor.io bring to Microsoft?
We believe in mutually beneficial relationships. While we will reap many benefits of the program, we also want to reciprocate. In short, we will drive growth for Windows Azure in very direct ways (using it for our service), and indirect ways (evolving the ecosystem by helping Azure integrate with our channel partners).
What does this mean for Factor.io?
In the next couple weeks we’ll be on-boarding our first set of private beta users. Over the next three months you can expect us to launch Factor.io into public beta and general availability. We will also be adding integration with Azure so you can easily include Azure with your continuous delivery pipeline.
February 19th, 2013
We are proud to announce we now support the Heroku channel in Factor. This means you can perform operations like scaling, deploying, listening for logs, and more on Heroku.
While you can do some really cool things now with Heroku, we built this channel because there was one particular workflow on high demand: Deploy to Heroku from Github on post-receive events.
To demonstrate this capability, we created a workflow that looks something like this.
- Listen for a post-receive web-hook from Github.
- Using the Github channel download repository.
- Using the basic channel unzip the repository.
- Using the new Heroku channel, compile and deploy.
- Using the Twilio channel, send a text message with the last check in message and the Heroku release number.
This workflow was built in just 1 minute and works perfectly.
While we could have built all this using git, we wanted to keep it web API focused. That’s right. Gtihub supports downloading repositories using their web API, which provides a Zip archive of the file. Heroku also supports compiling and deploying using a web API as opposed to git.
January 31st, 2013
People who want to automate their lives come to Factor.
This is an interesting lesson I learned over the past couple weeks since I announced Factor. Factor is a service to help automate and integrate the development workflow like your continuous integration/deployment process. However, as I am learning, people are interested in Factor for an even bigger goal: automating their lives.
Every new users to Factor gets asked a few basic questions: (1) What kinds of apps do you build, (2) What is the primary benefit you would get from Factor.io, and (3) What kind of person do you think would benefit most from Factor.io?
Based on these questions here are a few themes I’ve been discovering:
- Developers love automating their lives.
- Ability to create custom triggers/listeners is a hot selling point for developers.
- Automation helps save time and make you generally more efficient (this is an obvious one). However…
- Automation also helps with reducing risk and errors. By automating something you won’t ever forget to complete the task and you can also be sure it will happen consistently ever time.
For those unfamiliar with the service, you can think of it as “IFTTT for developers”. It is easy to create simple workflows like IFTTT; however, Factor is designed for developers with a few extras. Developers can create their own triggers and channels. The workflows can be a set of chained events, not just a simple IF X THEN Y statement. The execution agent can run locally so you can manipulate your own servers.
Signup here
Learn more about Factor here
January 29th, 2013
A Unix Pipeline is a set of processes chained by their standard streams, so that the output of each process (stdout) feeds directly as input (stdin) to the next one.
The Unix Pipeline was invented by Douglas Mcllroy after noticing that much of the time he was processing the output of one program as the input to another. The idea was implemented 40 years ago, back in 1973 by Ken Thompson.
This very basic but powerful tool solved the problem of fragmented command-line tools which needed to work cohesively. This same problem exists today with the web. Unlike the CLI, the web is even more fragmented. Documentation in Unix was standardized with the man-pages while on the web we have countless websites for docs, many of which are quite poor. In fact, my friends Eric Redmond and Troy Howard are organizing the “Write The Docs” conference to address this issue. The Interface in Unix was pretty simple stdin/stdout while on the web we are just starting to standardize on REST, but still a far ways away. In Unix we had a single format, strings, while on the web we are also starting to standardize on JSON, but there is still this crazy thing called XML around. In Unix we have an awesome authentication/authorization model, while on the web we have a shit show with OAuth1, OAuth2, OpenID, tokens, custom systems, etc.
The good news is that help is on the way. Yahoo Pipes got the ball rolling 6 years ago, but halted and failed. Now companies like IFTTT, and Zapier are picking the momentum with great adoption and pretty awesome interfaces. They are building the Unix Pipes for the Web!
Factor.io is another player in this arena, though a newcomer. Factor provides the interface to connect to each of the various service providers and frameworks. Unlike the predecessors, Factor has a few key differentiators.
- You can run the workflows locally, so it can manipulate your own system or servers (e.g. Shell, Chef, Puppet)
- Create your own channels so you can use the popular channels which are already supported, or add your own. Feel free to share them too.
- Don’t be limited by a single pipe, you can chain together pipes through many steps. You can even execute multiple actions at once.
If you’d like to check out Factor, sign up here!
January 28th, 2013
For products which tailor to developers, documentation is one of the most important data points for deciding to use a particular library or service. For example, we used AngularJS for the development of Factor over any other MVVW framework because of the great quality of docs. Great docs lead to great code and productivity.
Documentation is a part of the user experience. This includes the API/Reference docs, samples, and tutorials. Being a part of the user experience we wanted to treat it like it was part of the design, as such “DDD” or “Docs-driven development” was born.
Docs-driven development is to docs what test-driven development is to test. It starts by the developer writing the documentation for a particular scenario. The scenario includes sample code and process. After that, they build end-to-end tests which describe the process defined in the documentation. Thereafter, the test-driven-development process kicks in.
The tutorial “Deploying to CloudFoundry from Github,” was used as the first model for this process.
January 22nd, 2013
Factor is a service to make it easy for developers to define and integrate their continuous deployment and integration workflow. Development teams spend over 30% of their developer resources building the process for deploying and managing their apps and infrastructure, like “Deploy my app to AWS when I push to Github”. Most of this time is spent glueing together numerous services (e.g. Github, AWS, Hipchat) and technologies (e.g. Chef, Salt Stack) to work in a cohesive workflow. Factor relieves developers of building this veneer layer of glue by connecting all the services and technologies using a simple workflow.
January 15th, 2013
When Yahoo! launched their Pipes platform in February 2007, it immediately sparked my interest as an incredibly promising way to get a lot done without having to implement everything from scratch. After all, like most folks, I’m always looking for shortcuts and am eager to adopt third-party tools—provided, of course, that they Just Work. Unfortunately, Pipes is now six years old, and today, even after all that time, it lives on far more as a toy and a curiosity than as a full-fledged tool.
I think that we can attribute this to six crucial failures on the part of Yahoo!:
1. Jack of some trades, master of none
Because Yahoo! Pipes seeks to do only a few things, we can’t fairly label it a Jack of all trades. And even though it seeks to master only a few things, it only does these things somewhere between moderately well and poorly. No one can say with a straight face that Yahoo! Pipes is the great [insert X here] in the world.
2. Rough UI
While Pipes’ UX isn’t so bad, the aesthetic design is quite poor. In its six years of late, it has barely changed. While this is admittedly a perception issue, let’s be honest: if something looks and feels dated, it’s a major turn-off. Simple as that.
3. Only as powerful as its channels
Given the distributed nature of modern applications, a platform that enables integrating numerous services is only as powerful as the channels to which it connects. If a platform is limited to just a few very basic APIs (e.g. Flickr, RSS) then the value of the platform is very limited. Its value increases substantially as it adds valuable and more up-to-date channels.
4. Not extensible
The functionality/connectivity of Pipes, as I have said, is quite limited. If users want it to be more valuable, they have to extend it themselves. It would be far more useful if users could extend it for their own accounts, or better yet, enable community contribution of new functions (i.e. open source).
5. Lack of investment
Judging by the Twitter account, Pipes gets virtually zero marketing love. There aren’t a whole lot of new developments or things to share either. It’s simply been stagnant. Not exactly confidence-inspiring.
6. No discernible business model
You can’t fund a product when you don’t make any money. The minds behind Yahoo! Pipes either failed to discover a sustainable business model or never even made the attempt. Whatever the case may be, without traction there is little point in continuing the product.
Far all of these reasons, Yahoo! Pipes is yet another once-promising project that seems almost entirely bereft of life. Which is a shame, because the essential thrust of the project—enabling people to stitch together APIs into a single interface more valuable than the sum of its parts—was one that was (and is) worth carrying through to completion.
I am not an executive at Yahoo so I won’t get a chance to grow Pipes passed its awkward adolescence to the beast it could have been. I am, however, doing the next best thing: I am building Factor.
January 15th, 2013
http://factor.io/docs/tutorial/deploy_from_github_to_cloudfoundry
We love Cloud Foundry, the open-source platform-as-a-service for hosting. We also love Github for manage code and collaboration. However, there is no mechanism to automatically deploy our apps to Cloud Foundry when we push to Github… until now!
This tutorial demonstrates how you can create a workflow in Factor which listens for post-receive hooks from Github, download the code, uploads it to Cloud Foundry, restarts the app, and send you a text message when it’s done. What’s amazing is that you can do this in under 5 minutes with Factor.
Don’t forget, before you can use this tutorial you need to register.
January 14th, 2013
Over the past few months I’ve interviewed about a dozen 5-200 employee companies including AppFog, Vizify, Sprintly, Urban Airship, Kontagent and Cloudability. This was all part of my customer development process for building Factor.
As a startup you are lean and agile, which also means you are likely implementing a continuous integration and continuous deployment process. CD is a process whereby all code that is written for an application is immediately deployed into production. The result is a dramatic lowering of cycle time and freeing up of individual initiative.
All companies require a continues deployment process! Nobody is in the business of building processes, they are in the business of delivering value.
Developers are burdened with the necessity to build the CI/CD process, but none of this delivers direct value to the customers. They would much rather use that time to work on the product. I’ve seen about 20-30% of developer resources being spent on building the process to deliver the product, not building the product itself.
It is Factor’s mission to make it dramatically easier to deliver software by automating and integrating the continuous deployment process.
With that in mind, there are a few key requirements I must keep in mind.
- While the goal of each CI/CD process is the same, the implementation of each is very unique.
- Every company has already invested in best-of-breed tools for their process like Github, Jenkins, Heroku, Open Stack, Salt Stack, Chef, Puppet, etc. Factor will compliment all of them, not supplement.
- Most of the work of Dev and DevOps is glueing the different technologies together, rarely are they implementing new platforms/frameworks.
Twitter
Blog
LinkedIn
Support
Facebook
