As a learner who is interested in product management, I want a course to teach me the basics of what it means to be a product manager.
That is a user story that (hopefully) represents you. When you are thinking about building products and features, you should start with user stories. I know it seems like a weird process to go through, but trust me that it is worth it. It forces you to enter a user's mindset and think through their problems and how they may wish a service might solve them. This sort of grounding in a user's mindset will serve you very well. It forces you to think, "How can I come to my user?" rather than "How can I make my user come to me."
What constitutes a user story
A user story is almost always the form of "as <a certain type of person>, I want to <do something>." You identify what kind of user they are (a customer, a shopper, an admin, a moderator, an athlete, a chef, etc.) and what they may want to be able to do (purchase something, modify their email, remove a post, see my previous workouts, find new ingredients, etc.)
Be careful these are not just reframings of what you wanted to do. "As a worker with frequent users, I want to be able to use the Metaverse to take meetings." This is just taking what you want the user to do and reframing it as a user study. "As a worker who takes frequent meetings, I want to have a more personal experience with my coworkers despite a remote culture" would be a much better framing of a user story.
"As a worker who takes frequent meetings, I want to have a more personal experience with my coworkers despite a remote culture."
Do you think that's true? I don't, and I certainly don't think the Metaverse solves that. That would be my biggest criticism of the Metaverse thus far: it's a product in search of a problem as opposed to being a product that solves users' problems.
However, we, as product managers, are but mere mortals and don't have all the answers. We frequently make guesses and are wrong. Our "product sense" (as tech companies like to call that) can intuit some of the answers, but we will get some wrong. Therefore, it is useful to keep your thinking grounded in users.
Research
One thing you should do is validate user stories by doing research of some variety. Sometimes, that's as easy as browsing StackOverflow or Reddit to see what your users are saying about your product. Other times, you might call up some of your customers and ask them what problems they are facing. You can also ask them, "If we did X, would it solve your problem for you?" and get some good feedback that way.
A word of caution when speaking with your customers: a lot of the time, your customers don't actually know what they want. They'll say, "Yes, I want feature X," but in reality, if you build it, no one is going to use it. They'll think they want something, but in reality, it is just an indication that there's a problem there that isn't being solved correctly. It can be a symptom of something else.
Another word of caution here is that frequently, you have a loud minority of users who will clamor for something when, in fact, they are a very small minority of the users. Anyone who has worked on a social network will know that only a single-digit percentage of people make any posts that have any traction but will have an outsized voice when it comes to feature requests. It's a biased sample set.
The best kind of feedback comes from UX researchers. They will put your product in front of people and watch them use it. That way, you don't bias your outcomes by leading them; they let them use the product and then pass that feedback on to you on how they used it.
What to do with user stories
Okay, so now you have some user stories. Now what? At this point, you would prioritize them (we will talk about that next section), pick a few, and plan to work on them. You will take some of those user studies and propose solutions that fulfill your user studies. You will take some of those solutions and turn them into product specifications, which then are passed to design and engineering to turn into products and features.
Just always keep your users in mind. That alone will give you a leg up on a lot of product managers.
