Qualifying your ideas
Inexperienced product managers, especially stakeholders who find themselves in this role for various reasons find it extremely difficult to tell different types of ideas apart, so every idea they have for the product become a feature request and finds its way into the backlog.
Individual contributors — the ones responsible for the implementation of these requests — are able to tell that they are being asked to work on a half-baked idea because it will more often than not come through a channel which encourages instant communication, like Slack, or from a situation where things are being theorized like, a meeting.
If you feel guilty of this, it's important to know how this behavior makes your team perceive you as their manager or a stakeholder. When you develop a habit of making requests and decisions on a whim and without "sleeping on them", it makes you seem like you are not capable of doing the work you are ultimately responsible for, which is delivering the best possible product to the users. Also, people may think you are all over the place because you can't seem to afford time to think about things, and this might lead to some of your ICs look for other opportunities.
Truth bomb: your idea most likely sucks
Products in their early stage of design and development may benefit from these wildcard ideas, especially when the people proposing them are domain experts and know a lot about the industry and the users. But as the product matures it's the designers and developers who will come to know both the product and the users far better than you, and they will get tired of disproving, or working on them because they will know they are a waste of time.
Few people are willing to put in work for a dead-end idea. Ever fewer will want to do it over and over again.
So, why is it so tempting to throw ideas around recklessly?
Because it's cheap. High-level perspectives leave all the details and intricacies of implementation hidden from view, so a lot more things seem realistic. And guess what: this is the most common perspective founders, and stakeholders have.
The truth is, ideas really are a dime a dozen. The implementation is where the real effort lies.
An excellent exercise for qualifying your ideas is to do your due diligence and research. This means doing all or most of the work which your ICs would do when they would need to implement a feature.
A very cheap way to do this without being a designer or a developer, is to rely on writing.
Write out the user documentation for the feature.
This will make you understand how it should work in detail.
Write an email which announces the feature to the users.
This will make you describe it elloquently.
Write social media posts and create visuals — or get someone to create them for you.
This will give you a few more chances to describe it in various levels of fidelity (give you a scale of brevity).
Try to figure out where this feature will be talked about on your marketing website, and write the copy.
This will give you insight into how this feature fits in with your product strategy. Is it a game changer, or filler?
If you manage to do all of this, and it still makes sense to see this feature in the product, than you really might be on to something. And if you can't be bothered to go through this, rest assured it's most likely a flop.
What's this?
You are reading his blog.