Our first deadline was looming and we had early adopters waiting in the wings. We were hard at work getting the initial version of FileGuardian to market. On the business side, I was starting to formulate our pricing model. I knew it wouldn’t be needed immediately since our early adopters were going to receive free usage for a period of time, but many were asking what FileGuardian would cost after.
Our internal alpha review was a … disaster
I had given our employees free reign when it came to application design and architecture. Therefore our internal alpha review had two key goals:
- Verify the chosen application design
- View the current state of FileGuardian – we called it alpha mode since it still wasn’t ready for our early adopters to beta.
There are many parts to application design and most were spot on to what I expected (in fact, many still live on today within FileGuardian). One in particular though was so far off it’s what deemed the initial review a disaster. I probably had given one employee a bit too much leeway when it came to development. The way he coded the first version of FileGuardian would end up making the application a nightmare to maintain.
It would also require specialized programming skills which I knew were in short supply on the market. This had a huge impact on #2 above since the current state of the FileGuardian was based on this design decision. It was early November and I had to make a decision: stay with the current path or kibosh it. If the latter was chosen, we’d need a complete redesign which could severely impact our end of year deadline.
Back to the drawing board
I knew we couldn’t live with the application the way it was initially designed. I figured the risk of going back to the drawing board and potentially missing our deadline was necessary. As the old saying goes “you never get a second chance to make a first impression”. Plus I had worked on previous software projects where a poor choice in the beginning affected the software for its entire life. Since this was going to be my future (or at least I hoped), we needed to do things right from day one.
It was risky though. We needed a version and a version soon. I had lined up some early adopter previews for the middle of November which now needed to be pushed back. I felt keeping our initial users in constant communication with the “state of the sate” was important. As my wife can attest, I’m a big believer in setting proper expectations and if you screw up, being honest about it. When I screwed up on a project I was the first to admit it and I think my peers respected me for that. I wanted Shugo to follow that same philosophy: open and honest communication especially when we goofed.
As a result I shared with our early adopters what had happened and how we needed to go back to the drawing board. We were still committed to our deadline and would still hit it but our initial review would need to be moved back two weeks. All were very understanding probably because I was “selling” them vaporware still and probably because they were close friends or family. Nevertheless, we were back to the drawing board charting a new course.
Version two…full steam ahead
Version two proved much better. Standards were followed and we were well on our way. FileGuardian would guide the user on a five step process to securely send files. Here’s our actual UI mockups’ showing each step. Boy how FileGuardian has changed since these days.
It was early December and our initial early adopter previews went smooth. One occurred in their office, another back at the Grey Lodge, one in our office and the last at Panera. I think their lack of using a system like FileGuardian is probably why we received positive feedback. We were showing them a new way to do things. Think about the iPod. It showed us a new way to purchase and listen to music. Was it the optimal way? Who knew but it was new and different so we accepted it as such.
In December of 2008, FileGuardian was “unveiled” to the world. Pretty funny saying that since we’d find out that an early adopter wouldn’t start using it until February 2009 but we hit a major accomplishment. If you went to www.myfileguardian.com you could sign in and use the system even though it lacked some key features:
- FileGuardian lacked a signup process – so any new early adopter would need to contact us personally and have their account created.
- If you did have an account and forgot your password, guess what you had to do: contact us! We released without the standard password reset process (what were we thinking?).
- FileGuardian lacked a bulk method to send email alerts. Our initial design included the capability for our clients to send bulk email alerts like a Constant Contact or MailChimp. We didn’t have time to include this so it was 86’d (I never worked in a bar or restaurant but learned the term from Gordon Ramsey from his countless TV shows).
I didn’t want to miss the deadline so removing features like these, and others, were not deal breakers. The important piece was our clients could send files securely. We were proud and knew there was much work left. I personally was anxiously awaiting receipt of my first secure file since two of the initial early adopters were my accountants (personal and business). My 2008 tax returns would be delivered through our application and I was excited.
A meeting that changed our course
If you remember back to part three of our story, I kept our consulting company open even though I was fully committed to this new venture. This turned out to be a key decision for our future.
One our consulting clients was Payroll Network, an esteemed, established and thriving payroll company in Maryland right outside of D.C. I had a great relationship with a number of employees and was asked to join their technology group as consultant years prior. I jumped at the chance since it would diversify our consulting client base a bit. Plus, I thought we could charge a premium for our consulting rate since they were located in an affluent area; just don’t tell Rex I said this.
Each year we would hold a technology summit down in their office. We’d spend two days together locked in a room identifying major initiatives for the year. I was more of a development sounding board bringing new ideas and technology to the fold. I really enjoyed it since it allowed me to interact with other IT professionals who thought a bit different than I did. Honestly, it was a great match and I still do minor consulting with Payroll Network today. And, I haven’t raised our rates.
In February 2009 our annual summit was being held. You know how people say everything happens for a reason and sometimes things just fall into place? This meeting proved these points true.
During our two day huddle, the team identified the need to securely transfer files to clients and vendors outside of the payroll system. Payroll Network was very progressive and developed their own internal systems to extend the functionality of their payroll software. Part of these systems generated files which needed to be sent securely to clients since they sometimes contained personal information such as SSNs, bank account numbers or other financial information. How could we accomplish this? I mentioned FileGuardian and how it was being “used” by early adopters.
I remember having a bit of anxiety since I fired up my laptop and walked them through a demo. I had sent files securely through FileGuardian many of times and even demo’d to our early adopters but this was different. It was the first time I was truly “demo’ing” the application and trying to “sell” someone on it. The demo went smoothly and as a technology group, we decided Payroll Network would start using FileGuardian. Of course it helped when I shared we wouldn’t charge Payroll Network for a period of time since it was so new but heck it was our first “sale”. More importantly, they were first client in the payroll industry…