What action should change?
Ask Before You Build
What if the most valuable Power BI skill is knowing when not to start building yet?
A practical workshop on turning requests into better analytical problems before the team commits to a solution.
DOES THIS SOUND FAMILIAR?
Start with what is actually happening.
- Stakeholders ask for a dashboard and development begins immediately.
- Requirements describe fields and visuals rather than decisions.
- Teams discover important assumptions after the build has already started.
- Developers deliver what was requested but not what was actually needed.
WHAT WE NEED TO ANSWER
Good work starts with better questions.
What does success look like?
What assumptions are already being made?
What does the metric actually mean?
Who needs the information — and when?
At what level of detail?
How should it be delivered only after the problem is clear?
WHAT WE PRACTISE
The scope follows the problem.
I do not force every engagement through the same checklist. These are the areas that may matter; the agreed scope determines how deep we go.
Turning requests into decision questions
Defining success before building
Surfacing assumptions
Clarifying business meaning
Understanding user and urgency
Choosing information and level of detail
Challenging whether a report is the right solution
Using coaching-style questions without turning every meeting into coaching
WHAT YOU GET
Something you can use after the conversation ends.
The output should help you make a decision, change a practice or move the work forward. It should not exist simply to prove that work happened.
Interactive Workshop
Participants practise the approach rather than only hear about it.
Questioning Framework
A repeatable sequence the team can use in requirement conversations.
Live Scenarios
Examples where participants decide what to ask before they build.
Build / Don’t Build Exercises
A deliberate challenge to the assumption that every request needs another report.
Team Checklist
A lightweight reminder for future discovery conversations.
HOW IT WORKS
Enough structure to make the work clear. Not so much process that the process becomes the work.
Discovery
We clarify the audience, current level, recurring problems and what people should be able to do differently afterwards.
Design
I shape the agenda, examples and exercises around those needs rather than forcing a standard deck onto the team.
Live work
The session combines explanation, demonstration, questions and hands-on practice.
Follow-through
You leave with material, patterns and clear next steps for applying the learning at work.
YOUR TIME COMMITMENT
The main time commitment is the live interactive workshop. A short discovery conversation happens before delivery so the session can be shaped around the team.
A GOOD FIT WHEN
This is likely to help if...
- Your team spends too much time building before understanding.
- Developers want stronger business conversations without becoming business analysts overnight.
- You want to improve requirements through better questions, not more templates.
IT MAY NOT BE THE RIGHT FIT IF
- You only need technical Power BI training.
- You need formal product-management process design across the organisation.
If the problem is real but the format is wrong, that is useful to know early. I would rather redirect the conversation than force the challenge into the wrong service.
ASK BEFORE YOU BUILD
What if the most valuable Power BI skill is knowing when not to start building yet?
Bring me the problem, not a polished brief. A few sentences about what is happening and what you would like to change are enough to start.
Discuss team trainingPREFER TO WRITE?
Send me a message.
You do not need a polished brief. Whether the topic is Power BI, Fabric, AI, team training, mentoring, coaching or simply a challenge that needs untangling, leave a few details and we can start from there.