We software management trainees here at Fog Creek recently read Positioning by Jack Trout and Al Ries.  Since I'm the marketing director right now, the discussion group found me especially eager to think about how we're marketing FogBugz and Fog Creek Copilot.

Positioning argues that the heart of marketing and product design is discovering or creating the relevant market, and positioning oneself to shine and stand out in it. But what is the market? It's the need we fulfill -- not a technical feature we provide. Companies in varied industries, as well as schools and nonprofits, use FogBugz for many purposes. Some just use it to track bugs. Some put all tasks in it, or manage client email with it.

And so Positioning, like Getting to Yes and the best design books, reminds us that we have to figure out what the customer actually needs, or thinks she needs. For example, with FogBugz, this won't be "bug tracking software" necessarily, but possibly "getting organized" or "one place to put all our work on a project."

Once we see the customer's underlying needs, we understand why a customer is comparing FogBugz to things that aren't like FogBugz at all -- a corkboard where people post their active tasks, or a development methodology. Likewise,  Fog Creek Copilot faces different kinds of competitors (and opportunities!) depending on whether customers use it for personal tech support, enterprise tech support, sales demonstrations, or just keeping in touch and surfing with a friend.

We have to close the gap between us and prospective users, which means we have to find and communicate with them on their terms. That's why we have a FAQ and a technical info page for Fog Creek Copilot.  I'm creating and editing web pages to advertise FogBugz to the different kinds of decisionmakers among our prospective customers.  Hands-on tech types might like our free trial; busy bosses, FogBugz In Two Minutes; thoughtful managers, the FogBugz book; groups in conference rooms, live demonstrations using Copilot.

To help me make those webpages look nice, my colleague Babak recommended that I read Robin Williams's wonderful The Non-Designer's Design Book. I did, and noticed that I could apply Williams's principles of alignment, repetition, proximity, and contrast when editing our suite of marketing materials.

• Alignment: Do all our salespeople, webpages, and ads stress the benefits to the customer?
• Repetition: Do we use consistent language and visuals when talking about those benefits?
• Proximity: Do we make it easy, on every page, for the prospect to find related information or buy immediately?
• Contrast: Do we clearly separate ourselves from the competition -- basically, how's our positioning?

The trainee discussion group is one of those long-term investments here at Fog Creek.  It takes a few hours a month, but it gives us fresh perspectives on what we're doing - we learn from the authors and from each other.  Positioning certainly provoked some interesting discussion and strategizing - as it possibly has with you.

Photos: trainee Jason Rosoff, senior developer Babak Ghahremanpour, and trainee Dan Ostlund on the couch; trainee Sumana Harihareswara facing left.  Not pictured: trainee Eric Nehrlich.

Our boss Joel is quite proud of how FogBugz 6.0 is turning out.  Like a dad with baby pictures, he'd like to show it off.  Thus, the FogBugz 6.0 World Tour, coming in a few months.

The demo will probably take about 30 - 45 minutes, and I'll leave lots of time for questions -- not just questions about FogBugz, but anything about the software development process, really. It'll be completely free.

But how many should we do, and where?  Here's the survey.  Please let us know if you're interested in attending, so we can decide where to fling Joel and his overnight bag.

Just a reminder that this coming Sunday, June 17th (Father's Day), we're making Fog Creek Copilot free for the day.  You can use it to fix a relative's computer, as Joel suggests.  It's way less frustrating than phone-only support.  But you could also connect using Fog Creek Copilot to show each other travel plans, or work on a photo collection together (a phone or Skype connection would come in handy).

Tuning up the relatives' computer when you're home for the holidays is a rich tradition; with Copilot, you can do it on National Legume Day too.  Or Father's Day.  Enjoy!

We want to provide remarkable customer service.  Our boss Joel has some tips on how we do that, including treating your customer service persona as a puppet, taking the blame for problems, and cheerfully refunding customers at the drop of a hat.  They're great.  Today I'll discuss a few other nuances of our customer service practices, and how FogBugz helps.

Ralph Wilson mentioned in his great textbook Help! The Art of Computer Technical Support (Peachpit Press, 1991) that customer service, via email, phone, or face-to-face, is emotional labor.  We're mechanics, yes, but we're also counselors.  If you have zero training and countdown timers on your support calls, then you're set up for frustration, failure, and burnout. You need breaks, you need tools, and you need techniques and training.

• Breaks: Our official office hours for phone support are 9am-5pm, Eastern Time, Monday through Friday (although in practice we often stay here an hour or two later).  During that time, we have 2-6 people available to answer sales and customer support calls.  This means we can take snack, lunch, bathroom, and discussion breaks without always diving back to our desks at the first ring.

• Tools:  The best tool in our toolbox is the customer service functions in FogBugz.  Our Asterisk phone system stores voicemails in there, we can search for similar problems from other customers, and all previous emails from a particular correspondent are a click away.  BugzScout means we get error messages with the file and line number, so we can track down exactly where in the code an error occurred.  (One caller has been amazed that I can browse the source -- hey, customers can too!)   Fog Creek Copilot shaves hours off some calls, because a picture is worth a thousand words.  My colleague Jason just wrote about our use of VMWare for approximating a customer's setup (especially when Copilot is not an option) and testing.  And our Asterisk switchboard, wireless headsets, and programmable phones reduce phone support hassles.

• Training: At Fog Creek, front-line customer support folks use FogBugz to enter bugs and manage customer help requests, Fog Creek Copilot to fix FogBugz problems for customers, and CityDesk to write documentation (including this blog!).  We're using the same software our customers use, so we know its quirks, and we can follow assumptions and jargon in help requests.  And we read the knowledge base, install FogBugz on our own computers, and answer easy questions before the harder emails and phone calls get thrown our way.

• Techniques: Wilson describes many useful techniques in Help!.  One of them: most callers welcome a bit of guidance on the call, so it's fine to structure it to get the problem solved efficiently.  As early as possible in the call (without interrupting the customer), I try to introduce myself, figure out what product's being discussed, and get the caller's name and phone number or email address.  "In case we get cut off, could I get your contact information?" always works for me.  And FogBugz makes a perfect place to store my notes as I create them during a call; you could even create a template snippet to remind yourself to gather certain information.  (This entry is already getting long, so I hope we'll talk more about specific techniques in a future post.)

The first books we management trainees read here at Fog Creek include Mike Gunderloy's book on FogBugz and Dale Carnegie's How to Win Friends and Influence People.  We need both technical and personal skills to provide great experiences to our users.  And Fog Creek helps us learn and deploy those skills, and teach them to the next round of trainees.

On the Business of Software forum, someone recently asked: how can software vendors compete with open source software?  Fog Creek is no stranger to that question.  FogBugz started as a bug tracker, and there are plenty of open source and proprietary competitors in that field.  And Fog Creek Copilot, our remote desktop service, incorporates software from the open source VNC project, and competes with various flavors of VNC and other open source and proprietary alternatives.

Our products compete against lots of other products - free and not, proprietary and open source.  To compete against all of them, we focus on the true, underlying interests of prospective customers.  (Yes, we management trainees just discussed "Getting To Yes" at work.)  I'm going to talk about how FogBugz and Fog Creek Copilot compete.

People consider using open source products for a few reasons. One possible customer interest is "saving money so I can look good to the boss."  In that case, we might talk about total cost of use and ownership.  We can compete there, since setup and support are so quick and easy.  And if the customer wants to see the source code and modify the look-and-feel, for control and reassurance, FogBugz has that too, since you can view and change the source code and the database schema.

But if a core desire for the customer is "using open source for ideological reasons" or "using in-house resources to massively customize all applications," then FogBugz is basically not going to meet that interest.  It's not for them.

You've probably also heard about other ways to compete with open source software: better design and user interface, brand reputation, customer service, features, ease of setup, and so on.  And we absolutely do compete on those factors, for example against Bugzilla, and also against quite a few commercial bug trackers.  But they aren't ends in themselves.  They all serve underlying customer interests.  A few examples:

• Avoiding hassle: Using Bugzilla is like interacting directly with a database using a web form; the user has to learn to behave like a computer.  FogBugz sets up in minutes and treats users as humans, so it takes practically no time to learn.   Everything just works.  That way, customers can do what they're good at, instead of wasting time configuring a tool that's supposed to help.  The design, and our quick, smart support, reassures customers and saves them time.
• Painless migration: People have fled from Bugzilla to FogBugz so many times that we actually wrote a special importer for Bugzilla databases.  We get emails from users literally begging us to help them convert their Bugzilla database to a FogBugz database.  Now every instance of FogBugz ships with this script.  So that's another way we compete: we make it very easy to switch. This saves customers time and worry.
• Vendor responsiveness to customer requests: We have a built-in screenshot tool so testers can submit screen captures as bugs in just a few clicks.  We did this because customers asked for an easy way to attach screenshots, and we took that one step further to make the experience seamless and intuitive.  Customers get better bug reports, improving their software quality.  This works right out of the box and Bugzilla doesn't have anything like it.

As a service, Fog Creek Copilot has a different kind of competitive advantage.  It works through firewalls because we host a reflector.  We manage the server and pay for the bandwidth.  So it doesn't matter that we provide the client applications' source code under the GNU Public License.  Any copycat service would also have to provide a reflector (which costs money) or give up the core customer need of ease of use (because it wouldn't work through firewalls).  The partially hosted architecture provides some shielding against open source competition, but only because it fulfills a key customer interest.

Don't forget that competition intensifies over time.  Your competitors will watch your software improve, and copy it, and there will come a time when you can't make money off it anymore.  Open source developers are great at cloning.   Good software takes ten years but then it's done, and you will have copycats every step of the way -- open source and closed source.  In the long term, we hope that customer service, brand reputation, and other stuff outside the actual codebase will give us an advantage others can't duplicate.

FogBugz works great on its own, but it really magnifies your productivity when you hook it up to your other tools.  FogBugz works together with source control, RSS aggregators, IDEs, and reporting software - and more.  The new FogBugz Ecology page lists major applications and systems that you can use to extend FogBugz's functionality.  We'll be adding to it as we find out about new plugins and mashups - tell us about them.

Also: if you're a Fog Creek Copilot subscriber, you can now cobrand Copilot with your logo, and point your customers at Copilot helpee download pages from your own site to provide a seamless support experience.  Check out the FAQ and branding tutorial.

Fog Creek Copilot, now at version 2.3, has file transfer, Mac support, and direct connect to make tech support really painless.  If you haven't checked it out since the 2005 initial release, check again -- Day Passes are only $5.

I had to make new button graphics for a web page, and they had to match the existing buttons.  I couldn't get/find the original graphics files with the layers that neatly separated the text from the background colors.  So I had to somehow change the text on this button:

which meant that I needed to remove the text and get a blank version of the button and write new text on it.

My first thought was basically "clone the background and paint/pencil over the text with matching background colors to create a blank button."  But my clone-and-paint dexterity wasn't good enough to match the original colors and shading, or I was just impatient.

So now I decided to create the button background anew, and then write text over it.  Using Paint.NET and existing tutorials on gradients, I could only make flat-looking buttons that didn't match the reflecting-light looks of the originals. 

 But then I remembered from the gradient tutorials that you can select certain pixels and then stretch them to cover more surface area.  Well, maybe I could use the rectangular Select tool, copy the gradient pixels from the old button, top-to-bottom

make a new image the same size (248 by 45), and paste the pixels and stretch them to fill the width of the new button.

So now my whole new button was the gradient.

But it didn't look right at the left and right edges, so I also had to find a way to copy the borders on those sides  I lassoed the text in the middle of the old button:

and then did a Reverse Lasso (Edit: Invert Selection) to get everything except the text, and copy it.

The new button only had a background layer.  I added a new layer and pasted the border on it.

Once I viewed both layers of the new image:

I had my blank button, ready for new text and/or saving as a PNG.

In retrospect, I could have done that lasso and paste of the border first, and then stretched the existing gradient pixels in the new file over the middle of the image.  That might have been easier.  In any case, I hope this is useful for other graphics newbies, or anyone who has to remove something from the middle of a background. 

Fog Creek Software has released a new recommended upgrade for Fogbugz 3, 4, and 5 to fix a security problem.  This vulnerability affects FogBugz on all platforms (Windows, Unix, and Macintosh) and all users should install this upgrade.

On a sunnier note: we have a new plugin to make your life easier.  FogBugz for Visual Studio is a free add-in that allows you to browse your current cases from inside the Microsoft Visual Studio 2005 IDE.  Just install the free FogBugz API on your webserver and install the plugin in Visual Studio.  Here's more documentation on the API's abilities; right now it just lets you log in, view cases using an existing filter, and switch which filter you're using.  The API and plugin only work with FogBugz 5.0. Let us know if you need help or have suggestions for improving the API.

I've been gathering notes on some FogBugz tips and commentary from around the web.  You probably already know about the SnagIt mashup with the FogBugz screen capture tool, and the CaseDetective and DBxtra querying/filtering/reporting tools.  But we haven't yet blogged here about these:

Lou Franco and his team at Atalasoft query their FogBugz database to make Scrum Burndown charts.

I take this data and copy to Excel and use linear regression on the data to get an idea of how we're doing on getting the sprint done in time.  I generate the chart, and put a copy in our internal wiki, so everyone in the company can see our progress.

Don't forget: a personalized picture of the day can give you a moment of cheer.

Tony Conrad and his company, Sphere, use FogBugz among other tools to keep far-flung workers connected.

We've adopted a number of tools that keep us ticking, enabling us to maintain a fluid, nimble approach to creating a great blog discovery engine. Here are some tools we couldn't live without...

Rafe Colburn and Nick Bradbury love FogBugz RSS feeds, and want to extend the use of RSS and aggregators to integrate notifications and applications.

Now, the promised tomfoolery: Rory Becker praises FogBugz during an anti-Bugzilla rant. ("Shall we say that Bugzilla was clearly developed with the *nix style user/developer in mind.")  And here's some bug-tracking silliness.

Discuss: What else is out there?

We use FogBugz, Greasemonkey, Asterisk, and Snappy to manage Fog Creek's customer emails, phone calls, and faxes.  It's great for customer service, and for generally managing communication.  Here are some details.

There's a comprehensive email system in FogBugz that both allows email into the system and sends responses back out, tracking emails using case numbers in their subject lines.  We use "FC" as our unique prefix.

Sometimes people want to track their customers explicitly with Clients, Areas, or something like that.  That could make sense if you only have a few clients.  You can change the name of either the Computer or Version fields to whatever suits your needs, such as "Customer ID."  Also, as long as you're using SQL Server or MySQL for your database, you can use FogBugz's full-text search, which includes email addresses and case comments, whenever you're looking for something.

We have lots of customers, so instead of dedicating an Area or the like to each customer, we use search to track and find cases dealing with a particular customer.  We also use "see also from this correspondent" and "see also from correspondents at this domain name."  Those links appear automatically in a FogBugz case where email's been sent or received.

We also use a Greasemonkey script with our Firefox web browsers to automatically pull relevant customer information from our web shop's DB onto our FogBugz screens.  The key for us is the Correspondent email address, but you could use a customer ID number.

We use FogBugz to track phone calls as well as emails.  Whenever I receive a phone call for support and I don't have an immediate answer, I click "New Case" in FogBugz and start entering details.  Or I'll use FogBugz email to send a sales prospect information they request on the phone, and set a due date to remind me to ping them in a few weeks.

Our phones run on the open source Asterisk switchboard software, and we set it to turn voicemail into sound files and email it into FogBugz.  That way, each message a customer leaves for us turns into a FogBugz case.  We've set up separate email addresses and FogBugz mailboxes for sales and support messages, so FogBugz learned quickly which Inbox Area to put those cases in.  Incidentally, we also receive personal voicemails as emailed sound files, which I much prefer.

We do the same thing with faxes, using Snappy Fax Network Server.  Snappy receives each fax, turns it into a TIFF, and sends an email into FogBugz with the TIFF as an attachment.  Again, FogBugz learned quickly that those emails belonged in the Fax Area.

Our online shop sends special email into FogBugz if there's an error or a suspect charge to approve.  Our online contact form feeds into FogBugz, as does recruiting email.  And of course we use BugzScout to automatically turn crash reports from the field into cases.  It's our centralized repository of knowledge, it's easy to extend, and it's just one database to back up.