At Yahoo, It depends a lot on what you're working on and what phase of the product you're in. So I will share my experience here (with removing any proprietary information). Currently I am a product manager on an iOS/Android app. So here's how my days look like:

• Research what's out there in the market. Keep an eye on the competitors; what they are doing and what they are expected to do. I do that through quick competitive analysis studies that I perform on regular basis. I use a simple competitor array to make sure i do that quickly. Check the template on Wikipedia under Competitor analysis.
• Conduct persona creation sessions to forge our target audience and their behaviors  I invite a lot of people from different departments to participate in those sessions. It always helps to get fresh ideas from non-technical people.
• Create user stories based on the persona created.
• Prioritize user stories according to what makes sense for the user.
• Iteration is in the core of what we do. The small agile team is always involved in the very details of the product. Sometimes we iterate on an icon design 10 times or more. This process is very informal and very rapid.
• I work very closely with engineers, designers and testers. We literally sit in the very same area with no borders or walls.
• I do NOT have solid set requirements when development starts.I realized it's a bad idea if you want to go agile. When we start development our requirements is a collection of user stories, story boards, paper prototypes and whiteboards, where the details can change at any moment. This is actually inexpensive and works very well when you have a small team (3-5 people) setting closely together. This doesn't mean changing the overall scope often. Only the details change. Requirements evolve during development.
• Every morning, and during the daily SCRUM (which doesn't take more than 20 minutes), we discuss what we did yesterday, what we'll do today and if there any impediments. My job is to remove those impediments. Then I start drawing user flaws in a huge white board that's physically next to our cube. Anybody in the agile team is encouraged to give their opinion about the user flow and the details of UX. This takes usually 15 to 30 minutes. Then we start implementing. This feedback process doesn't stop, we discuss every single detail as it's being built. This can be distracting, but the benefits over-weighs the drawbacks.
• It's not only the SCRUM team who needs to be involved here. I continuously communicate with other stakeholders like sales, marketing, biz dev, PR, legal and senior management, and make sure I collect their requirements.
• To make sure that all stakeholders are aware of what's going on, I conduct weekly/monthly product demos where i showcase the current progress and what will be accomplished next week. It's extremely important for stakeholders to be aware of what you're doing. This is how you get their buy-in. Which is crucial when you're building a new product.
• During development and on daily-basis, I write requirements for the team, make sure they have all the artifacts they need. Sometimes write pieces of code that will accelerate their work. An example of that will be that a developer needs a list of images IDs that are stored in an excel file. You need to strip those IDs and covert then to CSV file for him. You need to do a lot of house-cleaning so your SCRUM team doesn't stop. Anything that keeps the flow going. And if you find yourself free (which rarely happen), I do some bug fixing.
• Not freaking out: I am adding this as a daily activity simply because it's an essential part of what you do: You'll be bombarded with ideas and suggestions from people in the org and from users, trying to give you 'awesome' ideas on how to make the product better or how to quickly monetize it. Your role is calm down, absorb these suggestions, think them through and filter only the meaningful ones. While keeping everybody happy.
• Make sure that the team is focused on the high-level scope. I do that through stressing that every single day, minimizing the number of meetings as much as possible, and block external noise. This is paramount to be able to deliver on time.
• Check out the code on your machine and test like crazy. Test, test and test.
• Keep a relentless attention to details. The more details you know, and the more technical you're involved in the product, the better. Unfortunately, as a product manager, there's no threshold to how deep you go in the details on all levels: code, UX, SEO, QE ...etc. Developers will always welcome you being involved in what they do, but by doing that, make sure you know your technical limits too and respect their aptitude.
• Live and breath the product. Use the product all the time. Always keep a note next to you when you discover bugs or an idea for a feature pops. I use Evernote wherever i go.
• Motivating the team: keep your team motivated through explaining to them why we're doing what we're doing. Get them excited for the product. This is how you get the best out of them.
• Do users interviews on monthly basis. You will be surprised how users will use your product.
• After proving that the product you created is being used, establish a growth trajectory for the product. This involves many activities: working with marketing, business development and PR. Define what type of growth activity is will get you the maximum ROI: sticky, viral or paid.
• Focusing on metrics that really matter. For a mobile app for example, this can be active users/day, minutes spent/active users and weekly retention rate. Everything else does not really matter.
• Continuously learning stuff: I went to electrical engineering school, so you guessed it right: I have a lot of catch up to do. I use: http://www.udacity.com/ and https://www.coursera.org/.
• Do your team's laundry if necessary :)

The variance (even within a company) is really high based on the product you work on, so this is a hard question to answer well.

But I'm assuming some common themes across products and most Internet companies, involves activities including
- working with engineers on product design and requirements
- talking to users/customers.
- thinking through product roadmaps
- cheerleading, championing your project, and pushing it forward
- working through everything else that needs to get done including Sales, Customer Support, Marketing Communication and Collateral.

- and meetings; lots of meetings. :)