Last week, I visited a CloudBees customer with Kohsuke Kawaguchi (Jenkins’ founder) to interview them. The goal was to understand their key challenges and concerns.

Over the years, Kohsuke and myself have done innumerable customer interviews together and somewhere along the way we have hit on a formula that makes for great customer interviews.

The formula is “Be an intern” (credit: as is usually the case with Kohsuke, belongs to him).

An advantage of tag-teaming is that one person takes copious notes while the other asks questions. The interview goes something like this (replace “software delivery process” by the key problem(s) your product solves):

The Interview

Us: Think of us as new interns on your team, now walk us through the entire software delivery process.

Customer: We were using your software and ran into so and so bug with your software.

Us: Hold on. We will definitely get to that. Right now, tell us why that is important as an intern. If not, lets go through your software delivery process

Customer: Uh ok, I guess it is not important as an intern. Ok - so we have a very typical software delivery cycle. We push the code and then we do a “official build” which is then tagged by QE as golden build.

US: Hold on - who is “we” - is this one team or many? What do you mean “typical” - is that in your group, across teams or standardised across your company”. What’s an official build - who calls it official? What does a golden build mean? Who is impacted with golden build? How long the process take?

And so on. You get the idea. The interview becomes very open ended and helps us be part of their team.

Advantages of this approach:

• No ask-the-experts: Customer interviews are a critical learning process. When product (and in this case the founder of Jenkins) lands up at customers, customers want to jump at the opportunity to make the session as an “ask the experts” session. The intern approach avoids an “ask the expert session”
• Deep learning of the problems: A distinct shift happens in the customer where they stop viewing you as the expert and start explaining how things should work. As a PM - this is where the key learning for the product happens.
• Listening to the customer: When you are not the expert, you have no option but to listen - which is a tremendous skill to have as a PM. Listening to the customer is where you learn about the customer and importantly the customer feels heard before you tell them any solution.
• Validation of the roadmap: The session becomes a “no pitch” session and product management mentally maps problem to the planned roadmap. The usual risk is that product management “shows up and throws up” while the customer sits with folded hands thinking if they should renew or not next year. When you hear the problems and can map to the roadmap, it is a huge validation (or not) to whats planned.
• Explaining your solution/roadmap after listening to the customer: Once you have validated (or not) the roadmap, have heard the breadth and depth of customer challenges as part of this interview process, you lay out your roadmap and how your solution(or roadmap) helps address the key concerns that were raised in the interview.

If you are a product manager, I encourage you to use this as part of your quiver when you meet customers.