Regaining my timing

Regatta_de_Blanc.jpg

Like most musicians, I usually struggled to ‘keep time’ especially when playing solo compositions. But a few years ago, events which resulted in a stress induced condition (which I won’t bore you with here) has resulted in further degradation in my ability to keep time, even in a band situation where there is a drummer doing all the hard work.

I am determined to improve that though, and have been going back to basics and working on scales using a metronome to reduce that neural disconnect between my brain and my fingers. Over the weekend, I decided to challenge myself even further.

I’ve been a fan of The Police for a long time. There was something about their reggae infused punk beats that captured my imagination, and I admire all three musicians for their eclectic ability. I’ve never really played any of their songs on stage (mainly because I’ve never really had the chance to play with a drummer as talented or frenetic as Stewart Copeland), but I found a drum backing track online over the weekend for one of my most favourite songs of theirs and decided to give it a shot.

“Walking On The Moon” - As far as Sting’s bass work, this is actually one of the easiest ones to play, as the bass riff pretty much starts on the first beat of the bar (as opposed to a lot of other songs where the bass starts mid bar (e.g. Roxanne)). The guitar parts though, were the challenge. The chimey, chorus washed bits that come in every second bar is actually on beat four of the bar. It is a huge challenge to sit back and wait for the right timing to hit that Gmajsus4 chord, and then letting the delay slapback echo it for the first beat of the following bar! Even the staccato chord whips later in the verse are on the 2 and 4 - and every music teacher in the world always tells you to emphasise beats 1 and 3, NOT 2 and 4. Yet, this song is made by the choked chords on the 2 and 4. By far, the biggest challenge though, was playing along to Copeland’s frenzied thrashing. I had to keep time outside of his syncopated fills - a further testament to the skill of the original band.

Playing this was a great exercise in freeing up my mind from the usual constraints, and also to reduce those milliseconds of delay that had infused my neural system after that incident all those years ago. Breaking up my usual ‘straight timing’ with offbeat work like this really has seemed to reprogram the synapses in my brain. Time to go learn more Police numbers.

The first programming trick I learned

Most programmers I know experience a moment in early in their code writing careers where they are shocked by a profound moment of discovery & realisation about their craft. I’d like to think that this moment helps to crystallise their love of writing line after line of instructions designed to manipulate a pile of silicon and electrons into doing their bidding.

For a large number of those that attended some form of computer science class, or coding school, it was probably when you first saw a recursive function in action:

carbon (2).png

“WHAT? That function can’t keep calling itself… can it?? Wait…”

I said the same thing above that probably 99% of Programming 101 students said when they saw such a mind twisting piece of code. But no, for me, my major discovery about the beauty and subtlety of the art of programming that lurked a layer beneath the monospaced text on my screen happened way before that.

You see, I was a self taught programmer, and cut my teeth on the very early versions of Turbo Pascal back in the 80’s. I was lucky enough to score a job with a local IBM dealership as a support technician, and also managed to do some small bits of coding on the side for their clients.

One day, a senior IBM System/360 programmer in the company casually asked me: “Devan, do you know how to swap two variables around in RAM?”.

“Sure!” I replied, brimming with 18 year old confidence, “You just create a third variable to hold one of the values temporarily, then you do a reassignment and copy the temporary back into one of the original two…”.

I had fallen into his trap. The same trap that most junior programmers make:

The ‘old fashioned’ way of swapping two variables, using a third.

The ‘old fashioned’ way of swapping two variables, using a third.

I remember him shaking his head sagely. “Nope - did you know that you can do it without using a third variable?? We often have to swap over entire blocks of memory on the S/360, and often, we don’t have any extra memory to spare to hold a temporary value.”

I frowned in consternation. This was impossible, wasn’t it? You couldn’t ever swap two variables without using a third placeholder. The first assignment would corrupt one of the values immediately, or so I thought. I asked him if it took longer, or used more steps than the simple answer above. “Nope” he replied again. “It takes the same number of steps, and on some systems, like the S/360, it is actually faster than your example”.

I pondered this problem for most of the day, but in the end had to admit defeat to him. Surely this was just another hazing of a junior employee that he was dishing out here?

Wordlessly, he write the solution down on a whiteboard in the conference room:

Using XOR to swap values in memory.

Using XOR to swap values in memory.

I stared at what he had written with the same utter confusion that I did much later when looking at my first recursive function. Surely this was impossible. There must be a mistake here. This shouldn’t work. This can’t work.

