hr

SaaS Startup Founders: Are you talking to the right audience?

TOTALLY+MISSED.jpg

I have a confession to make. I am a developer, not a marketer, and in the nearly 4 years that I have been running my startup HR Partner, I have made a ton of mistakes in my ‘go to market’ strategy, and I hope to share a couple of them here with you.

I always naively thought that the coding of my SaaS product would be the hard part, and that the selling part would happen naturally and effortlessly. How wrong I was. In today’s noisy world, with a ton of competitive offerings, getting heard is nearly impossible, and finding people who will like, and more importantly, pay for your offering is painfully difficult.

Probably the biggest mistake we’ve made with our marketing was simply talking and selling to the wrong people. We never really stopped to look at who would be using our product but instead went for the scattergun approach to throw everything at the wall and see what would stick. Let me give you a brief history of what we did.

When I first built HR Partner back around 2016, I decided to release our Beta version to the world via a fanfare splash on the very popular ProductHunt website. It seemed to work, and we actually got hundreds of sign ups out of this one source. “Great!”, I thought - success and endless bags of cash shall now rain down on me.

Wrong. Pretty much 0% of those early signups stuck around. You see, ProductHunt is comprised mainly of programmers, designers and other small startup founders. They are very interested in tech, but have little or no interest in setting up HR policies and procedures, or managing a large team. They signed up purely out of interest sake, but had no reason to actually implement our system at their workplace.

Nevertheless, we doubled down on our failure to learn, and I embarked on a campaign of listing my HR system on various Beta announcement sites such as BetaList. Same results. A flurry of sign ups by curious people, but very little stickiness.

Of course, this spike in signups both times was great for my ego, but I couldn’t see that this was just a vanity metric that did nothing to help us get any real traction.

Next, we went completely broad based, by spending a ton of money on Google Ads. We even worked with a Google consultant to get our keywords and campaign ‘just so’. But while we saw a massive increase in traffic to our website, it didn’t result in many trial signups, and in fact, we got a TON of calls and emails from various employees asking us HR policy and payroll legislation questions! We quickly pulled the plug on this avenue.

At this point, and for the first time in over 6 months of trying, I actually sat down to think about where I was going wrong. It was pretty obvious actually. ProductHunt and BetaList are great sites, but really, they are ideally suited if you have early stage products that are geared to the programmers or designers of this world. Business owners are not renown for adopting concept stage or beta stage software - they want something proven and reliable. Coders and creative people however, are different and can’t wait to try the next shiny thing! We were talking to totally the wrong people.

So I began to think. Who would need HR systems? Well, the obvious answer is “HR Managers”, duh!

Thus began our next marketing push - cold outreach to anyone with the title “HR Manager” on LinkedIn. Initial observations were a mixed bag. We were having some great conversations with a lot of HR Managers on that platform, but very few would actually take the next step and sign up for a trial of HR Partner. It turns out that while these were the right people to talk to, they already had established systems they were happy with, and were not looking to buy.

We were getting closer - the right people, just in the wrong place & time. So how do we get them at the right time? Well, we’ve recently put some marketing effort on business software directories, such as Capterra or G2 Crowd. These are vast directories of SaaS offering that people can go to when, you guessed it, they are evaluating business software that they are thinking of buying.

Now we were getting somewhere. By promoting our offering on these platforms, we started to see a steady uptick of trial sign ups, and more importantly, paying customers.

This is all good news, but there is still so much more learning to be done here. For instance, we are finding that while it is the HR or Operations Managers we are mainly talking to, the actual buying decision is usually made by a different person in the chain.

HR Managers are coming to us with a specific set of problems - for example they may be drowning in paperwork or having trouble keeping employee qualifications and training up to date. Whereas the business owner may have a different set of issues they want solved, such as high turnover, or the high cost of recruiting new employees.

This means that we needed to address both areas. When talking to the HR Manager, we would focus on the problems they were experiencing, but when the decision went back up the line to the person who would sign off on the new software, we had to start from scratch and provide solutions for a whole different set of problems. We essentially had to sell our system twice, to practically two different audiences.

Did I say two? We actually discovered that we had a third audience that we had to sell to. These were the actual employees themselves within the organisations who bought HR Partner. Any great HR software is just going to languish if the employees don’t feel comfortable using it. All that the employees wanted to know was - how do I find out how many days leave I have available? How can I request some time off expediently? How can I find the contact email of another employee in a remote office? etc. A totally different set of problems and expectations than the other two audiences we had been dealing with!

