BugHerd needs someone to take responsibility for our SEO, PPC & Inbound marketing efforts.

At BugHerd we love testing and make all of our key decisions on insights garnered from data. As such you will be dedicated to following the “test, measure, learn” process and using your learnings to evolve our strategic direction.

You will understand the role of content in generating inbound traffic and use your keyword research skills to identify new opportunities to reach potential customers.

You will be technical in nature with a love of data. You will also be passionate about content creation (perhaps a personal blog?) while using a creative mind to help us grow our customer base.

Working at a start-up you must be able to roll up your sleeves and get things done autonomously.

You will have opportunity to get onboard early into a high growth start-up and scale a team as together we achieve our growth targets.

Desired technical skills and experience

Excellent knowledge of SEO, PPC & relevant technologies (international campaign experience desirable)
Web analytics – especially Google Analytics
Experience with of eDM/Newsletters
Landing pages optimisation
Social Media Marketing
HTML and CSS (Photoshop also desirable)
Content Creation/Blogging
Working knowledge of broader digital marketing ecosystem.
Experience 3-5 years in a relevant role – either agency or client side

B2B or SAAS marketing experience preferable.

Please contact jobs@bugherd.com for this Melbourne based role.

Front End Lead

We’re on the hunt for a lead developer (client side), who can own our client side application.

BugHerd is a Backbone/Rails combo with a data intensive client side requiring high availability and scalability.

You will have a strong background in MVC style Javascript frameworks (esp. Backbone.js) and have experience with developing applications where scale and performance are critical. As such you will have a clear understanding of client/server communications at scale as well as the effects of latency, queuing and response times.

As a lead you will be responsible for overseeing the ongoing development of the client side application as well as taking a leading role in managing processes for testing and deployment.

You will have opportunity to get onboard early into a high growth start-up and scale a team as together we achieve our growth targets.

Desired technical skills and experience
Significant experience with JS Framework, such as Backbone.js (preferred), ember.js, Meteor.js or equivalent.
Extensive experience with of AJAX, jQuery and Object Oriented JS.
Experience with HTML5 and CSS3.
Strong knowledge JS testing frameworks and deployment strategies.
Experience 3-5 years in a relevant role.

Please contact jobs@bugherd.com for this Melbourne based role.

Only a few months ago it was a rarity to see a project with more than 1000 tasks, it’s now commonplace. Where once ten users was the norm, we now frequently see projects with well over a 100 users. This isn’t bug tracking, this is QA on an epic scale.

The impact this has had on our application has been noticeable. For many users, the BugHerd widget was taking between 5 and 10 seconds to load on their websites. For our biggest customers, it would frequently time out and not appear at all. Not good. Whilst it’s cool that BugHerd is injected into every page of your website to allow you to log and resolve bugs anywhere, anytime… the bottom line is that it makes scaling a lot more complicated than the usual bug tracker which just loads once and stays open.

Which brings me to why I’m writing this post!

Around three months ago we learned that Heroku (our hosting provider) hadn’t been entirely clear as to how their service handled long running requests (for the technical minded, you can read about that here). This, in combination with an “error” in how Heroku reported request queuing to New Relic (our analytics provider), meant we literally had no idea just how bad our app performance really was.

Without getting into too much detail, we thought these few long running queries were only affecting users with very large projects, and we’d already been working with them to address their concerns. However, due to the way Heroku handles requests, those long running requests were actually affecting everyone…we just had no way to know about it. It wasn’t until Heroku and New Relic fixed their reporting system that we became horrifyingly aware of just how bad things had gotten. Just a handful of our biggest customers were unknowingly wreaking havoc on our entire user base.

This was a heart breaking discovery.

Since that day our dev team has been hard at work rebuilding our app from the ground up. We’ve rewritten our javascript, we’ve refactored our server app and spent a whole lot of time tuning our database. This has unfortunately meant we’ve seen some new bugs creep in, we’ve had some down time, both planned and unplanned, and it’s generally been a shitty couple of months for the whole team. But I’m happy to say there is now light at the end of the tunnel.

