Since I brought this up, I’ll start this thread 
I started hunting for bugs about an year or so ago. Just like how most bug bounty hunters get started, I too mostly reported low hanging fruits and petty issues that companies didn’t really care about in the beginning. Fast forward to 2015, I like to believe that I have improved over the past year or so and I will explain how.
Some things that I have done/observed that has significantly helped me reduce duplicates and get bugs accepted in the first go. I understand this might sound repetitive because it is not rocket science so just bear with me:
- Start early. As soon as a program is launched, start hunting immediately, if you can.
- Once you start hunting, take a particular functionality/workflow in the application and start digging deep into it. I have stopped caring about low hanging fruits or surface bugs. There is no point focussing your efforts on those.
So, let’s say an application has a functionality that allows users to send emails to other users. - Observe this workflow/requests via a proxy tool such as Burp. Burp is pretty much the only tool I use for web app pentesting.
- Create multiple accounts because you would want to test the emails being sent from one user to another. If you haven’t been provided multiple accounts, ask for it. Till date, I have not been refused a second account whenever I have asked for it.
- Now, if you are slightly experienced, after a few minutes of tinkering with this workflow, you will get a feeling whether it might have something interesting going on or not. This point is difficult to explain. It will come with practice.
- If the above is true, start fuzzing, breaking the application workflow, inserting random IDs, values, etc. wherever possible. 80% of the time, you will end up noticing weird behavior.
- The weird behavior doesn’t necessarily mean you have found a bug that is worth reporting. It probably means you have a good chance so you should keep digging into it more.
- There is some research that might be required as well. Let’s say you found that a particular version of an email server is being used that is outdated. Look on the internet for known vulnerabilities against it. You might encounter a known CVE with a known exploit. Try that exploit and see what happens (provided you are operating under the terms and conditions of the bug bounty).
- There might be special tools that are required. Explore into that, if possible. Remember, Burp is a swiss army knife but you might have to use certain specific tools in certain cases. Always, be aware of that.
- After spending a few hours on this, if you think you have exhausted all your options and are not getting anything meaningful out of it, stop and move on. Getting hung up on something is the biggest motivation killer but that doesn’t mean you are giving up. Get back to it later if something else comes up. Make a note of it.
So, that’s it. Above is an example of how I would approach a program. Feel free to ask questions/agree/disagree.
Cheers!