We all understand that customer interviews are solid gold at almost every stage of our products. And yet, many of us don’t know/use some of the basic techniques for these meetings.
Putting together a bunch of ready-to-use techniques here, in the hope that it can help some of you run better interviews, and thereby build better products.
In a nutshell:
- I borrow from my sales experience - some of the steps we use in lead qualification are quite relevant to PMs (this post on how PMs are simply longer-term salespeople)
- I also use typical IT-services discovery techniques (which excel in coverage, even if insight isn’t a primary objective)
Obviously:
- This isn’t going to help anyone who doesn’t do the basics (homework, expectation setting, relationship building, etc.).
- These have to be applied in context. Type of customer, type of person, depth of relationship, stage of the product, etc., have to be considered.
- The “example starting point” questions are merely to illustrate/clarify the point, and may not be un-biased enough for your specific enquiry.
- Some of these techniques can be wildly open-ended or mildly offensive when used without good judgement.
1. Workflow mapping:
This erstwhile favourite of IT consultants interviewing specialists at large firms (they have since moved on to workshop-ing) can be a great way for PMs to understand almost any type of customer.
Starting point examples:
- What’s your current request-approval workflow?
- How do you do X?
- When you get this call/request/error, what do you do next?
- Can you take me through a typical <insert process name>
2. Points of interconnect:
This is simply enquiring where/how another ‘stakeholder’ (person/department/company/regulator/etc.) gets involved in their workflow. I love these interconnects cos they reveal conflicts, pressures, and levers you can push. Bonus: it sometimes reveals what they actually think of a person/department/type of customer.
Starting point examples:
- Who all do you work with?
- Oh, so where does Accounting come in?
- How does this work from a customer’s perspective?
- If you wanted to change this, who all will have to say yes?
- How do you get buy-in for this?
- Who all ask-for/approve the budget for this?
3. Pressures and levers:
If you interview a stakeholder, and leave the room without understanding his/her KPIs or OKRs, you have a problem. This is the north star to empathize with them or understand the “why” behind their decisions and actions.
Starting point examples:
- When was the last time you had a good week/month/quarter?
- What is your latest big win?
- How do you decide between x and y?
- Do you dashboard for leadership? What metrics do you track?
- What keeps you up at night?
- Last session with your team - what feedback/encouragement/news did you give them?
- What kind of person would you hire into this team?
- If you were promoting from/into this position, what will you check?
4. DILO:
DILO, or “A day in the life of…” (an admittedly over-used technique) can be quite effective when used with good judgement. Obviously, this is better for a situation where you are discovering problems/solving for a person or role, rather than for a specific problem.
Starting point examples:
- Typical day/week/month
- Best/worst day last week
- (Asking a manager/peer), what does x do on a daily basis?
5. Alternatives:
This one is as simple as it sounds. Simply finding out what they currently use/what alternatives they are considering is necessary for a good product or sale.
Just remember to dig a little deeper:
- “How do you do this” is usually better than “which app do you use for this?” Cos they may not be using an app/system at all. Just think of how many folks shop without a list in hand, or keep in touch without a CRM. Or how many companies don’t use accounting software (and simply engage a trusted CA/CPA).
- Stay open to the possibility that they don’t do it at all. For example, some companies may not even do stuff like 3-way reconciliation or penetration testing.
6. Decision flows:
If you are speaking to experienced folks/experts from a specific discipline, it may be worth finding out why certain decisions are made. This is particularly helpful in filling the inevitable gaps and omissions that occur in full-cycle enquiries like workflow mapping or DILO.
Starting point examples:
- How do/did you decide what to pitch/buy/etc.?
- Why x, and not y?
- Why now, and not later?
7. Doomsday scenarios:
The primary thrust here is to find out if a particular doomsday scenario is actually scary. This helps assess the criticality of a person/process/system, and by inference, stuff like pricing, urgency, etc.
Starting point examples:
- What will happen if x went down for a day? (Alarm bells should ring if they are vague, or even calm when answering this)
- When was the last major issue in/with/around x? (Alarm bells should ring if they don’t immediately recall one)
8. Aspirational states:
Figuring out who they admire is good insight into their own aspirations. The reverse (I don’t want to end up like x) is generally less powerful. For some reason, people/departments/companies seem disposed to overlook the failures and amplify the successes of their peers. This is different finding out their/their department's/their company's KPIs, in that it focuses on peers, peer companies, etc.
Starting point examples:
- Who’s the best x you know….
- Who do you think has done this well?
- Who do you benchmark with?
- What will be different in 3 years...
Right, I think that’s a big enough to start with. To sum up, an initial list of techniques:
- Workflow mapping
- Points of interconnect
- Pressures and levers
- DILO
- Alternatives
- Decision flows
- Doomsday scenarios
- Aspirational states
I hope you got something out of this. Please do write in if you got something out of this; if you disagree, have something to add, or simply have a good story to tell. Thanks for reading!
