My first ever app I made and sold...

I was digging through a cupboard today, when I came across the package shown below.

I was initially flabbergasted that I still had a copy on hand, but that soon gave way to feelings of nostalgia that took me back 30 years (yes, that is 3 decades) to when I first created this.

It is basically the first time I had “scratched my own itch”. Being a commercial pilot at the time, I was finding paper based logbooks to be painful to manage, so I wanted to use my programming skills to create a computer based one which would make it easier to tally up certain entries, especially looking at the recruitment process, where pilots would be asked questions like “How many hours do you have on multi engine aircraft?” or “How many in-command hours do you have on a certain aircraft type” etc.

I wanted to create a simple logbook app which could answer that, and so Sabre Personal Logbook was born sometime in 1990.

I wrote this using Clarion 2.1, which is still the most productive and useful application creation framework that I have ever come across to date. I think the original app took about 3 months to create, including the creation of the boxwork art, printing the manuals etc. I even created it using the IBM PS/2 shown on the box art!

There was no such thing as Paypal or Stripe back in those days, heck, even the internet was in its infancy, so everything was done via magazine ads (mainly in Australian Aviation magazine), or pilot specific BBS’s (Bulletin Board Systems), and payments were via people sending you cheques to bank. Wow, there was surely a lot more trust in those days (plus less scammers too, so I guess it all evens out). We even had one of the first online shops in Australia called PC Aviator as our distributor for a bit there.

We had a good run for a year or two, and sold several hundred copies of the app, and we had senior check and training pilots from airlines like Qantas and Cathay Pacific using it and giving us feedback. We had plans to create a “Professional” version for companies and flying schools which could track multiple pilots (hence the moniker “Personal” on this first version), but that never eventuated, as I got distracted with other aspects of the business, and life in general.

Eventually, we just stopped promoting and selling the app, and it simply died a natural death. I did experiment with creating an online version using ColdFusion for a while there, which would have been the first online pilot logbook, but web technology was in its infancy back then, and hosting was super expensive, and online payment gateways took a long time to become mainstream here in Australia, so I abandoned that project.

It was good to come across this today though. Funny to see that the passion to create apps still runs deep within me. These days, I run a very successful app that makes far more in one day than I made in 2 years of selling my Logbook app (indeed, the executable file for the logbook app was smaller than just the CSS file in my current app), but this was my first foray into selling something to total strangers, and I am still excited by it.

There have been many many apps in between, but you never forget your first.

How we "judo'd" a server outage to create a customer evangelist

Photo by Erik Mclean on Unsplash

I was listening to Arvid Kahl’s latest podcast episode on my morning walk today, where he talked about Facebook’s recent 6 hour outage, and how you can ‘judo’ negative things like server downtime into a positive outcome.

As a former student of the martial arts, I love that term. Judo is all about using your opponents strengths and turning them into a weakness in certain situations, and I’d like to think that the reverse is true as well.

Here is my story - just over a year ago, we had one of our most serious server outages in my SaaS startup. Our main app server crashed at about 2am my time. This was before I had set up any sort of emergency escalation routine in our company to handle such outages, and as luck would have it, I was the only one at the time who could reset the servers, and it happened right in the middle of my sleep routine.

By the time my team reached me, and I was able to fix the problem at get things running again, our servers were offline for about 3 hours. To this date the longest outage we’ve ever had.

When I went to check my emails at the start of my normal work time, exhausted after a sleepless night, I saw one particular email in my flooded Inbox from a particular customer, and she was extremely irate and threatened to cancel her subscription with us. Most other customer were just mildly annoyed and were straightforward to placate, but this one email stood out to me.

I was gutted to receive such an message - probably the first such email I had received in running my startup (and to date, I think the only example of one), and I was initially just going to rescind and agree to cancel that customer’s account and help her move her data off our system.

But then I though, No, let me take the more human approach here, and explain to her how we are a small company, and I am the one in charge of our servers and I had a particular hard day that day helping my son with a tough assignment and was so tired I had slept through the first few times my team had frantically tried to call me to tell me things were not working. I wasn’t side stepping the issue, but instead admitted that we had failed, and personally took responsibility.

(Side note: We have since put in place several steps to ensure that the team can respond to server outages in a more timely manner, and we use the escalation policies on the excellent BetterUptime service to ensure this).

Well, a few hours after sending that email, I received a response from this customer apologising for her harsh tone on her earlier email, and she (Carmen) said she was stressed and working late too, and knew what it was like to help kids with their school work.