This week we will complete the last of our major updates. Everyone is now running our new javascript rendering code, you should now be seeing the benefit of our improved caching algorithms (there’s still some more to come here), our new upgraded database is running a whole lot faster and our app is generally a lot smarter at handling not only the crazy number of web requests we get, but also the sheer volume of data we need to deliver to users.

So before I finish this wall of text, I thought it might be nice to visualise these improvements.

First is a chart of app response time for just the last week. We started the week with an average 100ms response time (already half of where we started a month ago), and by the end of the week with a half dozen performance releases our app now averages 25ms. Four times faster than the start of the week and eight times faster than when we started doing improvements.

But that doesn’t tell the whole story. With our changes to caching and other optimisations, our database has had a massive reduction in throughput.  We’re now serving 90% less database queries than 2 months ago even though our application is now serving twice as many requests!

While the effort has been worth it, and the results for users speaks for itself, it hasn’t been without its hiccups. There have been a number of issues as a result of the past 3 months of work and the rollouts over the past couple of weeks. This has been particularly evident for users that have been “stuck” on old versions of our BugHerd widget, and it has also resulted in some odd behaviour for other users.

Firstly, I’d like to apologise to all the users affected by the problems in the past few weeks. We’re nearing the end of this cycle of changes, and for the next few weeks our focus is going to be solely on addressing the remaining issues that have arisen from these updates. Secondly, I’d like to reaffirm that BugHerd is absolutely committed to addressing the large number of feature requests and suggestions that have been coming our way. Whilst we wont be able to accomodate everyone’s request, I know that quite a few people are waiting on feature updates that we’ve promised and not yet delivered. I hope you can see that we’ve been busy, and that we’re 100% committed to delivering the best possible product to our users.

A special heartfelt thanks goes out to all our customers that have shown patience and understanding during this past few months.  So many of you have stuck with us even though you’ve had problems, and we can’t thank you enough for that. Finally, we have so many advocates and evangelists singing our praises, it honestly makes us proud to do what we do. Thank you.

Cheers,
Alan Downie (BugHerd CEO)

Things are looking pretty good for your startup. You’re half way through your first round of funding and you’re well on your way to being profitable. The problem is knowing if your current growth is enough to get there on limited runway. If you’re spending too much each month, you’ll run out of money before you’ll be able to support yourself on your revenue alone. On the other hand, you may be growing at a rate where you’ll easily become profitable without dipping too far into your capital.

If you’re in this situation, you can choose to spend a little more. Increasing your advertising budget or bringing on more talent allows you to take advantage of any growth you may have left on the table. At BugHerd, we needed a way to optimize the amount we were spending each month, so we could maximize our spending on without our cash dipping too far into the red. The result was this spreadsheet.

All you need is a few months of revenue and burn data, and the amount of money you have now. If this sounds useful to you, go ahead and download it.

If you’re interested in taking a closer look, check out our delve into the underlying maths.

Join the discussion on Hacker News.

Let’s assume your startup is making money, and growing, but it’s not yet profitable. You’re concerned about how much you should be spending. Spend too much, and you’ll run out of money before you can become sustainable. Spend too little, and you’re missing out on the opportunity to invest in growth. Optimizing your burn rate is important for using your capital efficiently, so you can grow at the maximum it allows.

Below is all of the math involved. If you’re not interested in that, go ahead and download the spreadsheet, and it’ll do it all for you.

First we have to understand that the amount of cash we have varies by the integration of our two cash flow functions over time. Essentially, if we take the area under the revenue curve for some number of months and take away the area under the burn curve for the same period, we have the total amount of money we’ve gained or lost over that period. We’ll denote the equation modelling our future revenue as:

and the equation modelling our future burn as:

So the equation that defines our cash over time is given by:

Where is the amount of cash we have now, and is the time from now, in months. To get optimum burn over the period, will equal the amount specified as the safety at the same time when we become profitable (when our net cash flow = 0). We’ll denote this time as and the elected amount of safety as .