But it does. Try it.

For those that are curious about the ‘exclusive or’ or XOR function, here is an explanation about it. And our veteran was right, on some CPUs, the XOR operation actually takes less cycles than a PUSH or MOV operation.

What was the ‘moment’ that made you fall in love with programming?

Successful Simplicity Revisited

I am a big fan of Derek Sivers, and have subscribed to his email newsletters since I met him at the Business of Software conference in Boston a decade ago. Last month, a newsletter came from him titled ‘Successful Simplicity’. The crux of the newsletter is explained well in the following video:

Basically, people find complications in things that they don’t want to do, and dismiss those same complications if it is something they want to do.

To bring this concept back to my own world view: This reminded me of several discussions I have seen on music forums I frequent about changing guitar strings. Lots of people seem to find the task of changing strings quite arduous and something to be avoided unless really necessary.

I will admit, I used to think the same way, but I have learned to overcome these ‘complications’ and inconveniences and embrace this particular task lately. And believe me, I had to. With over 20 guitars around the house, and a professional musician for a son that I act as roadie/guitar tech for, there wasn’t much choice.

Sword_polish.png

It goes back to a book I was reading many years ago about the ancient Samurai warriors of Japan. Because the feudal system of the time meant constant battles against Daimyos and duels between blade masters, their long and short swords (which were considered the ‘soul’ of the warrior) were constantly getting damaged in combat, or by body oils and blood! Contrary to what is shown on the big screen, these swords needed constant care and attention to prevent corrosion and cracking of the blade. Almost every time a Samurai stopped at an inn or a castle, he would have to get out his polishing kit and perform maintenance chores on his swords.

But the way they approached the task was what intrigued me. Because the sword was considered their ‘soul’, they treated the blade with reverence and utmost respect. Any work done on the hardware was treated as a sacred duty. Inspecting the sword for chips or nicks was a loving action that increased the warrior’s familiarity with his blade and gave him a chance to bond with an object that was considered an extension of his own body and consciousness.

IMG_2299.JPG

I decided to adopt that same philosophy with the routine task of changing strings on my guitars. Nowadays, I usually set aside about 20 to 30 minutes for the exercise, and I clean up a spot on the table on our deck (where I can experience the breeze and hear the birds in the trees) as my workbench, and inform the family that I am not to be disturbed for a while. I set out all my tools in an orderly fashion, and select the guitar that I will be working on.

Much like a cha-no-ryu tea ceremony, I tend to deliberately emphasise every movement. Almost theatrical. I force my mind to be present to the task at hand, rather than wander away. I bring my full attention to every dent, blemish and scratch on my guitars while working on it or cleaning it - not in an accusatory or critical manner, but simply as an observation and part of the process of becoming intimately familiar with my instrument.

In a lot of way, it is like a meditative practice, that forces me to be ‘in the moment’ and to appreciate every nuance of it.

Just reframing this regular task in this way has turned it from a chore to be put off, to an activity that I actually look forward to nowadays. So much so, that I started applying the same philosophy towards other mundane tasks that I have to do on a regular basis. Still got some troubles applying it to things like doing my taxes, but I will get there eventually.

Have you tried a similar technique to turn onerous tasks into joyous ones? Let me know.

The increasing third party costs of running a SaaS business

Photo by Émile Perron on Unsplash

There is no doubt that in recent time, the barrier to entry to building your own SaaS (software as a service) product has been lowered to the extent that almost anyone can jump in and build a solution to solve a problem.

However, an immediate after effect of this surge in SaaS offerings out there means that your average customer is completely spoilt for choice, and differentiating your offering from those of your competitors has become the problem du jour.

How to work on the ‘edge cases’ that can make or break your startup? It means you have to focus on things like customer retention and strategies/tools that can record massive amounts of data about how your customers come to you, and then what they do once they start poking around your system. This myriad of metrics and information usually means that you need to invest in a host of third party tools in order to get these capabilities into your own app.

Now, I am a believer in the old adage of “don’t build it yourself if you can buy it off someone has who has already done the hard work”. Our friends over at Baremetrics have already done the homework and designed a tool that will tell you whether it is more economical to build a solution you need in house, or pay a third party provider for it.