Long story short, she ended up staying on as a customer, but not only that, she became one of our loudest advocates and started recommending us to other colleagues of hers. Carmen even sent in a testimonial video completely off her own back and unasked by us. We used it on a special case study on her and her organisation on our marketing website.

Carmen has since moved on from her role at that particular company, and in fact we are in talks to see if she can join our team as a customer evangelist and customer success person!

I am so glad that we managed to turn what could have been a really negative episode for our company into something so positive. Sometime in the big, dark world of online businesses, it pays to be human and transparent.

How we manage our product roadmap

The screenshot here is our company Trello board, where we manage our product roadmap. We are extremely lucky in that our thousands of happy customers give us a steady stream of suggestions for new features and improvements, which we used to just throw on this board.

However, that soon lead to stagnation, and I would become paralysed with indecision whenever I looked at the board. It all seemed too much, and overwhelming and I never knew where to begin, or to stop.

How did we solve this? I mean, we still had to capture our customer’s wishes, but it was leading to a literal wall of things to do, and the more we added to that wall, the less chance there was of things happening.

Here is what we did.

Step one was to basically stop the development team from looking at this board at all. And that includes myself.

Step two was to get our Customer Success team to start managing the cards on the board, and to do it in a deliberate and disciplined manner. After all, the CS team were the ones talking to the customers during sales, onboarding and training calls, so they were at the ‘coal face’ as it were, and knew the exact challenges that our customers were facing.

The first thing we did, was to split the board into three logical sections. The left section is where incoming cards go to be evaluated and prioritised. The middle section was for recording progress, and the right hand section was for long term ‘back burner’ tasks.

Our current column layouts across the screen are:

• New - To Triage

• To Discuss

• Scoping

• Planned (Next 3 Months)

• Doing

• Done (Customer to be advised)

• Done (Completed)

• On Hold

• UX Improvements

• Column for each module in our app, i.e. Leave Management, E-Signatures

Cards pretty much move from left to right on here. Let me explain how.

The leftmost column is our ‘Triage’ column. Any new suggestions, comments or bug reports will go in here first, without any judgement or pre-conceptions. It is a column to ‘brain dump’ anything that comes through our support ticketing system or direct emails to CS team members.

It is important to note that any items the CS team adds as a result of a customer issue or request, all have a link to the relevant ticket in our HelpScout support ticketing system so we can cross refer back to the original conversation.

Once a week or so, the CS team will get together and go through this Triage column. They will decide what requests are important or critical, as well as see if any of the new cards are duplicates of older requests.

Things that they decide will be worked on will be moved into the next column, which is called ‘Scoping’. This column has a set process of itself, in order to scope out exactly what changes will be required in our system. The task has to pass scrutiny around security changes to our app, demand from other users, training and documentation required etc. A copy of the steps that a card in scoping has to go through is listed below:

Description

[briefly describe what the feature or fix should do]

Owner

[who is the owner of this story, who will be managing it moving forward]

Audience

[ ] Admin User [ ] Employee

Problem Space

[describe the problem or roadblock that this feature/fix will be solving. Are there any workarounds within HR Partner now, or are customers hacking around with existing functionality to try and accomplish their goals?]

Expected Outcomes

[describe what the final outcome or goal of this feature or fix will be. Try and go into details of the business problem that the end user will be solving]

Priority

[ ] Urgent [ ] High [ ] Medium [ ] Low [ ] Wishlist

Workflow

[what is the expected sequence of steps that the end user will have to go through in order to achieve their goals using this feature/fix? If there are multiple steps to prepare something, then process it, try and show a flowchart if possible]

Data Changes

[does this feature or fix make major changes to any data? Does it perform mass deletions or bulk modification of existing data that the user should be aware of? Should there be a way to reverse it if things go wrong?]

Permissions

[describe the permission restrictions needed on this feature or fix. Does it have to be restricted to employees in a particular Department or Location, should some employees be excluded from it based on any criteria etc.]

Interface

[does the interface need to be modified to suit this new feature or fix? If so, will it need a new menu or new screens created, or does it need a modification to existing menus or screens?]

Notifications

[what sort of notifications will be required for the end user? Will there be emails that need to be generated and sent to admin users or employees? Will any internal in app notifications need to be generated to let people know something has happened?]

External Factors

[does this feature rely on external tools, such as Slack or our API in order to be successfully used?]

