Menu

From product managers to product coaches

I have Thoughts about the term “Product Thinking”. But as a general progression, I think Sebastian Saboune is right that as an organization grows, product management has to evolve from a thing we do, to a thing we help the entire company do:

Our understanding of our craft has come a long way since 2015. I believe that it is now a good time to evolve product management into product thinking. A philosophy, mindset, a common knowledge. But primarily, something that can be acquired by anyone in the organisation.

The people in charge and at the forefront of this change will be product coaches. They will be the custodians of product thinking within an organisation, and tasked with getting people, teams, and organisations to become more product led through product thinking.

In summary; product management will become product thinking, product managers will become product coaches, and this will lead to organisations being more product led.

What it means to “think like a PM”

Marty Cagan’s article on the characteristics of a good One on One meeting is great advice for managers, but it also includes some excellent points about what makes a good product manager in general. Here, for example, is a section on what it means to think like a PM:

What does it mean to think like a PM? It means focusing on outcome. Considering all of the risks – value, usability, feasibility and business viability. Thinking holistically about all dimensions of the business and the product. Anticipating ethical considerations or impacts. Creative problem solving. Persistence in the face of obstacles. Leveraging engineering and the art of the possible. Leveraging design and the power of user experience. Leveraging data to learn and to make a compelling argument.

The problem with Impact/Effort prioritization

Itamar Gilad shares a healthy critique of the Impact/Effort prioritization matrix that is so ingrained in every product manager’s brain:

As straightforward as this all seems, there are major problems with Impact/Effort prioritization that cause us to pick the wrong winners. Most importantly Impact/Effort analysis requires us to make somewhat reliable predictions on future events — the effort we will require to complete a task and the value that will be delivered to users and/or to the company once completed. As it turns out both are jobs we’re exceptionally bad at.

He doesn’t say we need to stop using it though, just that we need to move the borders of the matrix around a little bit. It’s also worth noting that there is no “one size fits all” prioritization method. I’ve written about different prioritization techniques, and am a proponent of choosing and adapting the ones that work best within the culture of an organization.

Questions to answer before adopting a new technology

Kellan Elliott-McCrea has an excellent list of questions a team should answer before they decide to adopt a new technology in their software development process. For example:

If this new tech is a replacement for something we currently do, are we committed to moving everything to this new technology in the future? Or are we proliferating multiple solutions to the same problem? (aka “Will this solution kill and eat the solution that it replaces?”)

As he mentions in the post, these questions are not subtle… but I think they’re absolutely essential. It reminds me a little bit of Marty Cagan’s Product Opportunity Assessment questions.

The human-centered dilemma

Design is only as “human-centered” as the business model allows.

— Erika Hall, Thinking in Triplicate.

Users as friends, and other product principles from WeChat’s creator

In Four Key Product Principles from WeChat’s Creator, Connie Chan outlines how Allen Zhang, the Chinese programmer known for creating WeChat and Foxmail, thinks about Product:

The backbone of Allen’s product philosophy is thinking about users as his friends. This means designing products with sincere best intentions for the users and putting their interests above all others — even company stakeholders. For Zhang, the importance of always putting the user first is very simple: “Only when we treat users with genuine empathy will our products be used for a longer time.” What this means to Zhang is that product design should not be reduced to “processes” that can be continuously optimized by data-driven teams. He believes there is an amount of whimsical inspiration that process optimization cannot solve for.

The whole profile is worth reading. Zhang is inspiring, and we need more product thinking like this.

From output-based to outcome-based product planning

Cause & Effect and Product Risk” is a good good post by
Scott Sehlhorst on the importance of moving to an outcome-based approach when evaluating and planning product features. He also discussed how to use Impact Mapping to do it:

When we collaborate to develop a shared understanding that explicitly connects “building X” with “realizing benefit Y” we address the first problem. Impact maps are great for this, because in the process of creating the connections, we intentionally challenge those connections and explore others; creating a better plan, shifting to a bigger goal. All while providing deep context throughout the teams, increasing likelihood of successful delivery and effective stakeholder management.

Product management doesn’t require in-person collaboration to be effective

Remote product management is something I’ve written about before, so I read Julie Caprio’s Four Keys to Successful Remote Product Management with interest. In general I agree with the advice she gives in the article, but there is one section that I wanted to respond to briefly:

Product management, on the other hand, was more of a struggle. A PM needs to set strategy and come up with a vision for the product. Without the potential for spontaneous in-person conversation and even inspiration, this part of the job gets a bit harder. Creating a vision for a product is a collaborative effort involving several stakeholders; when the team is distributed, it’s more difficult to align on goals, tasks, and project ownership.

It’s a common criticism of remote work that it’s more difficult to collaborate remotely. But I think this is the conventional wisdom only because we try to recreate the office experience for remote work. Since offices rely on synchronous interactions, we use the same lens to try to make remote work effective, and that’s just not going to work.

If we optimize for asynchronous communication instead — which is what remote work is so good at — collaboration can be extremely effective. Perhaps even more effective than office collaboration, because everyone can provide thoughtful responses on whatever topic they are discussing on their own time. As Brian de Haaff points out in Remote Workers Are Outperforming Office Workers — Here’s Why:

Without being able to lean on physical proximity, remote workers must reach out to one another frequently and with purpose. This leads to stronger collaboration and camaraderie.

As counterintuitive as it sounds, this has been my experience as well. As long as we shift the way we think about collaboration away from the office mentality, and use the right tools, I don’t think remote collaboration is less effective than in-person work at all.

More

  1. 1
  2. ...
  3. 48
  4. 49
  5. 50
  6. 51
  7. 52
  8. ...
  9. 202