How do I ask for critical feedback when demoing a tool/dashboard/widget

Question

I've read How can I ask for candid feedback from my manager? and How politely decline positive feedback? and concluded that these answers were primarily for the individual, i.e. feedback to the performance of the individual.

My question pertains to the subject of a tool, dashboard, widget, script that I am demonstrating.

Ultimately, when I demonstrate a new dashboard to stakeholders, I answer questions that they have the moment of, i.e. when I am demoing dashboard 1, and a person has a question, I answer it right away or if I had thought of the problem, I've created slides/sections later to address it.

If the question was something I did not think of, I write it down for further investigation and get back to the question asker at a later time.

At the end of the demonstration, I always ask "ok, that about wraps it up, are there are questions or comments?" The responses I receive are generally along the lines of praise, i.e. "good work, I love !" instead of further feedback and features that I need to implement or problems to be addressed.

My question is how can I frame the conclusion of a presentation to solicit further issues with the product/deliverable/dashboard I am presenting instead of praise?

(Note, I am not admonishing praise, but rather I want to focus the Q&A on things I need to work on next)

Answer 1

People often infer from your presentations what kind of feedback to give you.

• if you present your plans and priorities for work on a system, they may tell you that they want you to add more things, or change the priorities.
• if you present completed work they will generally tell you they like it, and only tell you "but we want X more than any of this" if the need or urgency of that thing is very large, "but we were promised X, where is it?" if they have had that promise unfulfilled for some time
• if you call a meeting to ask "what would you like us to add next, we have no plans" they may give you answers (but you will get better ones by proposing something they can tweak or add to, as in the first bullet.)

You describe presenting completed work. Very few people will respond to that by telling you what you should have done instead, or what to do next. That's just not part of the script for your demo.

Wait a few weeks and schedule a "what you want to see us do next" meeting, optionally bringing your tentative plan and presenting that. Collect bug reports from the thing you just demo-ed, and a wish list for the next version. Set up your priorities and plans from that feedback, and get to work on doing all that. And when you demo that completed version, however many months later, open with a quick reminder of what they asked for and give status like "I will demo this today" [most should be this status] or "this did not make this release but should be in the next" or "this turned out to be more complicated than we [meaning not just developers but those who asked for the feature] first thought, so as you may know we have a requirements and design process underway for it" and so on. This increases the chances that when you come back a few weeks after that release to ask for what they want, they know you will be closing the loop on that when the next release follows. Building trust like that increases everyone's comfort in asking you for the features they need, release after release.

Answer 2

During a demonstration, many stakeholders are likely just taking notes and checking boxes. They haven't used the tool yet, so they won't have any major points of feedback.

I would suggest scheduling user testing for the sole purpose of a hands-on user operating the tool for its intended purpose and giving you feedback on its performance.

Another way of soliciting feedback is to place an obvious pain-point in the tool or software. Seeing one thing wrong with a tool will usually elicit other responses. This also helps gauge your audience's passivity.

Answer 3

Just like in SE, rather than leaving your question completely open ended, go into these presentations with specific questions you have or specific areas you want feedback on.

While I don't agree 100% with @JRodge01 that you should create a pain point to spark conversation, I agree that if you have points already, ask bout them specifically.

For example, if you want to make sure the user's eye tracks along the dashboard in a certain order, try asking people what they see first. If you are unsure if a certain process is confusing for a user, ask them if it makes sense.

The more specific your questions are, the more specific their feedback will be.

Answer 4

From my experience people just don’t have much valuable feedback ready in regards to Q&A after a presentation. Your brain is busy following the information as they are provided, making hard to give the presented concept some deeper thought. It is like back in school when you thought you understood everything after your teacher explained a concept, but then when the information had some time to ease in you thought “wait a second, how is that even working”.

So to improve your feedback-situation, I would give your stakeholders a chance to test your tools “hands on”, probably in a dummy-environment over a fixed period of time (say for a week after your presentation), during which you also invite them to provide feedback. This way they can click around, trying to solve their usual tasks and realise where they get stuck, what works for them and what does not.

Answer 5

I find it useful to begin the meeting by asking each attendee what's important to them (goals / painpoints) and what they're expecting to get out of the demo.

That gives me a sneak peek into their hot buttons and also allows me to reset expectations early if there's a major disconnect.

It's also super handy because when there's a discussion point which relates to an item they've raised, I can try to expand on that a bit and make it more relevant.

Just like any good user story ensure you cover the who (persona), the what (goal/function) and the why (value/benefit).

Lastly I tend to make a point to ask if there are any queries or concerns at the end (especially if they've been a bit quiet during the preso) and recap any key points covered and outline next steps.

Answer 6

If you present (something that looks like) a finished product, people will assume it is finished, and often that will be the only way they can imagine it looking. For many people, their reaction will either be "I like it" or "I don't like it, but I'm not sure why".

Instead if you present two or three 'sketches' of alternate options, they can compare alternatives that they probably wouldn't have imagined for themselves, and a range of options may even suggest things you hadn't considered.

The other advantage of presenting a sketch is that you don't get distracted by minor details. No one will complain about your text boxes not lining up or a spelling mistake if you're drawing on a white board, so you can concentrate on the important things.

A hidden advantage of providing options is that requests for changes don't feel like personal criticism and you don't feel any need to defend your decisions. You can lay out the advantages and disadvantages of all your ideas and let them choose.