No two products are alike and no two product teams are alike. That's why we here at ProductManagerJobs.net has always advocated that the product manager best practices incorporate the idea that it's both an art and a science. It's mastering the craft of being a product manager that we are all here to write about and explore how to be better in this awesome career path.
We often get asked this question -- what do product managers do and do I have the right skill set today to make a leap into product management?
There's still a lot of misinformation about what product managers do, but if we have to summarize and distill what product managers do and the two key skills to improve on it's the following.
Below is a mental model or mental map of where the Product Owner or Product Manager sits within the larger team organization. It might be different depending the size of the company you work at, but essentially the similar hierarchy is in place.
I'm not entirely sure if stakeholdering is a word; in fact I'm pretty sure it isn't as word, but we are going to use it anyway. Managing a group of people whom you don't have direct hiring or firing control is the core aspect of being a better product manager today.
From the diagram above, you can see that the Product Owner or Product Manager is on the business side but really sits between the Business Sponsors and the Core Team. The product manager needs to liaise with the users, the subject matter experts, the business sponsors and executive owners in order to understand risks, translate requirements into the core team.
Probably the most important aspect of your role is people-oriented: building and maintaining a network of stakeholders and subject matter experts. That network, together with your relationship with the business sponsor and executive owner, is your best means of gaining consensus about business value and the priority of the functionality your team is building.
You are also the person that the development team will turn to when they need to understand the business drivers that form the rationale for the initiative, as well as the specific functionality that end-users of the product expect. Nobody is expected to know everything; your network is where you’ll turn for details and clarity.
When you are developing or refining User Stories for your Product Backlog, there are a few questions to ask that can help clarify and promote the conversations that are needed to ensure shared understanding. Here are a few that can help you effectively manage this key aspect of the Scrum process.
What user group is affected by this?
Typically User Stories are framed from the perspective of a particular user persona. This helps ensure that the delivered functionality solves a problem or adds value from the perspective of those using the product.
Is there development work associated with delivering this function?
If not, it’s likely this item should not be a User Story at all. Consider what coding and testing tasks are required. If this work involves only documentation, design or decision-making, it can either be integrated into one or more other stories, or be handled without the usual estimation process associated with User Stories.
Are there dependencies with other people or teams associated with this Story?
Scrum teams should generally not commit to delivering any work that is dependent on others. Often such items are better handled as “Research Spikes”: time-boxed work effort that can lead to subsequent User Stories.
How do you become better at these? Are there other questions you have about launching a career or taking a leap into product management today? Leave you questions below and we'll add these to the article in the future.