Free AI web copilot to create summaries, insights and extended knowledge, download it at here

Abstract

/p> <figure id="3a3f"> <div> <div> <img class="ratio" src="http://placehold.it/16x9"> <iframe class="" src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Ftenor.com%2Fembed%2F16536353&display_name=Tenor&url=https%3A%2F%2Ftenor.com%2Fview%2Fcompute-the-jetsons-robot-maid-does-not-compute-gif-16536353&image=https%3A%2F%2Fc.tenor.com%2F0RWNo75prkQAAAAC%2Fcompute-the-jetsons.gif&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=tenor" allowfullscreen="" frameborder="0" height="400" width="600"> </div> </div> </figure></iframe></div></div></figure><p id="a4e7">I was once asked to write a JIRA ticket detailing step-by-step how to enable a user to share articles from the website to her social network. Well, the product manager is no more of an expert than anyone participating in a social network (almost everyone) in describing that behavior. So when common knowledge things are asked to be put in computer language level detail in JIRA that means that…Houston, we have a problem.</p><p id="eb7a"><b>Examples: </b>developers complain they cannot implement what is in the JIRA ticket because it is not detailed enough (although it is a common knowledge issue that they could easily inspect for themselves); customer success teams ask product people for product documentation without wanting to be involved in its creation nor updates, which leads to limited understanding of the product and extreme dependence on a product manager every time something needs to be adapted</p><h2 id="4701">Antidote</h2><h2 id="b935">If you are a product manager in this situation:</h2><ul><li><b>remember everyone in the team that all are equally responsible</b> (sounds familiar, see above) for understanding well enough the problem and at a sprint level the stories they are trying to solve</li><li><b>document in JIRA the problem and the acceptance criteria, but NOT the step-by-step details of implementation</b>, so you don’t foster ‘does not compute behavior’ that blindly follows recipes, but rather problem ownership mindset, that after understanding the problem, wants to decide on the best way to solve it</li><li>clarify your role in the team by reading aloud articles by Marty Cagan on every occasion (just kidding, but at some point, it may be useful); <b>remember to your team that the role of a product manager is mainly to ensure value, usability, feasibility, and viability of the product</b>, in short, to pick the right things to work on, not to write implementation-detail JIRA novels</li><li>in the case of product documentation, <b>involve other stakeholders in their production</b>, so that they have a beyond-surface understanding of the product and can make some adjustments depending on the case/customer they are talking to. Note: there will always be product details that only the product team will know, but stakeholders should be able to perform high-level changes to the product documentation to cater to their purpose</li></ul><h1 id="fc35">The small picture aka myopic product manager</h1><p id="099d">This type of product manager just understands a hyperspecific part of the product they are working on and can usually be seen in larger organizations.</p><p id="e965">Once, upon joining a company I wanted to understand how a product worked from beginning to end. I felt the need to start writing a manual as each product manager’s knowledge was mainly limited to the compone

Options