But over time, while talking to several marketing experts about how we could improve growth in my own SaaS product by increasing user retention and satisfaction, I kept hearing that we needed to provide things like:

  • Detailed user onboarding workflow

  • Screen recording to track behaviour and movement through your app

  • Knowledgebase of help articles

  • Video based training via an online academy

  • Automation tools for importing/exporting and linking data

  • In app chat for instant support response

  • CRM (customer relationship management) tool for drip email campaigns and “central point of truth” for all your customer data

  • Mailing list management software

  • Blog site with relevant articles plus hints and tips for your customers

  • Analytics and data warehousing tools

This is of course on top of a bunch of other tools that you need in order to build and host your offering in the first place, such as:

  • Hosting with AWS/Google Cloud/Azure etc.

  • Landing pages for marketing campaigns

  • Prototyping tools

  • Bug tracking and CI (continuous integration) & build tools

  • Source code repository hosting

  • Security infrastructure

  • NPS (net promoter score) measurement tools

  • Billing management systems

  • Financial accounting/payroll systems

and much more.

We recently did an audit of the cost of third party tools that we use here at my own SaaS business, and we worked out that all of our monthly tools that we used to track the above was around the $3000 per month mark (and that is with about half of our tools on free or discounted plans!). Now, given that our base pricing for our SaaS is $100 per month, it means that 30 of our customers are basically there just to pay for our third party toolset. None of those 30 customer’s revenue can go towards paying for general marketing costs, or to pay wages for our team.

Because we are still a fairly small and growing company, 30 customers is quite a sizeable percentage of our total base. I know what you are thinking - “Meh, that won’t be a problem once you have a million customers!”, but then it still will, because a lot of these third party tools pricing are based on the size of your customer base, so our hosting and support tool costs will increase linearly along with the size of our customer base at a constant rate.

To this end, I am now revisiting the idea of swapping a lot of these third party tools back ‘in house’ again. For instance, we recently explored a variety of customer onboarding tools, but given the fact that most of these tools run to around $200/month on their basic plan (that’s another 2 customers we have to find and keep just to pay for that tool), we decided to go back to writing our own onboarding sequences for new customers.

Sure this took some time to do, but at the end of the day, we could incorporate steps into our onboarding that third party tools could not hope to replicate - for example, studies have shown that the sooner you can make the customer feel that they “own” your tool, the better the chances they will stick around and explore. So, the second step of our onboarding process encourages the customer to upload their company logo to their trial company. This way, they see their company logo and name at the top of every app screen they visit during their exploration. We have seen trials to paid subscription conversions improve as a result of just this one change alone!

One of our ‘self rolled’ onboarding screens within our app.

One of our ‘self rolled’ onboarding screens within our app.

Same with our billing system backend. At a recent conference I attended, I was bombarded by third party payment processing handlers who promised they could handle things like bounced payments and expired credit cards for us - all for a monthly fee plus percentage commissions.

I am sure they were great and all, but I ended up writing our own Dunning routines and processes for handling expired cards all within our own codebase, which gives us far better flexibility as to how we can handle them.

The other thing I have been exploring is the consolidating of multiple services all into one. We recently signed up for HubSpot’s sales and marketing toolchest, and it appears that we can now stop subscribing to about 5 other vendors (in app support chat, support knowledgebase, newsletter manager, drip campaign system, landing page hosting) and do it all within the one system. HubSpot isn’t cheap, but we can reduce our monthly third party service bill by around $1000/month, so that certainly helps to offset the cost, especially while we are on their ‘startup’ plan initiative.

While we are talking about startup initiatives, I do love that a lot of companies out there provide deeply discounted pricing plans for new SaaS businesses, I am a little perturbed that most companies (such as Amazon) only provide them to funded companies. In my view, a company who has just received millions in funding can certainly afford to pay for Amazon assets to host their MVP, whereas a bootstrapped startup that is running on the smell of an oily rag could certainly do with a discounted (or free) temporary offering so there is no negative impact on their cashflow while they are building their customer base.

Most of these startup initiatives also expire after a specific timeframe (e.g. after one year). That also seems a little strange, as some startups can boast a meteoric rise within a few short weeks, whereas others may take years to break profitability. Far better to peg the discounts or free tiers to measurable metrics such as number of paying customers, or monthly revenue, in my opinion.

I am thinking that as the ancillary costs of running and promoting a SaaS business continues to rise as it is now, we will see more and more startups going back ‘in house’ for their analytics, onboarding and support tools, and we will see a consolidation (and pricing reduction) in the number of third party offerings.

What are your thoughts? Does it make it more cost effective to move some of these functions back ‘in house’ again for your startup?