We love receiving feedback and suggestions via our people powered forums, and 99% of the time these cover important points which we resolve as soon as possible in order to maintain high levels of customer service.
It`s a rare thing, but there have been times in the past where suggestions have been made for features that are already present within fixx, similar to the insights I shared in my previous post. In this post I am going to share another of these with you.
A great example is the results of a filter, unless specified, these can return a list of any matching issues spanning over a number of projects. The way they are presented currently, shows various issue attributes such as its ID, Priority, status, Type, Title and who it`s Assigned to.
One suggestion was to add more columns to the filtered list of results which would present more meta-data to the current user, such as the Project it falls under, when the issue was created and when it`s due to be completed by.
This is a very valid point, and we took this into consideration whilst designing fixx, and we came to the conclusion that the information which is currently onscreen is the most important and fitted the workflows we created during the design phase.
To make sure people don`t go without, we also implemented a hover activated Quick Information box over each Issue ID which displays the remaining issue attributes as can be seen in the screenshot below. To show the Quick Information box, all you need to do is hover your mouse over the issue ID for a couple of seconds.
I`m betting that a lot of you were not aware of this feature at all. There are a few more of these posts on the way, so make sure to watch this space for more great tips.
Yesterday, Sarat and I were doing some pair programming on our new but shockingly large 37" LCD TV that's on the wall in our fancy meeting space in the lab.
Pair programming is fun and you learn a hell of a lot! If you want to know more about why this is the case, I suggest you read this great article by Obie Fernandez.
We were ironing out some bugs for the fixx 1.7 release, and I had a filter set-up to give me all the issues that had to be resolved for that particular release. As a result I was jumping back and forth from the filtered list of issues, to the full view of the issue we were currently working on.
It was in this process that Sarat made, what seemed to be an odd observation at the time; that I was doing things wrong. I couldn't understand how, as fixx is made to be simple. I went back to the Dashboard and proceeded to click on my "fixx 1.7" filter to go back to the list of issues we were working on.
Sarat then noted "You do realise you could have got back to that list by pressing the Issues tab, rather than navigating back to the Dashboard and invoking your filter...right?".
Obviously I was not aware of this, and feverishly tried it out to find out he was right. Of course he's right; he wrote it!
fixx remembers your last used filter no matter where you go in fixx, and when you return back to the Issues tab presents the list of issues from the last filter. Even if you apply a temporary filter without saving it, the results of that filter are remembered in your session, and can be viewed once again when you return to the Issues tab.
It's evident that I was in need of this piece of functionality, as issue tracking should not by obtrusive by any means, and it turned out to be there all along but I just wasn't aware of it being the new guy in the lab HQ. You can tell that a lot of thought gone into the design and functionality in fixx, and the more I think about it, the more it makes complete sense. As a result this is one gem I want to share.
You're either going to read this and think, how on earth did he not know that, or you're going to go away and try it out for yourself and increase your productivity. Either way I'm happier that I am now aware of this, and hope that it manages to have an impact on the way a few of you use fixx.
A recent conversation on a local community forum about a software vendor who required the filling in of a 2 page form just to get in touch raised my irk and reminded me of key marketing errors that ISVs seem to make. I wanted to share these in the hope that budding entrepreneurs avoid these mistakes that can be very frustrating for customers.
Not publishing your contact details
Yes, you can have a Contact form that tries to collect structured data to allow you to respond to queries but not publishing your e-mail, telephone number, or address is a big no when it comes to selling products online.
Other than building trust in the customer that you are not a doubt-able business, it encourages customers to start a dialogue in a manner that they choose and at a time they choose.
Requiring sign-up to download your free/trial product.
To be clear, there are niche sectors and products where it might well be required to capture a lot of customer information before you let them download a product (no examples I am afraid).
However, for most software products and especially in crowded marketplaces, it just doesn't make sense to force customers to go through a lengthy sign-up process and gather their auto-biography to let them download the product.
If the trial does not convince the customer to purchase a product, then I doubt any direct marketing gimmicks will.
Having a blog / news section that doesn't say much.
A blog is a powerful marketing tool, but I see this so often that I had to mention it. They usually fall into 1 of 2 categories,
Press Releases These blogs and news sections are nothing but press releases with a fancy picture added to make it look more personal. They usually talk about how awesome the company is, or how a new client has decided to choose their awesomeness, or how they are doing awesome things.
Don't get me wrong. There is nothing wrong with keeping readers up-to-date with your successes and promoting the good work you are doing. The problem is people will get frustrated with all the self promotion if you have nothing useful to say eventually.
Journal I know of a few companies (whose names I shall not mention), who excruciatingly detail every mundane activity from buying new desks to an employee being off sick. How is this useful to a customer, fan, or prospective employee? All it tells them is that you are dull and have nothing useful to say.
Having a blog but not allowing comments
Note that I am not saying that you should not moderate comments (we moderate all our comments). Moderation is fine as long as you allow some form of feedback and a way for people to engage with you and react to your blog post. Rejecting criticism and allowing only nice comments might sound prudent but people are bound to take their criticism elsewhere, where you have no control over the medium.
Lack of spam prevention on the blog
As a professional company, it reflects very badly if you do not moderate your blog or have spam prevention tools on it. This is a no-brainer given most popular blogging platforms allow this or it is fairly easy to implement in a custom blogging solution.
Our solution to this problem is to moderate all comments, whether it be for spam or inappropriate content. Even regular comments are not approved until someone manually approves it. This means that the quality of the comments and dialogue is fairly good.
Competitive comparisons
The biggest purchasing activity that a customer performs is to compare competing products to help make a decision on which one to purchase. It just seems obvious then that it is a great idea to include a matrix comparing your competitors to your product.
The practical flaw with comparisons is that they are never objective (unless they are on Wikipedia). Do you know anyone that actively lists factual weaknesses against their competitors? Most people I have spoken to say they immediately dismiss comparisons with competing products as they never trust them.
Your effort is better spent in highlighting the benefits of your product and why a customer should consider purchasing your product on it's own merits.
Putting valuable content in inaccessible documents
Lots of companies have excellent case studies and valuable marketing material but in a moment of uninspired genius, they decide to make them available in either PDF format, or worse, as Microsoft Word or Powerpoint files.
There is nothing wrong with a well-designed concise PDF that people can take away to read in their own time. We use them ourselves. The problem is that most of these PDFs were made for print (large sizes and unnecessary graphics) and just dumped in a download-able folder making it tedious for the customer to get information.
We at hedgehog lab love testing, infact our flagship bug tracking product, is geared toward tracking those bugs and delivering better software.
Well now there is an awesome test management suite on the block called testuff, which executes manual software tests and reports the flaws found in these tests. To boot testuff can output these results directly into fixx and other bug trackers!
From their site,
Testuff is an on-demand service for managing and executing manual software tests and for reporting defects. It is a test management suite that includes management for various test stuff: cases, runs, defects and more.
What's unique about testuff is the ability to attach video footage of each test and attach it to bug reports in order to quickly replicate and highlight the problem within your software to developers. Isn't that cool!
Yay! It's finally here. I am excited to report that we have just released fixx 1.6, which has some exciting features that you have been requesting.
The highlights of this release are,
The REST API is finally here. It is limited but a great start. You can access the documentation for the API by upgrading to 1.6 and going to /api.jsp in your fixx installation. If you would like to see specific functionality in the API please request it.
So you are a small company or ISV that develops software products. Your company is doing great and sales are increasing but you find that you are spending more and more time doing support and dealing with irate customers. You are developer(s) at heart and find it frustrating to deal with customer service and support. After all, why should you? It is not your core competency. You feel you should focus on what you are best at, coding.
In a moment of genius, it strikes you that if you can outsource accounting/book-keeping and your legal issues, why not outsource your sales and support to a company that specialises in sales & marketing. This would free up all your time to work on some beautiful code. Tip : Do not do it!
Outsourcing your sales and support is one of the worst ideas you can conceive of. Forget about cost-cutting, efficiency and all the apparent benefits you can see. Just don't do it!
Customer service is a competitive advantage
Whether you are a small business or large, customer service is one of your biggest competitive advantages. All the bells and whistles, features and innovation in your product combined are still worth less than delivering exceptional customer service.
Very few companies can get away with poor service and a great product (I would love to hear if you know any). On the other hand, a lot of companies do great with exceptional customer service and mundane products. Zappos sells shoes. But try convincing their customers they are the average shoestore and they will probably disagree.
Customer service is marketing
This is not rocket science. Great customer service generates word of mouth and creates fans. This directly leads to increased sales and recognition. Do you spend lots on PR and advertising? Try cutting that spend and investing in great customer service.
Customer service is employee retention
Great customer service is not just about selling and marketing. It also generates motivation in your team, helps your employees spread the word about how good you are and creates an environment where everybody wants to work.
Customer service is about knowledge
At hedgehog lab, we encourage and sometimes require that our developers deal with support and sales queries. This is because no amount of documentation/manuals/training can give anyone else the deep knowledge of a product that you as the developer have. Someone who is not involved with the company on an intrinsic and daily basis will just not have the knowledge and answers required, resulting in canned responses and delayed support.
Customer service is not rocket science
Despite customer service being a great skill to have, it is not a complicated science and comes naturally to most people. It is about being polite, responsive, giving the right answers, and being emphatic in dealing with problems. Yes, you might need some experience to become good, but there is absolutely no obstacle (other than attitude) to prevent delivering great support.
All of these principles apply whether you are a small or large company. Whether you have specialised support staff or do support yourself depends on your size and business, but for God's sake, do not outsource customer service and support.
I recently got asked by a customer about whether we eat our own dog food in using fixx (which we do) and the conversation veered towards what I think are bug tracking best practices.
A lot of the so-called best practice is just common sense (as it always is) but it is surprising how little they are used. Therefore, I thought I would share what we feel are bug tracking best practices from the view-point of 3 different roles.
For end users
When you report a software bug, it is imperative that you detail how the bug was caused in the first place. This will help the developers in finding the root cause and fixing it.
Never provide a solution unless you are a developer in-charge of the functionality. Leave it to the developer to implement the best solution.
For Developers
Be patient! We all know how frustrating bug reports can be. Try to re-assign the issue back to the reporter and ask for clarification rather than dismissing it.
Don't be defensive. I have certainly been guilty of this. No developer likes being told their code is buggy, but try to verify whether something is a bug or not before you dismiss it.
Try to use filtering, reporting and organisation features in the bug tracker to keep your focus on a specific set of issues.
Do not close issues unless you raised them. The only person who should close an issue is the person who raised the issue and can verify if it is resolved or not.
Try to provide estimates that accurately reflect the effort required for a task.
Added by David in comments - If you are working on an open source project, try to provide a suggested solution (in the form of source code patches) along with the bug report.
For Project Managers
Resist the temptation to keep adding new "fields" and meta data. Remember that the focus of the bug tracking system is not to store boat loads of information but to enable you to get things done and fix issues.
Try to keep the workflow simple. The key is to get an issue from open to closed in the fastest time possible. Complex workflows only serve bureaucracy and encourage procrastination in the process.
Trust your developers and testers to make the right decisions. Do not enforce too much control with complicated permissions and umpteen approval/review processes to get a bug resolved.
Try to keep tasks or issues that are small and achievable. "Develop a visitor management system" is not a feature/task, it is a project (as ludicrous as it may seem, this is a real world example).
Don't go overboard with reports. Project Managers love nothing more than constantly generating reports that all say the same thing with a different presentation.
I would love to hear if any of you have any other tips or best practices that you use in your organisation.
The year was 1999. It was my first year of University and I had a compulsory module titled "Fundamentals of Software Engineering". As a self-taught programmer, who liked to learn things by "hacking" at code, there was nothing I dreaded more than a 40-year old balding professor who was going to preach "methodologies" and talk about some language used in World War I called Ada. Why couldn't we just get on and create some cool Assembly code and hack on those spare micro-processor units?
Turns out that the professor was not that boring after all and methodologies were quite important in the real world. Between the yawn inducing talk of SSADM and boring geometry of UML, we talked about gems like No Silver Bullet, The Mythical Man Month, and other interesting discussions on real-world software delivery.
It was in this module that I learned of the then revolutionary [sic] software development methodology called Iterative Incremental Development. It just made sense! This was the real deal and I was going to conquer the world with an all new way of developing software. And then I got a real job!
The iterative incremental model was primarily championed in those days by the Rational Unified Process, which had more templates and documentation than my entire university course books combined. It was the flavour of the day, and it was meant to solve all our software engineering pains.
Fast forward nearly 10 years and the web is now filled with talk about how agile development will rescue the economy (interesting, Toyota reported their first operating loss in their 71 year history today). Heck, SCRUM is so cool, it is the only software development process where I can call someone pig and still keep a straight face.
Let me make it clear that I (and my company) believe and practise the core principles of Agile Software Development, primarily the iterative incremental development, transparency, and working systems at all stages. I have no problem with promoting and encouraging agile development, however, let's just be clear that this is nothing new. Scrum was mainstream since 2001 and iterative incremental development preceded even that.
Agile Software Development is not about tools, technology or marketing buzzwords. You don't need fancy words like sprint, card walls, or Scrum to practise an agile development process. Agile development is about people and process, and no one has a monopoly on this.
Hi everyone, I'm Damian - the newest recruit to join hedgehog lab. My official title is Product Manager (manager at only 22 years of age!), which means it's my role to manage and run development of fixx, solomon and Product X (the mystery will soon be unveiled) so we can all get plush new Audis.
I like the fact that straight away, I have been put in a position with a fair bit of responsibility, which is great as it means I get to experience all areas of business and I'm able to directly shape the future of our products. So if you have any queries or features you want for upcoming versions, I'm your go-to guy to make this happen - damian@hedgehoglab.com or alternatively add suggestions to our forums.
On this note, we are getting ready to release a new version of fixx early next year (1.6), with a 2.0 release being planned for summer 2009 which I'll be heavily involved in...get ready for some big changes!
I also want to take this opportunity to quickly talk about solomon - our CRM and web-based contact manager, which is looking mighty fine...don't worry you won't have to wait much longer! It'll be worth the wait as you will soon be able to see the thought and experience design that has went into the interface and the performance should be lightning fast with lots of JavaScript (or AJAX for your 2 point ohs) magic binding the entire thing together.
A bit more about myself. My background is in Computer Security and I have joined the lab pretty much straight from Uni. I am one of the cool kids in the lab who work on a Mac, not a PC (hello Mark!), and in my spare time I dabble with Ruby and Java, which is handy as it means I can hit the ground running with both fixx and solomon, which are both developed in Java.
In the short time that I've been here, the things that I really like about working in a start-up are transparency and team discussions. The former is self-explanatory, as it means that no business related subject is taboo. The daily team meetings and discussions are great because I'm able to voice my opinions in a group of very intelligent people. This also means the turn-around on ideas is pretty darn fast too!
I'll leave it here for now, but I suggest you watch this space for some exciting product releases and announcements over the next year.