nt they worked on.</p><p id="a08c">I remember while at college and studying the theories of work organization, reading that, to enrich someone’s work, say a line factory worker, you give them an understanding of the whole cycle, beginning-to-end.</p><p id="c976">One of the things that gives me the most satisfaction is to know how a product works completely, but also how it attracts, retains, and engages users. With the growing specialization of product managers in terms of growth vs. core, I am afraid that many product managers will also have a partial picture of the product in this regard.</p><p id="fb5e"><b>Examples: </b>product managers are organized by product components and struggle to answer questions outside the component they are focused on; product managers know all about engaging the users with the product but have no clue how users are attracted to the product</p><h2 id="85fa">Antidote</h2><h2 id="2146">If you are a product manager in this situation:</h2><ul><li><b>try to sketch the beginning-to-end of the product you are going to work on, using one-on-ones with different people to get the full picture.</b> Offer to send the document once you are done with it, most often than not they too are struggling to understand the bigger picture</li><li>similarly, try to <b>understand how the product attracts, engages, and retains users</b>, the picture of a useful persona will become clearer if you are able to accurately depict going through all these stages</li><li><b>be clear on the consequences, for you, the product, and the user, if you only have a microscopic picture of your product and discuss it</b> with the product leadership, your team, and key stakeholders, so that they are aware and can help you in building that bigger picture</li></ul><p id="e1c6">This is not intended to alienate any function that interacts with product managers — they are key to product development — but to identify aspects that can make that dynamic to be more productive and beneficial for all involved. Since the role is still being consolidated, there are many misconceptions that could lead it to be shaped in the wrong direction, not fully exploring all its potential for greatness (Spiderman makes an entrance).</p><p id="9ad1">Very often (hopefully less than a few years ago) it is still part of the product manager's role to educate others in the organization about its purpose. So having a clearer picture of what you would like product management to look like is key in explaining it to others.</p><h1 id="5d4b">The one product manager type you may consider</h1><p id="1356">This is a provocation…each one of us has particular skills we bring to the role and would like to grow throughout our careers. So there can be endless ways to be strong product managers.</p><p id="bb2c">However, looking at the things that definitely don’t make you a strong product manager (at least a happy one), one can derive that a strong product manager:</p><h2 id="6d9b">Understands the bigger picture (market, lifecycle, product) and is expected to mainly ensure value, usability, feasibility, and viability of the product while being accountable for the things she has the power to control.</h2><p id="1fef">Uf!</p><p id="0f71">While it would be good to have all this right from the get-go, I argue that just getting one of these things right could bring a major impact on the product managers' morale in the organization, their teams, the product, and ultimately the users.</p><p id="d963">Sounds worth a shot, no?</p></article></body>

The three types of product manager you don’t want to become

and the one you may want to consider

Product management is still being shaped as a role. That is why it is so important to get it right. So it doesn’t become a “bullshit” job. A job that doesn’t add value and causes distress to those who perform it. There is a lovely book on them that I recommend reading.

In such an infant role there are many ways to get it wrong. And many of us have experienced at least one if not all of them. Here are my top 3 no-goes as a product manager. It is interesting to see how they, unfortunately, link well to and feed each other.

The scapegoat aka the weak version of Spiderman

It has become somewhat a dogma that a product manager has all the responsibility but no power. As someone highlighted to me, this is almost the reverse of Spiderman.

In fact, while Spiderman (after a quote check it seems it is Uncle Ben, but Spiderman fits the picture better) beats his chest saying that “with great power comes great responsibility”, many product managers or product managers to-be beat their chests saying “we have no power, but great responsibility”. That to me sounds like the definition of toxic. Having sole accountability for things beyond our control.

So let’s try to shake this off the narrative about product managers (at the very least not brag bout it). People in all roles deserve to be accountable for the things they directly control.

Examples: someone in sales misses a deal and they blame the product manager; developers are unable to deliver the things they committed to the sprint and blame the product manager; developers expect the product manager to be a ‘sh*t umbrella’, writing that the PM should be the shield of all pressures in the 360 performance evaluation; the weather sucks, and guess what?…it is the product manager’s fault (ok, this one is not an actual example :P)

While the trademark of a product manager is to understand the big picture (more on that later), in many cases the role is used as a dump of responsibility by other teams, that just feel they can get away with little ownership for the product development.

Antidote

If you are a product manager in this situation:

remind your team and other stakeholders that everyone is equally responsible for wanting to solve the problem for the user
involve everyone in understanding the user as much as you do. In my view, there is no reason for the product manager to know more about the user than anyone on the team, in fact, it can lead to imbalances in empathy for the user across team elements that can weaken their desire to solve the problem
define well the scope of the problem and present it back to anyone involved, discussing and highlighting the different responsibilities in addressing it

The scribe aka the developer’s assistant

In my view, a sure sign of an immature product practice is when developers believe that the role of a product manager is to be a sort of scribe, writing JIRA tickets to excruciating detail, because else it “doesn’t compute”, and they are unable to get on with their work.

