Why The New Agency switched to BugHerd

We recently caught up with Alan Jones Co-Founder of The New Agency to check how their switch to BugHerd was going. Here’s what Alan had to say:

Tell me about The New Agency

We’re a digital agency that tries to take a proprietorial view of the work we do — we ask the question, “If this was my online business, what would I need to make sure my marketing spend was actually creating recurring transactional relationships with my customers?”. About half our work is for brands, either directly or through larger traditional agencies who need help with specialist digital skills. The other half of our work is building web platforms for early-stage startups; typically people who have a great idea, a little money, but who don’t have a software developer for a best friend.

Why did you start using BugHerd?

We’re not into the idea of full-time employees — we think it’s bad for the people who work with us and it’s bad for us, for various reasons. We prefer to work with freelancers on a per-project basis so we can assemble the best team for every new project, instead of apply the team we’ve employed to every new project, whether it’s a good fit or not.

Working with talented freelancers means lots of working remotely and lots of asynchronous team communication. All the tools we use to deliver our work are cloud-based, and in Bugherd we’ve found a tool that lets us run a freelance, remote team super-efficiently.

When we have a client who’s interested in giving us feedback on the project while it’s still in development, we can use BugHerd to give them an easy way to give us productive feedback we can actually use, without getting bogged down in showing them how to use a project management or traditional issue-tracking tool. 90% of the issues our clients report are visual issues rather than UX, so BugHerd lets them point-and-click and give us everything we need to understand what they mean and act on it.

How were you tracking website issues previously?

Often we’d have to use the client’s own tracking tools, such as JIRA, but if we were able to choose our own solution, it would most often be Basecamp.

How does this differ with BugHerd?

Basecamp’s really a project management tool, and issues is just something you can do with tasks if you choose to. So on the one hand it was good to get client feedback in the one dashboard project management tool, but on the other hand, because Basecamp doesn’t capture most of what we need to know about an issue, most often an issue report from a client was just the start of a series of emails or calls back and forth just to figure out what they meant, never mind get started isolating and resolving it.

Basecamp’s also actually pretty bad at presenting large volumes of information in an easily-comprehensible fashion. If you’ve got a small project, a slow project or a small team, it can be pretty good, but it doesn’t scale really well. So far, we haven’t seen a project too big for BugHerd — it’s really efficient in its display of information about the task at hand and about the overall project.

Has it changed any of your old processes?

There will always be clients who believe they can pay someone money to go away and come back in three months with a fully-formed web business! BugHerd hasn’t solved that problem for us. But it’s lowered the bar significantly on that, so more clients engage earlier in product development than before, and more people in our team get involved in issue reporting than before because it’s so quick and doesn’t require another tool open in another browser window. There’s more sharing of the load, less leaving it to the project manager or account director to manage the issue tracking.

Any features you would like to see added?

I’d like to see a solution for iOS and Android issue reporting, even if it’s just the HTML5 clients, but ideally native too. I’d really like to see BugHerd incorporate some image hosting so that one of our designers could upload some static mockups to a secure URL, share it with a client, and get some feedback on a PNG, and have that in the same issue repository as the eventual platform we build for the client.