So:

and:

We can assume that our burn rate will be a constant over time from now on.

…and then substitute in our burn/revenue equality at , to simplify things somewhat:

Getting the optimum burn from here is dependent on the equation modelling your revenue, but if we use a simple linear regression, then everything resolves to a quadratic. Solve this for :

As:

So:

Go ahead and solve the quadratic via Wolfram Alpha.

And substitute back into the revenue function.

You can do this with any revenue function you can integrate. Or just use our spreadsheet which will do it all for you. Remember that this does not take into account any deviations from your projected revenue curves that may result from changing your monthly expenditures. The results provided via this method are a reference point, and not prescriptive.

Join the discussion on Hacker News.

The more third-party services you integrate into your website, the more your code fills up with redundant analytics, event tracking and other embed scripts and tags. With Segment.io, you only have to implement once, and you can simply toggle the services you want to use on and off. With Segment.io implemented on your site, all you have to do is press a button, and BugHerd will be instantly installed!

If you’re already on Segment.io, turn on BugHerd now and start keeping track of your web projects the right way.

We recently caught up with Rafe Hatfield, the head developer from Suite101, a growing content network that’s been using BugHerd to crowd source and manage feedback for their site. BugHerd’s feedback widget embeds a tab in your page, much like UserVoice. However, BugHerd’s widget allows users to submit feedback using the same point and click technology as the core bug tracker, and the reports are fully integrated into your existing workflow.

This is particularly useful for media sites that constantly push new content. Errors that miss the editors and developers can be easily pinpointed by reader with BugHerd, so that the quality of the site can be upheld.

Tom:

Hey Rafe, can you give me a general overview about Suite101 and what you’re about. What makes you awesome and how long have you been around?

Rafe:

Suite101 has been around since around 1996, initially as an online community for writers, we evolved into a home for writers to publish articles and earn income with a revenue share plan. We’ve spent the last 12 months reinventing ourselves and changing our technology to allow us to grow faster. We’re moving towards a platform that will allow people to share their personal experiences with a view to teach others in a social setting. We’re in the very first steps of this new product, the next few months will see it rolling out.
(that’s a long and wordy explanation but we’re in a very odd place at the moment, slowly evolving into something new – if you want the short version then we’re in content publishing)

Tom:

That sounds like you’ve come a long way. What kind of problems were you encountering with Suite101 that lead you to BugHerd?

Rafe:

The main challenges we have with regards to bugs are getting all the variables correct (OS, browser version, exact process the user is doing, etc), understanding the exact step in the various processes the user is on, and actually getting the user to report the bugs in the first place. There’s also the processing and handling of the actual bugs themselves – being able to easily process new bugs and deal with the flow, without having outsiders clog up Pivotal Tracker.

Tom:

So how has BugHerd addressed these problems?

Rafe:

By allowing the users to register their bugs on the page they’re getting them, we get exact knowledge of what’s going wrong and where its happening. If they’re running the plugin, we get a screenshot so we know we’re seeing exactly what they are, without worrying about browser versions etc. The feedback tab keeps bugs out of the flow until we’ve had a chance to review them and put them into the backlog, and the fantastic integration with Pivotal means that working on them either through the bug herd site, via the widget overlay on our site, or through Pivotal all works to seamlessly progress them.

Tom:

Great! So what kind of issues does Suite101 use BugHerd to manage?

Rafe:

We are using BugHerd to handle all of our front end bug tracking at the moment, and are slowly moving the back end bug tracking in also (historically back end bug tracking goes directly into PT however we want to use one interface for everything).

Tom:

Cool, so what did you change from to BugHerd? What processes have you kept?

Rafe:

Previously we were using Lighthouse, which is a great application but the integration with Pivotal left a little to be desired, and the flow wasn’t smooth. We also use (and continue to use) zendesk, mainly as a communications tool now. Prior to this all of our bugs were done directly in Pivotal, which gave outsiders access to our main project planning tool and clogged our backlog with things we weren’t interested in dealing with as yet.