I was once asked to write a JIRA ticket detailing step-by-step how to enable a user to share articles from the website to her social network. Well, the product manager is no more of an expert than anyone participating in a social network (almost everyone) in describing that behavior. So when common knowledge things are asked to be put in computer language level detail in JIRA that means that…Houston, we have a problem.

Examples: developers complain they cannot implement what is in the JIRA ticket because it is not detailed enough (although it is a common knowledge issue that they could easily inspect for themselves); customer success teams ask product people for product documentation without wanting to be involved in its creation nor updates, which leads to limited understanding of the product and extreme dependence on a product manager every time something needs to be adapted

Antidote

If you are a product manager in this situation:

remember everyone in the team that all are equally responsible (sounds familiar, see above) for understanding well enough the problem and at a sprint level the stories they are trying to solve
document in JIRA the problem and the acceptance criteria, but NOT the step-by-step details of implementation, so you don’t foster ‘does not compute behavior’ that blindly follows recipes, but rather problem ownership mindset, that after understanding the problem, wants to decide on the best way to solve it
clarify your role in the team by reading aloud articles by Marty Cagan on every occasion (just kidding, but at some point, it may be useful); remember to your team that the role of a product manager is mainly to ensure value, usability, feasibility, and viability of the product, in short, to pick the right things to work on, not to write implementation-detail JIRA novels
in the case of product documentation, involve other stakeholders in their production, so that they have a beyond-surface understanding of the product and can make some adjustments depending on the case/customer they are talking to. Note: there will always be product details that only the product team will know, but stakeholders should be able to perform high-level changes to the product documentation to cater to their purpose

The small picture aka myopic product manager

This type of product manager just understands a hyperspecific part of the product they are working on and can usually be seen in larger organizations.

Once, upon joining a company I wanted to understand how a product worked from beginning to end. I felt the need to start writing a manual as each product manager’s knowledge was mainly limited to the component they worked on.

I remember while at college and studying the theories of work organization, reading that, to enrich someone’s work, say a line factory worker, you give them an understanding of the whole cycle, beginning-to-end.

One of the things that gives me the most satisfaction is to know how a product works completely, but also how it attracts, retains, and engages users. With the growing specialization of product managers in terms of growth vs. core, I am afraid that many product managers will also have a partial picture of the product in this regard.

Examples: product managers are organized by product components and struggle to answer questions outside the component they are focused on; product managers know all about engaging the users with the product but have no clue how users are attracted to the product

Antidote

If you are a product manager in this situation:

try to sketch the beginning-to-end of the product you are going to work on, using one-on-ones with different people to get the full picture. Offer to send the document once you are done with it, most often than not they too are struggling to understand the bigger picture
similarly, try to understand how the product attracts, engages, and retains users, the picture of a useful persona will become clearer if you are able to accurately depict going through all these stages
be clear on the consequences, for you, the product, and the user, if you only have a microscopic picture of your product and discuss it with the product leadership, your team, and key stakeholders, so that they are aware and can help you in building that bigger picture

This is not intended to alienate any function that interacts with product managers — they are key to product development — but to identify aspects that can make that dynamic to be more productive and beneficial for all involved. Since the role is still being consolidated, there are many misconceptions that could lead it to be shaped in the wrong direction, not fully exploring all its potential for greatness (Spiderman makes an entrance).

Very often (hopefully less than a few years ago) it is still part of the product manager's role to educate others in the organization about its purpose. So having a clearer picture of what you would like product management to look like is key in explaining it to others.

The one product manager type you may consider

This is a provocation…each one of us has particular skills we bring to the role and would like to grow throughout our careers. So there can be endless ways to be strong product managers.

However, looking at the things that definitely don’t make you a strong product manager (at least a happy one), one can derive that a strong product manager:

Understands the bigger picture (market, lifecycle, product) and is expected to mainly ensure value, usability, feasibility, and viability of the product while being accountable for the things she has the power to control.

Uf!

While it would be good to have all this right from the get-go, I argue that just getting one of these things right could bring a major impact on the product managers' morale in the organization, their teams, the product, and ultimately the users.

Sounds worth a shot, no?