In a forward-thinking organisation, ideas come from all levels and departments. That’s a wonderful thing. Some of these ideas solve a known problem, some ideas need some work, and some ideas should never see the light of day. Instinctively, you may know which ideas you want to carry forward.

But when you see a terrible idea, how do you explain that to a colleague while keeping your relationship intact? And how can you stop yourself from forever saying “no” when projects don’t quite fit? 

Try asking questions that enable the person to answer for themselves. Ultimately a project shouldn’t be decided by a single person (not even the CEO). They should be judged on merit against company goals. 

I often find myself referencing this slide from Lucy Butler, director of analytics at the Financial Times. All decisions need to roll up to their North Star engagement metric using one of the levers indicated. She included some specific product questions underneath each column.   

For non-product people — which is where most ideas come from — questions can still be more generalised. Not only does it help colleagues get to a yes/no on their idea, it also helps people understand the framework for product decision-making as a whole. 

If you ask one question it should be this: How does this idea help us meet our company objective? (Or, if you have multiple objectives: Which company objective does this help us meet? How?)

Below are a few more questions that help move from an ad hoc idea into a thought out product idea. I’ve heard of companies using online forms to field these ideas, but they work just as well — perhaps even better when beginning the product journey — in a conversation or via e-mail. 

• Which customer segment(s) is this for?  

• What is the expected longevity?

• What is the expected return on investment (ROI)?

• Which departments should be involved in this?

• How much maintenance is this likely to need? 

Invariably, not all answers will be available — a journalist may have no visibility into likely ROI, a marketeer may not have the technical know-how to estimate maintenance — so be sure to ask questions that can be answered by the intended audience or enable resources to help people answer those questions. This shouldn’t be a barrier to surfacing ideas. This should be seen as part of the process to give a go/no go and to prioritise in line with current and future workloads.

By asking these questions, you can reframe the conversation into what will be worked on and when, avoiding a barrage of “no.”

If you’d like to subscribe to my bi-weekly newsletter, INMA members can do so here.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .