Recently we had a guest speaker come in to my marketing class to talk about qualitative research interviews. She had some great advice for interviewing customers and getting valuable information out of them. Here are some tips I learned for conducting customer interviews:

  • Be Prepared, Yet Flexible. Always have a list of questions, but use them as a guide. Let the content of the interview go where the customer takes it.
  • Show You Care. It should be obvious to your customer that you care about what he or she has to say. Pay attention! If you don't care, why bother?
  • Don't Interrupt. Never interrupt your customer while they are telling you a story. Instead, make a note of what you wanted to ask about and ask it when the story is done.
  • Pause. When the customer is done telling you a story, pause for slightly longer than you normally would, just to be sure they don't have anything else to add.
  • Be Encouraging. Non-verbal communication (i.e. head-nods) and minor vocalizations (i.e. "Mmhmm") show that you are still paying attention and encourage the customer to keep talking. Also, don't be afraid to probe the customer for more information with short extending questions like "Can you offer additional details?" or "What happened next?"
  • Don't Talk About Yourself. Customer interviews are NOT a two-way conversation - let the customer do the talking. You won't get accurate information by offering up your own insights and opinions.

I used to think that these techniques could only be used for market research at large companies who are developing new physical products, but after this particular class I started to think about how qualitative research applies to software development. Every one of these tips should be applied to our relationships with customers - especially in our initial meetings.

As developers, we often get ahead of ourselves and start planning out a product before we fully understand what our customers want. In my opinion, the first meeting with a customer should be exactly like a qualitative research interview. Allow the customer to talk at length about what they need and what kinds of problems they are trying to solve with the software. Show them you care about what they have to say and hold off on offering up your personal opinions. By structuring our initial meetings this way, we can get a clear, unbiased picture of the situation and create better solutions for our customers.

This past weekend I volunteered to be a Teacher's Assistant at the Ruby on Rails Workshop for Women at Harvard University in Boston. I have to say that I was really impressed by the whole event. Sarah Allen and Sarah Mei started doing these workshops in the San Francisco Bay Area, and I'm really glad that Sarah Allen made her way to Boston so we could have one too. There was a great turnout; a mixture of women of all skill levels and ages, and yes, there were some men there too. It was really refreshing to be in a room full of so many kinds of women programming Ruby on Rails.

In her intro, Sarah described her hope to one day attend a meetup where she did not "personally double the number of women" in the room. I certainly know what that's like, and I'm so happy I made the choice to donate a Saturday to this event. This workshop felt so different than any Ruby or Rails event I've attended. There was no judgement, no attitude, no "are you really a rails developer?" - there was just a bunch of people who wanted to learn and some other people who wanted to help.

Thanks so much to Liana Leahy and Mary Tolbert for organizing this event, and to Sarah Allen and Andy Gregorowicz for presenting to the group.

You can read more about the workshop in some post-workshop blog posts from Liana, Sarah, and Andy.

So I've been in grad school for about a month now, and it's going really well so far. It's a ton of work, but my classes are super interesting so I can't really complain too much. :) I decided that I should start a new series of articles on this site, henceforth to be known as "Things I Learned in Grad School." As you probably can gather from my oh-so-creative title, I plan on doing a series of short posts with some random but useful things I learn while I'm at school. So let's hit the ground running with a couple of little tidbits I learned in my Intellectual Property class!

NDA's & Trade Secrets

Did you know that it's not always necessary to make your employees or partners sign a Non-Disclosure Agreement (NDA)? Or if you're the employee, did you know that if you haven't signed an NDA you are still obligated to keep your employer's trade secrets private? Though an NDA is the easiest way to prove in court that ideas were supposed to be kept private, it's not the only way to win a case of stolen secrets. Your ideas and trade secrets are automatically protected by trade secret law as long as you make a reasonable effort to keep them secret. There are also some relationships (such as employer/employee) where the law assumes confidentiality. So if you haven't signed an NDA, don't assume you can shout other people's secrets from the rooftops, and make sure you know your rights if someone's shouting yours.

P.S. This information is based on United States laws. I'm not sure how it works in other countries, but if you know please enlighten me in the comments. Cheers!

Oh hey there... it's been a while, eh? I've been just a teensy bit busy saying goodbye to New Zealand, traveling around Australia, flying back to the US, emptying my storage unit in AZ, packing my life into 2 small vehicles, driving across the country, catching up with fam & friends, and finding a place to live in Boston. But enough with the excuses, I'm back now!

For those that didn't know, I'm going back to school this fall at Northeastern University. I'm super psyched about getting a master's but a little nervous at the same time. It's weird to be doing the school thing again. Anyways, I'm moving to an apartment in Boston in a couple weeks, so I have a new community to infiltrate! If you're in town, let's hang. :)

P.S. I'm also looking for part-time rails work in the city (or I'm willing to work remotely) while I'm in school, so if you know anyone with an opening, I'm all ears!

Lindsay Ucci (aka Ooochie!)

Lindsay Ucci

Ruby/Rails developer and wannabe pastry chef. :)

Welcome to ooochie.com! I'm Lindsay Ucci, and I'm a web developer in Boston, MA. If you're in the area, please get in touch!

Design by Dan Ritz, FeedBot by Matt Forsythe, and Powered by Mephisto