Was your idea shot down as soon as you shared it?
You’re not alone. Know that idea shot down happens a lot!
If idea shot down happens often enough it make us want to shut up and stop sharing our ideas. If you only have a hunch as to why your ideas are shot down, give people the benefit of the doubt. Investigate why they are shooting down your ideas.
I recently helped one of my reader’s Thal, go through this investigation. Here’s Thal’s initial email to me:
Hi Poornima,
I read somewhere (maybe on your blog) that people shot your ideas down constantly. How did you get over it?
I’ve tried sharing my ideas for product improvements in meetings, and during one-on-one’s with my manager, but I can’t seem to get through to anyone on my team. They just keep shooting my ideas down.
I don’t know if it’s my ideas or my team. Looking to you for some guidance.
Sincerely,
Thal
Sound familiar?
I started out by asking Thal a few follow up questions.
When you share an idea for the first time, how do you share it?
I needed more context, so I had Thal provide a detailed description. Thal wrote back telling me that usually in meetings, like morning scrums, all hands or sprint planning, Thal would chime in with an idea or two for how the product could be improved based on feedback from customers.
Sometimes teammates would engage with follow up questions, but then move on to other priorities.
I pressed Thal a little more, asking what were the follow-up questions, and how would Thal respond to these questions.
Thal replied that some common questions were:
- Why was this a top priority? How were customers or teammates affected?
- If so, what did next steps look like for implementing it? How much time and how many people would need to work on it?
When put on the spot, Thal found it hard to answer what next steps looked like, and provide an estimate for timing.
These seemed like good follow up questions, but it was still unclear to me why they were asking them. (I’d later walk Thal through the process for handling these “put on the spot” moments — I’ll walk you through them as well below.)
So I asked Thal what were the last twos ideas that were adopted and why? Regardless of whether it was Thal’s or someone else’s.
Nice-to-Have Idea vs Must-Have Idea
Thal came back and reported that the last two ideas were things that were broken and impacting thousands of users:
- There had been an issue in the product’s checkout flow where expired credit cards weren’t being flagged early on, costing the company thousands of dollars in lost monthly revenue over the span of three months.
- There had been an issue with the sign-up process where new users didn’t want notifications automatically turned on in the mobile app and they didn’t understand why notifications had to be on by default. As a result, they’d drop off, and this occurred for several weeks.
These were great examples of things that were broken that needed to be fixed ASAP.
I asked Thal if there were any examples of ideas that weren’t trying to resolve broken issues?
Thal investigated the team’s releases, and discovered that the last new feature the team had implemented had been over 18 months ago!
Firefighting vs New Features
It’s common practice for teams to go into maintenance or fire fighting mode for long stretches, so I asked Thal what the team’s priorities were.
Thal said that in general, they had been fighting a lot of fires. The product’s user base had grown very quickly, and the company wanted to keep as many users as it could, instead of building new features to attract new users. Hence, the team shifted its focus to retaining users by resolving as many issues as they could.
Then I asked Thal if the team was planning shift gears any time soon to entertain ideas for new features?
Thal reported back that the team didn’t have the bandwidth at the moment. They were crunched for time and resources, and the company was waiting for revenue to go up by converting existing users into paying customer before building new features.
Thal learned through investigating that his teammates weren’t interested in ideas for new features.
Switching to solutions.
Thal followed up by asking me if maybe it was best to just suggest ideas that would fix things instead? Given the team’s focus that would be prudent. Additionally, Thal needed to work on feeling “put on the spot”, and be able to have answers to questions that came. Thal’s responses would influence idea adoption and implementation. I recommended doing the following to prepare:
Show your idea’s impact.
It’s not enough to say something is broken, needs to be fixed, and propose the fix. Show the impact of what is broken. Data drives decision making. However, it’s hard to glean a clear picture from data alone. I recommended Thal frame the data in a story format for teammates to digest it better. One way to do that is to tell the story of a single customer: share who they are, and what problem they are experiencing. Then refer back to the data to show how that customer isn’t alone, there are X customers like them.
Show the cost of inaction (AKA risk assessment).
If the team is already in fire fighting mode adding one more idea that is a solution to the mix can make the fire fighting seem endless and insurmountable. The last thing you want to do is demoralize a team.
So it’s important to assess if the idea is one that really needs attention and resources. If its impact is higher than another one people are working on, then it’s worth considering it. But you don’t want to end up with a lot of half-baked ideas — that will only intensify the fire fighting.
Have your team answer the following questions: Is switching worth it? Would the team be able to implement the solution quickly i.e. without facing scope creep in the form of tech debt, product debt, or knowledge gaps? Often it’s these risks that cause people to shoot down ideas. They instinctively know how burdensome it will be to take them on, and may not voice those instincts aloud.
Gain support for your idea.
An idea needs more than one champion. Who else on your team thinks it’s good and why? Would they be willing to vouch for it? A good way to approach your teammates is by hosting a pre-meeting. A pre-meeting is meeting ahead of time to talk through ideas, uncover objections or blind spots, and gain committed supporters. Check out Karen Catlin’s talk here for how to host a pre-meeting.
Think about the timing for your idea.
Sometimes the time isn’t right for an idea. For example, if your team is in fire fighting mode, there is a re-org or limited resources. It’s easy to take it to heart, but it’s important to stay a bit detached. And revisit ideas often. I recommend having a brainstorming session quarterly or looking through the backlog. Sometimes teams find that it’s easier to implement one of those because they have more time, resources, or it becomes a priority.
A Culture of Constraints vs Experimentation
The team’s focus was on firefighting. They were shooting down ideas that didn’t fit that focus. Thal admitted to being eager and looking ahead to implement something new, partly because fire fighting was getting tiresome.
Thal also realized that it wasn’t enough to just shoot a hand up and voice an idea. An idea needed to be fully formed, otherwise it would be shot down quickly.
While firefighting isn’t fun, it can often be necessary so long as it’s finite and fits into a company’s goals and a team’s priorities.
As Thal was going through this investigation, it became clear that the company had a clear culture of accountability. Thal’s investigation made the company realize that in some ways they had become a little too constrained.
To balance things out and make sure that people didn’t get burnt out or demoralized by all the fire fighting, they encouraged teams to take 1–2 days a month where people could do things that would re-energize them such as attend a conference, bring in a speaker, or host lunch and learns to share expertise. This helped people learn new skills and engage with their teammates. And given they were still operating in a culture of constraints, they marked these days off on the calendar and had everyone participate.
Initially, there people grumbled about these mandatory days, but over time, people looked forward them as a nice mental break.
Thal received recognition for championing them.
Enjoyed this post and want more resources?
Check out the following posts: