I am writing this post after making the decision to kill months of hard work around adding invoicing to Skyclerk. We have decided to scrap everything and start over as the road we were driving down showed not to be the right path. We almost made the decision to finish up what we were working on, launch it, and then make it better over time. Iterative software development is a notion we grasp onto and practice, but then again, our first release should be something we are at least proud of.

The problem is we made a big mistake. We have been telling customers for months invoicing was coming soon. By opening our big mouths and not delivering we are letting our customers down. For that we are sorry!

Keep Our Big Mouth Shut

Last year we made some big mistakes. We exposed our product roadmap with timeframes of when we thought we were going to have things done. This included our mobile apps, invoicing in Skyclerk, and more. Then we were stuck between delivering on our commitments to our customers and building the best darn product we could. I am afraid the product suffered because of the added stress of hitting targets we announced. If we just kept our mouth shut we would have had the freedom to take the time it needs to release when we knew we were ready, not when we felt we had to get something out of the door.

Transparency

We like to be a transparent company. We like to talk to customers about what we are doing and where we are heading, but more importantly we like to build impressive products and features. We feel we can serve our customers better by delivering something that is “freaking amazing” than giving them an outlook into where we are heading.

I am afraid as of today we will no longer publicly give insights into where we are heading. We will have to keep our product roadmap private. Please disregard any timeframes or roadmap announcements we have made in the past.

Please don’t be afraid to send us your thoughts and comments. While we may no longer respond with “great idea we will start working on it”, we do listen to all our customers, and use as much feedback as we can when building our products and features.

And rest assured, because we do not brag about working on what is important for you, it does not mean we are not doing exactly that.

Over the last year or so Google has rolled out a new consistent look and feel across all their properties. While I am not in love with the design, I am in love with their consistency. One aspect that I think all start-ups should learn is being consistent between the apps and the marketing sites. Every google property has a marketing site that tells you about the application and convinces you to sign-up for it. Every software as a service start-up has the same thing. So many start-ups do not carry the same look and feel all the way through from the marketing site to the application to the mobile app and beyond. Here at Cloudmanic Labs we are guilty as charged.

Most users do not know what a marketing site vs an application site is. Nor do they care. They just want to be able to get what they want when they want it. So when you start with one look and feel and transfer to another look and feel users might think they have left the site. Imagine driving down the road in a desert. All of a sudden, you blink and you open your eyes to find yourself in the middle of a city. You are still driving down the road. You are still fine. However, you would have to take a few moments to process the change.

I think we owe it to our users to focus on a consistent experience across all our properties at Cloudmanic Labs. Users should be able to flow between our sites and apps fluidly without having to recompose when going from one site to another. It might take a while (well over a year) but we are going to start refactoring our properties to be more consistent.

Last week I made a comment on twitter about how I did not want to hire a candidate without previously have a Github account. I got some backlash more or less calling me a fan boy of Github. While I am a fan boy of Github, that was not the reasoning behind my comment.

If you have ever read a programmer’s resume you know it is a big listing of every programing language they have ever looked at. All languages are the same right? Once you know one you know them all right? I call bullshit on this. Yes, once you know some CS fundamentals jumping into a new language is easier. You do not need to go back to college or anything. You can generally figure it out - but you cannot figure it out overnight. Just because you are considered a senior programmer in one language it does not make you a senior programmer in another language. As a small business we can not afford to hire someone that is going to need ramping up time. We need someone that can hit the ground running. We need someone that is going to produce high quality code, quickly.

So when looking at some one’s Github account I can quickly see what language makes them high. I can see what technologies they pursue in their own time. You don’t publish code on Github unless you are at least somewhat proud of it. Going to anyone’s Github account shows you within seconds what language is their primary focus. I am only interested in hiring people that share the same primary focuses we have. When hiring I want the best of the best in the field we are looking for, not someone who can “learn to be the best” or who is the best at something else.

Lastly, the technologies we use have all made Github their official home. The leaders and maintainers building these technologies have made Github their official hangout. If you are not part of this community it is a good indication to me that you are not truly passionate about your programming craft, (or at least the craft we are looking for). If you are truly passionate about skiing you do not live in Florida do you?

Generally, I want to hire people who have a natural fascination with the technologies we use. In programming passion and fascination are much bigger motivators than a paycheck. Not having a Github account in my world says to me you are just looking for a paycheck.

Andrew Warner of Mixergy.com says that when he interviews founders of startups the one thing they always say is the first release of their product looked like crap. Over time the product has evolved, but in general looking back the first release was not something they are proud of today. Hearing that always makes me ponder. Sure, I believe in release early and release often. Of course building a MVP (minimal viable product) and getting it out to customers is much better then continuously polishing your product hiding behind the “its not perfect” curtain. The idea of releasing something you are not 100% proud of seems odd to me.

Many products are a spin off of a consulting firm, and founding teams often have client work backgrounds. It seems product teams forget their client work process when they build their own product. When working with clients you often practice what I call CYA (cover your ass) software development. You work with your client to really flush out their ideas. This often turns into a scope document, and the clients signs off. Then you often move into wireframes flushing out any micro detail, and once again the client signs off (covering your ass). Lastly, before much development takes place you might have some design rounds with the client getting the client to fully sign off before the development really starts. With client work you are going through these phases to really ensure you are delivering just what the client wants and make sure everyone is on the same page. What also happens during this process is you flush out the entire idea from high level all the way down to the micro details. You never say “oh we will figure that part out later”. With this process you deliver just what the clients wants on budget and on time. Never would you deliver something to your client that you are not proud of.

When building your own product so many development teams just dive right in, pick a point at random and start programing. Since it is their own product many developers tend to think the CYA process is not needed, and maybe sometimes a little boring. I say this is a mistake. Not working through the different user experience issues, the data model, the design, and so on while just hitting the ground coding is a great way to have headaches later on. The CYA process front loads resolving headaches and problems that may arise in the future. Why not do that with your own product?

I am proud that any product we have ever released at Cloudmanic Labs has been well thought out. We go through the same process we would go through with clients. Not one line of code is written until we fully flush out our ideas, manage the scope, and fully design the product. The first release of our products have often been far from crap. They are polished. Also, our development time is not any longer then other hit-the-ground coding teams. Our discipline to maintain the CYA process has made it so we have never released a product we were not proud of, no matter how far from our desired final form it is.

We of course don’t think we are going to be perfect on our first release in terms of features, customer needs, and bugs. There is always going to be things we messed up, and that is why user feedback is very important. We listen to it all and evolve our products with our customers in mind. We never skip out on any of the important steps of a product development cycle just because it is convenient to ignore them or because it is boring. We never say “oh we will figure that out later”.

CYA software development has an important role in non-client work as well.