Tom:

So are there any big changes you’ve seen since using BugHerd?

Rafe:

There is much less back and forwarding with people to get to the bottom of what the bugs are about, our help desk people are much happier with their process flows, the process of dealing with bugs is unquestionably smoother and “neater”.

Tom:

Finally, do you have any other tips for other web dev teams looking to use BugHerd

Rafe:

Tips for new users – ramp up to opening up the tool to everyone. We are very slowly pushing it out to more users, and until very recently only used the bug reporting tool in-house; this gave us a lot of practice to work out the flow we wanted, get used to handling bugs and moving through them, understand the interfaces properly, etc etc. If we had opened to the world from the start it probably would have been a much different experience.

Rafe Hatfield is the head of product development at Suite101, a collaborative publishing platform based in Vancouver. You can follow him on Twitter by his handle @RafeHatfield.

The purpose of this survey was to gain insights allowing us to better suit the needs of you, our customers. It’s important to me to share with you our results, and how we plan to use these insights to move forwards.

An interesting problem in designing your survey is your methodology. The survey had a mixed use of qualitative and quantitative questions.  In this instance this means the difference between open-ended form answers (qualitative as the respondent can answer whatever they like) or something like a radio button list (quantitative because the respondent can select from a pre-defined list, which we can then extract direct statistics from).

When soliciting feedback, try to take any observer bias out of the equation (in this case my bias). This is important. To do this I left many key questions as free text responses. This way the respondent is not guided by my suggestions. While quantitative data is far easier to analyse, setting the categories ourselves would introduce this bias. It’s better to leave these options open ended, see what responses we are likely to receive, and then use that information to optimize the design of further surveys.

The best example of this would be in our question regarding competitors to BugHerd (more on this later).  If I had simply listed businesses the businesses we thought were our competitors in a series of check boxes, the data would be easy to analyze but inaccurate  By allowing open answers, we received data very different from our expectations, which is invaluable for us in positioning and developing the product.

To overcome the difficulty of analysis we manually categorized the qualitative responses, which were then graphed.  These categories can then be used in future surveys (with an understanding they are based on actual responses not my opinion) for statistical validation.

Now, onto the data.

Q. What is your primary role within the company?

We know that the majority of our users are developers of some description. What is interesting to us is the number of users who we would classify as managers. This would be users who, in their primary role, are no longer technical but tasked with looking after a team or organisational performance.

This is an extremely valuable piece of information to us when it comes to how we position the product and understanding how BugHerd finds its way into an organisation.

For example, the pattern we see is a developer encounters BugHerd and then recommends it internally to a manager/project manager. These people become the eventual account holder.  Moving forward we need to find ways to remove as much friction as possible from this process.

This is quite different to a startup or freelancer environment where the person who discovers Bugherd is, in many cases, the same person who pays.

Finally, while we think that BugHerd has a potential to help Marketing or QA teams, it is interesting that only a very small proportion of our respondents come from these fields. This is likely as a result of the positioning we have employed to date.

Q. Of the people you use BugHerd with, who gets the most benefit?

What I find interesting here is the relative importance of non-technical roles like project managers and clients. This is particularly informative from a marketing perspective as it is not a segment that we have actively had messaging to support. It is also important in terms of considering what features to work on. Developers, designers and managers all want and appreciate the app differently, so it’s often a balancing act deciding what to work on next.

Q. What is the primary benefit you receive from BugHerd?

Here we ran into one of the problems of our survey method. This was a free text response allowing us to generate high value insight into the language of our users. However, it does make it hard it visualize and there is always going to be error in re-categorisation of data (which I have had to do to make this graph). To give you an example of how I have done this:

Ease of Use:

“The interface. It is easy to use and clear to understand.”

“Simplicity and clarification of communicating bugs.”

Efficiency:

“Time – it takes less time to report, find and resolve bugs”

