How and Why To Write a Rude Q&A
One handy technique I learned years ago at Microsoft was the Rude Q&A (RQA). Whenever we had a major launch, we’d start preparing by writing a document that listed all of the difficult, unfair and perhaps rude, questions we’d rather not be asked, but might come up.
We’d work with PR to draft it and distribute it to anyone who was talking to the public or with journalists. It forced us to think through our message, improve our thinking and at times even realize ways to make the product better.
Why do this?
- Helps you prepare for criticism. If you do hear a tough question you want to be ready. A RQA runs you through the unpleasant things you might hear, and increases the odds you’ll handle that situation well. A good RQA raises confidence in tough meetings or presentations.
- Many people will not give you the benefit of the doubt. When you work on a project your optimism makes it hard to see what you’ve built objectively. A RQA forces you to see your blind spots of how the project will be received.
- Revision. If you have lots of good RQA questions, but don’t have good answers, it’s a red flag that your plan, design, or pitch needs more work.
When to do it
- Before Launch. When I worked on software projects, we’d write RQA for our areas before any major launch. We’d share them and discuss, and then give them to anyone who had to represent the product to the public or the press.
- Early in the project. Provided it’s treated as an exercise, rather than a product planning technique, making an RQA early can help sanity check the assumptions your team is making about the project. Doing it early makes it possible to discover a better plan or approach for the project itself.
How to create a RQA
- Ask friends who excel at giving tough feedback for their opinions. Some people are naturals at this task and enjoy coming up with the rudest, most confrontational questions the world has ever seen. You might be offended or hurt by what they come up with, but that’s okay – better to be offended/surprised now, in an RQA than in a demo, pitch meeting or public setting.
- Make sure to include questions that are unfair or based on erroneous, but popular, assumptions. Reporters, clients, and the public all have their share of unfair questions and erroneous information, and you want to be ready for them.
- Spend more time on the answers than the questions. The answers take more time because the responses need to be more polite and mature than the questions themselves. They also need to carefully refute assumptions in the questions without being dismissive.
- Write polite answers. Only the questions should be rude – your answers should be diplomatic. Technically it’s a Rude Q & Polite A (RQPA).
- Review them with your staff. You want everyone who speaks publicly about the project to have similar answers.
[revised and edited 8-16-16]
I have a similar technique when starting projects – it’s basically the “assume you’re going to fail” technique. What you do is picture yourself 1 year into the future and pretend that the new project you’re about to launch has completely crashed and burned. And then you ask yourself, “Whoa, how did this happen?”
When people are really excited at the beginning of a project, it’s easy to feel like success is inevitable. Assuming you’re going to fail allows you to anticipate what can go wrong, and correct course before there’s a problem.
Hi Terry – good point.
That makes me think – one of the reasons people avoid this stuff is that they fear it will crush morale. But I actually think it works the other way – having honest criticism written down clarifies what the risks are and gives people more confidence to avoid them – a morale boost.
But it depends on the culture and attitude of the team I suppose.
Good technique. I was actually just reading Michael Michalko’s “Thinkertoys” recently and apparently Walt Disney had a similar technique. He’d spend three stages evaluating an idea. In the first he’d approach it as an optimistic dreamer. In the second he’d approach it as a realist. In the third he’d approach it as a cynic. People are definitely better off critically evaluating their own work before handing it to someone else. Not only will it be greatly improved before anyone else sees it, but I think it’s easier to take others’ criticism when you’re already used to looking for the flaws yourself.
Why would anybody write a comment here? Because this is a great post! :))) I love this Idea so much I’m going to write a RQA for every presentation now.