Dogfooding:

“Refers to the act of a businesses internally using the software products they create for their customers.”

“Developers who do not use their own software on a regular basis are often unable to understand the problems their users face.”

As a subscription-based service, SnapBill had the need for its own automated billing solution to facilitate invoicing, recurring payment collections and the management of client data.

So what’s better than using SnapBill to bill for SnapBill?

This scenario creates the “ideal” position for any service provider to be in and may lead to what is more commonly referred to as “dogfooding”.

Convenient? Yes. Without its problems? No.

The challenge SnapBill faced is, if we’re expecting our customers to use our service, are we ourselves willing to use it … does it meet our own expectations and needs?

I assure you this is no sales pitch or an attempt at bullshitting you. We’re probably our most honest customer, and it’s not always easy… you know? Being honest with yourself.

Experiencing operations first hand is a great advantage to have as a service provider but it can also become a tricky game to play.

When using an external source to fulfil a need in your business you rarely get to experience what goes on behind the scenes. Things just work. Even when there is something wrong. For example a bug,  in all likelihood, will be fixed before you even noticed it was there. This user experience is aimed at optimal lack of failure, or rather disguise of failure. Creating strong reassurances that the service works nearly flawlessly combined with quick response times from the support channel when an issue does occur. (Rarely the scenario when using your own service, as with most SaaS products, bugs are inevitable).

In our experience the most powerful advantage of “dogfooding” SnapBill, is that we can successfully deploy changes directly within our own billing environment. This way we get to test and experience our final product, which in turn allows us to ensure optimal usability and efficiency of our product.

When implementing new features our process usually follows:

1. Create a development and test schedule

2. Developers get to work building code

3. Deploy the code onto our staging servers

4. Run live test verifications until all tests pass

5. Deploy changes to production

6. Provide reports to the technical team

7. Provide first-hand experience and knowledge to customers via support articles and feature introductions

By being your own best customer in addition to being the actual product developer, brings about a very different dynamic which coupled with ineffective management can also lead to epic failure occurring from the inside out.

Here are some of the important things to be aware of when dogfooding:

Try to be a new user, everyday

One of the easiest pitfalls of dogfooding is to slip into being an active, regular user of your product, focusing on driving sales and pushing people through to your signup page, but rarely frequenting the entire process yourself.

You need to ask yourself: Is the complete experience of my product tedious? Are there any bugs? Are there upgrades available to simplify the process? Just how inviting is that sign up page or e-mail really?

It’s pretty easy to neglect this aspect of your business, being your own customer comes with many benefits, but being a new customer everyday grants you better insight into the entire take on process that could very well be turning new business away if it becomes too messy or buggy.

Make the effort to evaluate this point of the business and prevent any potential issues, be unaware of it and you’ll literally have customers walking away at your doorstep.

Constant updates & notifications on support documentation

Being the development team and making practical use of the service often results in staff having a rather extensive knowledge of the features and functions of the product. This eliminates the need for us to refer to our support site and results in us neglecting to update customers with simple and concise, steps to making use of the system.

We’ve learned to be very pedantic about this and it helps us to ensure that there are constant updates, communication and documentation available to our users.

We have achieved this level of information sharing by implementing it as one of the crucial steps in our development process. Developers are to brief our account and social media managers on each feature, we then also tests the feature and compile a notification mailer or an insert for our newsletter. This results in creating awareness via our social platforms and a clear concise article on our support site.

Why not provide your users with regular information on all available functions? Just because a function or feature seems obvious  to you, doesn’t necessarily mean your user will smell that it is there. This is also a great way to show that you are constantly evolving. Successful software solutions are in a constant state of being updated.

You vs The Customer

The idea behind SnapBill stemmed from identifying a need within our previous web hosting business.

With that need came a few requirements to inspire the solution, many of which were our personal needs and not global requirements pertaining to a successful billing solution.

Refining the solution became an obsession and luckily for us we discovered that other people were willing to pay for this.  It is at this point that we decided to sell our web hosting company and go mainstream with our SaaS billing service.

When moving on from the initial foundation phase it is very easy to become distracted by your own needs pertaining to the “solution”… given that its purpose was to solve a specific problem. For example when you find that something isn’t working for you— you quickly implement a change to solve the problem or you realise you need something added, and being within a agile development mindset it is quickly coded and deployed by your developers.

This can go on for quite some time, fair enough it’s good to aim at speeding up the development of the system, but you can easily be distracted from what your customers need or lose sight of the needs of your target audience. Keep in mind that your requirements do not necessarily match those of your intended audience.

Our advice on climbing out of that rut and removing your unintentional self-centered visions are:

1. Determine who your target audience is / identify your mass market

Pull out the statistics and recognise who the majority of your clients are and the figure out why they are actually using your system.

2. The quieter you become the more you can hear, listen…

Listening is cliché and is easily avoided and brushed off with “thank you for your suggestion we will review it at a later stage” and let’s be honest it never gets reviewed again. Actually listening to clients suggestions and drawing up a development board has been one of the keys to our success thus far.

Schedule weekly meetings with your team, and don’t limit them to just your developers, you need to include the support technicians, the accountants, the accounts managers, the social communications managers and the tea lady. (because coffee is awesome)

The reason for the variety of input in this meeting is that you need the people on board who deal with customers on a daily basis, the guy who knows which problems arise most, the person who interacts with the end-user on a daily basis and get some much needed input from the people who are making use of the system themselves (the dogfooders on the team).

This should empower you to get a broader overview of what needs to be implemented to match your vision and to also consider what it is the people who pay you require. (Freemium models do tend to mess with this ideology, see Free fall and the revival of the free package.)

Lastly, enjoy your product – that way it will always manage to sell itself, there is no greater sales advantage than becoming a testament to your own product.