“I absolutely love Bugherd. It has substantially decreased the time and effort it takes documenting issues during quality assurance testing”

Task/Workflow Management:

“Simple communication from non-technical clients that still has all the details we need to address an issue.”

“overview of open issues during development and prioritising during delivering a website”

Visual Tracking:

“issue reporting within the website context”

“Pins that point directly to the visible bugs.”

Collaboration:

“The ability to facilitate communication between departments about what needs to be done on the websites”

“Efficient communication for remote workers”

The most interesting part to me regards efficiency and collaboration. I feel these are a result of other things (cause vs. effect)

Its great to know that things we have actively focused (Bugherd’s ease of use, workflow management & visual bug capture) are helping teams become more efficient & collaborate more effectively (achieved) which will positively impact the bottom line of our customers.

If you consider that, even on our highest plan for $180 p/m, Bugherd can effectively pay for itself by saving a team 2+ hours a month.

The next step will be to turn this question into a multiple choice and validate the categorization allowing for correlation between this and other data.

Q. If you could no longer use BugHerd, what alternative would you choose?

This was an extremely interesting response for us. We have traditionally defined our competitive set as being the full-featured bug trackers (Jira, Redmine etc.)

However, the top 7 responses  (almost 60% of total) did not include any of these full-featured competitors.

It’s important to note that this was an unprompted question (i.e. we did not list competitor names). If we did list competitor names we would likely have biased results based on what our assumption of the competitive set is.

Given that, what it does tell us? BugHerd is doing something that hasn’t been done before, or is replacing some fairly prehistoric methods for accomplishing the same thing (screenshots and email anyone?). This is fantastic.

Q. Do you use Bugherd with external clients?

Wow! Exactly 50%!

This is not even as simple as freelancers & agencies vs. the rest. We had previously discovered that some agencies have been happy to use us internally but reluctant to use us with clients. This is often a cultural thing but something we wanted to explore in more detail below.

Q. How disappointed would you be if you could no longer use BugHerd?

People using BugHerd with external clients are more likely to be “very disappointed” if Bugherd no longer existed. This suggests the value that we are providing for teams using BugHerd externally seems to be greater.

What do we do with this information? It helps us focus our marketing and communication specifically. We have previously focused equally between internal teams and agency types. While this is still important we can see through the numbers that attempting to acquire more customers who use us with external clients will likely result in lower churn and greater recommendation due to the additional value they perceive.

Importantly this question is also a very good measure of customer satisfaction that we can actively measure improvement against over time.

Note: If you want to know more about the purpose behind this question then have a read of Sean Ellis’s blog.

Q. Have you recommended BugHerd to anyone?

The same pattern can be seen here. Of respondents, those people using it with external clients are significantly more likely to have recommend BugHerd to someone else.

Again this starts to tell us that much of the products value is in the way that it manages feedback between technical and non-technical teams. While we have always known intuitively this rings true it is good to get some data that supports our assumptions.

Q. If you where to recommend BugHerd, how would you describe it?

 As a little addendum its important to understand what language people use when talking about BugHerd, Asking a question gives us extremely valuable information for landing page messaging and keyword strategy.

Note: I don’t like word clouds very much but it seemed the best way to illustrate the point.

Summary:

We learnt a huge amount through this process and a couple of key themes emerged.

1. Ease of use, efficiency & workflow management are top tree benefits you get from BugHerd (and if BugHerd saves you time it pays for itself)
2. Our competitive set is not what we thought.
3. We provide more value to  those of you using us with external clients

What do we do with this? It is most valuable in heaping us better manage our customer acquisition. The more we know about who our customers are, how they use BugHerd and what benefit they receive the better. This then fuels our marketing strategy though a combination of better targeting, ad messaging, landing page conversion and customer onboarding.

It took me about 1/2 a day to put the survey together using a simple Google Form and then a bit more to do the analysis  However if you consider what we have learned, it’s time extremely well spent.

Next up we will talk separately about the question “How can we improve BugHerd”.

