Rule 1: NEVER let stakeholders tell you what to build.

Why: Stakeholders know what their problems are but not how to solve them.

How to fix it: Let the stakeholder walk you through their challenge and how they are solving it today.

---

Rule 2: Don’t explain to stakeholders what dashboard / tool etc you want to build and (directly) ask for feedback.

Why: It invites stakeholders to (inadvertently) lie to you because they don't want to hurt you

How to fix it: Talk about your stakeholders' workday instead of the solution you want to build. Then build a quick MVP and observe stakeholder behavior (Show, don’t tell).

---

Rule 3: Never ask a stakeholder if they would use your solution if you were to build it

Why: Questions about the future prompt optimistic lies.

How to fix it: Talk about specifics in the past instead of opinions about the future. People can describe their challenges and desires with much greater accuracy when remembering a concrete situation.

---

Rule 4: Your interview partner talks 80% of the conversation, you only 20%.

Why: You're here to learn and not to give too many things away that will make them give you biased opinions

How to fix it: Talk less, listen more

---

Rule 5: Every time you talk to a stakeholder, ask something that could completely destroy the idea of the solution you had in mind.

Why: Most data initiatives fail because they build something that stakeholders don’t want.

How to fix it: The scariest questions are the ones that address the elephant in the room and eliminate market risk. Seek the truth, even if it hurts.

Here are some example stakeholder questions:

Do you think building a dashboard that does {{X}} is a good idea?

Verdict: Terrible question. See Rule 3. 

How to fix it: Find out how {{X}} is currently tackled by the user and how hard it is to do / how much it costs to do. Ask to talk you through a concrete example when {{X}} came up. Check if they are actively working on improving {{X}} to get an idea on how important this is to the stakeholder.

What would your dream dashboard do?

Verdict: Ok'ish. Not helpful on it's own but allows to dig deeper. See Rule 1.

How to fix it: Understand why they want the dashboard to do certain things. You need to understand the motivation behind the feature requests.  

What are the implications of not knowing {{X}}?

Verdict: Fantastic question. Here you can understand the consequences of not delivering a certain analysis, table, report etc. which tells you subjectively how important it is in the overall context compared to other stakeholders. Typical example: Investor Reporting. Many founders will tell you that it's a disaster to not have an investor report in your reporting tool. But when you dig what the consequences are, they usually tell you that an intern spends 8 hours every 30 days to put it together.

Talk me through the last time you needed to make decision {{X}} and were lacking decision support information?

Verdict: Great question.  

How to fix it: "Show" always works better than "tell". This will show you where issues and inefficiencies are and not where your user thinks they are. It's very hard to be "wishy-washy" when going through actual workflows. 

If we built a model that predicts churn with 90% accuracy, would you use it?

Verdict: Bad question. See Rule 2 and 3

How to fix it: The fact that you described a concrete solution and benefit doesn't help. People are overly optimistic about what they would do. Plus: this question is about YOUR solution and it should be about THEIR life!