Thus we refined our sales and marketing processes to deal with these three distinct audiences that our product had. Sure it is a lot harder to do, and is time consuming, but it has resulted in a far more effective and predictable process now - just by understanding who our audience was, and in our case, who our multiple audiences were that we had to talk to, understand, and solve problems for.

We are still learning and improving, and I am interested in hearing more from other startup founders and business owners out there. How did you find your real audience?

This article was originally written for the Catalysr Blog. I was a member of the Catalysr C18 cohort for migrapreneurs, an experience which was awesome and extremely beneficial to me and my startup. Find out more about them at catalysr.com.au.

Errors don't have to be boring

This is part 7 in the chronicles of building HR Partner, our latest web app.

A short one today.  I was designing the 404 and 500 error screens for our Ruby framework, and decided to go outside the box a little.

Usually, the 404 error page is a fairly boring affair, telling the user that they have tried to load an invalid page.  I thought to make it more interesting, I would incorporate an ever changing background for the error pages.

I am using a dynamic CSS background for the error pages, which links to unsplash.it to load up a random grayscale image as the background.

This way, every time that a user hits an error page, they will still get the large '404' or '500' error number, but overlaid on a different background each time.  I have no control over what image gets shown, but I find myself just hitting invalid pages every now and then during my development routine - just to see what pretty landscapes show up.

The body style tag looks something like the following:

<body class='black-bg' style='height: 100%; background:url(https://unsplash.it/g/1000/800/?random) no-repeat fixed center center;'>
  ... rest of 404 error info
</body>

So as I said - error message certainly do not have to be boring!

Don't hide the delete button

Welcome to part 6 of our series on designing HR Partner, our latest web app that is slated for release in 2016.

This episode, I'd like to go through a design consideration that I had with the file upload library module in our app.  In this module, the user can create 'categories' for their files, and upload an unlimited number of files to that category.

They also have the option to delete a category if it is not needed any more.  The problem is, we won't allow them to delete while they still have files allocated to that category.

The question was how do we deal with this restriction?  On our early Alpha version, we simply hid the delete button if there were still files within the category.  However, this gave the user no indication that they COULD delete the category, at least unless the category was already empty, in which case they would see the button.

We thought that this was counter intuitive.  We wanted the give the user an indication that they could delete, as long as they deleted the files first.

So in the second iteration, we put the delete button back, but disabled it when there were active files in the category.  This still wasn't optimal, because there was no explanation as to WHY the button was disabled.

So we went to the next level, and made the button active.  If the user presses it while there are still active files, they will get a popup telling them why they cannot yet delete.  If there are no active files, then they will see the usual delete confirmation dialog.

We hope that this method means we don't clutter the interface with too much extra text, yet still gives the user an idea of what they can and cannot do within a particular screen.


Don't change that menu

We are rolling along with Part 5 of my blog series that I am writing while building our latest web app HR Partner.  The earlier posts can be found on this site, and I will shortly put together an index page, so all the posts can eventually be cross referenced in the one place.

Today is a short post, and it is to do with a tiny design decision that we made today.

Clutter, specifically screen clutter, is a pet peeve of mine.  I dislike having more than is necessary on my app screens.  This must be a habit going back to my flying days.  Most aircraft cockpits have been designed by ergonomic and efficiency engineers to make the capturing of information as easy as possible.  Under IFR (instrument flight rules), the pilot has to minimise moving his whole head to avoid disorientation that can occur with no external frame of reference.

I try to always abide by these rules when designing my interfaces.  No extra clutter that will distract.  On the left hand side of the HR Partner page, is a menu showing the different HR 'modules' that the user can work with, i.e. Employee Training, Document Attachments, Absence Details, Assets on Loan etc.

I wanted to have the module menu so that whenever the user clicked on a module, it would disappear from the menu.  After all, if you were in the 'Absence' area, it would make no sense to have the 'Absence' menu option still available to click, was there?  It was another line in an already long list.  Removing it would make the list shorter and easier to scan for the user.

Or so I thought.

The module menu in question, on the left.

The module menu in question, on the left.


It turned out, that having the module list change (even subtly) via the removal of a single line tended to throw our test users off.  It turns out that most users will subconsciously memorise the placement of menus and clickable areas on the screen - even if they scroll up and down!  They tended to keep a mental map of where everything was, and had already calculated the minimum distances required to reach those spots.

Moving them by one line or so tended to throw out their entire frame of reference and result in confusion and pauses when trying to find where they wanted to go.

In the end, we decided to leave the module list exactly 'as is'.  I would appreciate any thought anyone out there might have on this.  Also, if you have any scientific research that would back up my theory about users mapping the screen layout subconciously, I would appreciate a heads up.