I want to give a quick shout out to @bugherd for their outstanding customer service.

— Joshua Rapp (@rappsodystudios) February 21, 2011

1. Let’s start simple: thank the customer for getting in touch. The people getting in touch with your support desk are among the most engaged people using your application. They have taken the time to write in, so first and foremost just be courteous. Some of our comments on the satisfaction survey specifically referred to the courtesy provided.
2. Do everything you can in a single response. Avoid asking questions about information which could have been found in screenshots, customer data or log files, whatever you have available. Nothing is more frustrating for the customer than being asked to provide something which they already had and making them wait longer for no reason.
3. Use ticket status properly. The customer knows exactly where they stand if the ticket is either:
   • Open: you are leaving the ticket open because you are still working on the issue and will follow up with another response
   • Pending: you are expecting a response before being able to continue
   • Solved: the ticket is deemed solved unless the customer has additional requests
4. Be transparent. If you cannot action the request or a customer asks for a feature which is not on your roadmap explain why. Your customer is smart and a better understanding of your product and why things are the way they are can help them. It’s not always what they want to hear but they will appreciate your straight forward response. Avoid canned responses intended to appease the customer which can come across as passive aggressive. At the very least, make the customer feel listened to.
5. The last and probably most important one: be accountable and action the request. Whether it concerns a bug report, a feature request or just a question, actually doing what the customer asked for seems obvious but support reps are sometimes tempted to blow the customer off with a nice sounding message that avoids them doing work. At BugHerd we have the luxury of running a nimble product development process which allows features and bugs to be fixed sometimes on the same day, but the same counts if you have a 12 month release cycle. And last but not least: we don’t run Support as a department; everybody including the CEO answers support emails.

It hardly needs to be said, but customer service is all-important. It’s like being active on social media. There’s no direct connection to more sales but it most definitely can set you apart from the competition. Good customer service can turn even a random tire-kicker into a fan.

Firstly, how do we normally handle file uploads? We have a form and it posts some data to our server. This can take a really long time, due to a number of factors, such as file size or the users internet connection.

The factors I have listed above can really effect how many requests you are doing. It’s possible, depending on your configuration, that you can do quite a few requests a second but not many simultaneous requests. This is definitely the case if you use Heroku, which is BugHerd’s hosting platform.

In most situations we are in some way limited by memory or server architecture which means we can only serve a limited number of connections at a time. The shorter a request is, the more of them we can handle.

A quick solution would be to simply increase the number of servers available to handle requests. However, if you don’t have that many users it quickly becomes expensive to have all these resources free just in case 10 dialup users all get the idea to upload cat pictures at the same time…

tl;dr Short requests are good for application servers. Long requests are bad:

We can solve this problem, by taking these long requests and putting them on another server. At BugHerd we have chosen S3 for this purpose, but you could use your own server or another provider, like Rackspace for instance, which offers a very similar system.

How is something like S3 different? S3 is better at doing this because it is designed to handle a massive amount of long requests and as the application servers are shared between many users they can afford to have massive amounts of parallel uploads at a very low cost. S3 requests are not exactly fast, but you can do as many of them as you want, and you are only billed when the requests are running. So while your users are uploading, your app servers are free to handle other requests, like serving up your app for instance.

The basic idea here is to tell our application we are going to upload something to S3, our app gives us a policy, which we then use to upload the file in a secure way to S3. Once that is done, we tell our application server, and store a reference to the file’s location in the database.

Below is some example code showing how the process works:

As you can see, it’s pretty simple. We have a signature in our page, which we send with our file to Amazon, then we contact our server to let it know the file upload is done. We also patch in a progress method, which should be pretty straightforward if you have glanced over the JQuery documentation.

The above code is reliant on some server help for policy generation and we’ve put together a sample app that ties it all together. You can fork or clone https://github.com/nelix/BrowserUpload if you’d like to run the sample app. Our sample is written in Rails but really it’s all scaffold and you can set this up with any language that has hmac encryption (hint: almost anything). The repo also has a fork for IE support which is very hacky and doesn’t show progress, that stuff is not covered here, but the example does work.

