Back when I did my very first customer development interviews, way back in 2007 for an aborted Slacker-player-over-cellular-networks company, they were called "requirements gathering". Go out, get a big list of requirements, write a product spec, release, and bask in your glory. Pretty simple.
Needless to say, my approach and techniques since those halycon days has changed a lot. Now I believe that users have no idea about solutions; they only know about their problems.
Inspired by Cindy Alvarez's (@cindyalvarez) post, here's a real-world list of questions I recently asked a number of potential oneforty users and my thinking behind each question:
1) How/why do you use Twitter? (Make sure to push on business/personal use to understand both)
2) Tell me more about what you think Twitter is (For others in your industry / average users).
3) How has your use of Twitter evolved? Are there any particular things about Twitter that suck?
4) Do you use any tools for Twitter or other social networks? (Note that I don't ask where they find Twitter tools; I don't want to assume that they go looking at all.)
5) What sorts of Twitter tools would be so useful that you'd be willing to pay personal money for? (The personal use question - do they *really* want/need Twitter tools? Consider it a pre-emptive "how disappointed" Sean Ellis question. If the answer is "none", it's the equivalent of a less than 40% "very disappointed" response.)
6) What sorts of tools would you be willing to spend your employer's money on? What is your budget? Do you need a Purchase Order or approval above a certain threshold? (Pricing discovery to gather lower stakes information about willingness to pay - with OPM.)
One of the things that you'll note is that there are only six questions. These are the six questions I want to get answers to; they don't have to come in this order, but I want to try to get to them. They serve as jumping off points for each stage of the interview, not the next step. If the interviewee goes off on a tangent, it is my job to follow her there. I can cut her off if and only if we're running short on time. If time's not a worry, exhaust the tangent, then and only then move on to the next kickoff question.
With these kickoff questions, I start as far back as I can so I don't assume that the problem I'm trying to solve is actually a problem for my user base. Even if I've done previous interviews and come to a pretty firm problem statement, I always start from the beginning to try to get the user to come to that same problem statement organically. If the user doesn't come to that statement, I abort the script and dive into the problem.
I also never, ever suggest or test potential solutions during customer development interviews. Once upon a time, I did. I would suggest a number of potential solutions to my interviewees and ask them to rate or rank them. Turns out they always chose the solution I secretly liked the best. What a coincidence, that. It almost convinced me that I could skip the whole discovery process because my market research (read: Googling) was so good.
Maybe I'm not as good as others who conduct these sessions, but I had a hard time shielding my biases when talking about solutions with interviewees. Users don't know what solution is best until they actually use it - they only know their problems. So I stopped polling potential solutions and now I rely on interaction data and metrics by actual users of the actual product or MVP.
Again, my magic phrase in every customer development interview is "that's interesting - tell me more." (Note: this also works great on dates.) Also, I never ask a yes/no question, I let pregnant pauses hang in the air until they're almost awkward, and sometimes I'll even willfully mischaracterize a interviewee's opinion to elicit their response - all in hopes of getting the interviewees to keep talking so I can get every last insight from the brief 30-60 minutes I have with them.
Hopefully, seeing a real, live customer development script used by a real startup with real potential users has been useful. Fire away in the comments if you have any questions, concerns, or suggestions on possible new approaches.