Mockups

[try and include mockups or prototypes of any screens or workflows. Hand drawn, scanned/photographed and uploaded is fine, or sketches with any rudimentary drawing tool, or Photoshop, Figma, Sketch etc.]

Once the scoping process is completed, a decision is made as to whether the work will be done now, or at a later date.

This is when the card gets moved to either our Planned column or the Doing column.

At this point, the development team lead (myself) gets involved again. I look at the cards in these two columns, and set the priority from top to bottom. Now comes the time to take it to the next level.

We use a system called Phabricator for our development repository tracking, code reviews and bug ticket handling. Phabricator was originally developed internally at Facebook before being spun out on its own. Some people find it too technical, but I’ve used it for years and love it (even though the development company in charge has shuttered and stopped working on it as of August 2021).

When a card is to be worked on, I create a ticket in Phabricator and assign it to the developer that I want to be in charge of the ticket. Within the Phabricator ticket, I paste the link to the Trello card, and on the Trello card, I enter the Phabricator ticket number as a cross referencing mechanism.

The Phabricator ticket reference in the Trello card.

Showing the Trello link in the Phabricator ticket.

This means that the CS team can dive into Phabricator and find the work progress status if needed, and the development team can also go back to Trello and see the customer support tickets relating to the task at hand.

This two way deep dive (and yes, all our team have access to all our systems as a default) is invaluable to us keeping track of the status of any work being done.

My main focus is keeping these tickets on track in our Phabricator system. Once the tickets are completed, and tested on our staging server, then they are closed in Phabricator, and the developer responsible for the ticket will have to go back to Trello and either move the card to the Done column, or if there are links to our support ticketing system on the card, then it is moved to the Done - Customer to be advised column.

The CS team will then, as part of their Trello maintenance routine, go through the cards on Done - Customer to be advices and send responses to our customers advising them that the bug has been fixed, or the feature they requested has been implemented.

This I think is the biggest shining light of our process - Our customer is kept in the loop from initial support ticket right up to the job being done and pushed to production.

At our current team size, this process seems to work really well for us. It will be interesting to see how it scales as we grow. We will probably need to look at other toolsets and integrations, seeing as how Phabricator is now end of life.

Would love to hear from other startups how you handle a complex and busy roadmap. Drop us a comment below.

Optimising bank working hours

Photo by Museums Victoria on Unsplash

This is probably an out of date concept these days, however if you ever ran a traditional business back in the 70’s, 80’s and 90’s as I did, one of the most frustrating things ever was trying to get my banking done over the counter.

Almost all businesses have to have cash floats, or make deposits etc. to ensure cashflow stays strong, or perhaps talk to a manager to make certain arrangements. I know I had to do this many, many times during my business life over the decades, however it always flummoxed me as to how bad the experience was.

You see, in Australia, banks didn’t really open their doors until about 9am. Then they would shut early - around 4pm, citing that their staff needed the extra time at the start and end of each day to cash up and reconcile etc.

The big problem with that, was that most business people couldn’t visit the bank except:

1. Before they opened their own doors early in the morning, or

2. After they closed up shop at the end of the day, or

3. During their lunch break

Because (1) and (2) was practically impossible, you used to get a massive rush during (3) when almost every business in town was in the bank to try and get things done.

Here is a rough timeline graph of the bank’s chosen working hours vs the customer demand during those hours:

As you can see, a lot of frustrated people on either end, and a lot of overworked, harried bank staff in the middle trying to deal with the uncommon rush.

Why didn’t banks ever implement a split shift system?

They could have easily split their staffing in half, and have half the team come in earlier in the morning to open up and do the morning cash processing, and offer counter service to businesses who needed to get their cash floats before starting the day.

Then, they could have had a ‘late team’ come in later in the morning to help the morning team cover the mid-day rush, and work later to finish cashing up and deal with businesses coming in after closing to deposit their daily takings.

They would still have had a full team on for the lunch rush (which would be lessened by taking care of the customer needs on either end of the day, with no additional staffing costs involved.

I would assume that workers with kids in school would prefer to work the morning shift and finish working when it was time to pick up their children from school. Alternatively, people who were studying or partying may wish to sleep in a little later and work into the evening.

As I said, this is probably all redundant now, in the cashless economy and online banking world, however it is something that I always thought about when I walked into a bank to do business, but ended up leaving in frustration and with a negative taste in my mouth.