So that’s it, hopefully you have found that this is pretty simple to implement and it should get some of those long requests off your back and let your application server get back to doing what it’s good at.

If you have any questions or suggestions, I’d love to hear from you.

We recently caught up with BlueChilli, a venture technology company that builds and invests in digital start-ups by providing development rather than cash. As BlueChilli manages the development of many different web applications and projects, all in different phases of their development, keeping track of everything is a huge concern. As BlueChilli has many non-technical founders as clients, BugHerd is ideal for them, and helps them keep track of all their web development projects in a way that is intuitive enough for anyone to use.

TOM:

Hi Jeremy, can you give me a general overview about BlueChilli and what you’re about? What makes you awesome and how long have you been around?

JEREMY:

BlueChilli is a startup investment group that empowers entrepreneurs by providing the technology and business resources to enable non-technical founders build and grow their own tech company. We have a vision to build 100 startups by 2016, a vision that was announced last year and one where we have already made 27 investments.

TOM:

Awesome! What challenges were you encountering that lead you to BugHerd?

JEREMY:

Well, our process empowers the founders of our startups to test the applications we build – so we needed an efficient platform that non-technical users could use – such as our founders and their friends, from any location around the country or around the world (we even have startups in San Fran that we support from Sydney), with no training.

TOM:

So how has BugHerd addressed these problems? Is anything you think BugHerd does incredibly well? Anything it could be better at?

JEREMY:

BugHerd allows us to push the testing to the founders, it keeps them engaged and gives them ownership. It turns regular non-technical users into testers.

Most of the issues we are having with BugHerd are technical, with dynamic and complex sites, sometimes the original marker placement gets lost – we either need BugHerd to capture the HTML, or take an automatic screenshot as a backup.
The introduction of kanban is great, but we would like more customization over the different statuses, and an environment setting (dev/staging/prod). However, it’s improving all the time and as early adopters we like what we’ve been seeing.

TOM:

What are some issues unique to startups that you’ve used BugHerd to manage?

JEREMY:

Startups need to iterate quickly and often pivot, don’t have product managers and don’t have trained testers, so we need an easy way for them to provide feedback, raise issues, and for us to respond without loads of management overhead (and hence cost). Also, we have a dozen or more projects on the go at any one time, in various stages of development or in post-implementation support, and we have staff working across multiple projects in any given sprint, which is a challenge to organize without too much overhead.

TOM:

For those who might not be familiar, can you please describe the process of using BugHerd to report and handle one of these issues?

JEREMY:

The founder raises issues in staging using the BugHerd widget, developers move issues they are working on this sprint (1 week sprints) into “Todo”, and into “Doing” as they are working on them. Once set to “Done” it means it’s been deployed to staging. At the conclusion of the sprint, founders test (on Monday), and move to “Closed” status. Then it’s deployed to production on the Tuesday. This happens every single week like clockwork and we’ve gotten a lot of positive feedback about the relative ease of the process.

TOM:

How did you deal with these issues before BlueChilli decided to use BugHerd?

JEREMY:

We’ve always used BugHerd, even pre-kanban. It always just fit our philosophy.

TOM:

So what are the results? Less errors or bugs? Less time spent in communication?

JEREMY:

Well, because it’s so easy to raise issues, and respond, every founder, tester and developer uses it every day, and our development team spends approximately 80% of their time actually writing code… BugHerd is one important piece of the puzzle that helps keep the team engaged and productive.

TOM:

Finally, do you have any tips for startups looking at using BugHerd?

JEREMY:

If you’re doing user testing, use BugHerd. We’re using it to help us build 100 startups by 2016, enough said.

Jeremy Paddison is the Chief Technology Officer of BlueChilli, a Sydney-based startup incubator and investor that brings ideas and talent together. You can follow BlueChilli on their twitter.