Jeff Gothelf addresses a very common problem in his post on the perils of fixed time, fixed scope projects. This point on what it means when you “launch” a product is so important:

Deadlines imply that if we don’t get the product right on the day we launch, we’re doomed. This is an antiquated point of view. Launching publicly simply begins the process of learning how right (or wrong) our assumptions were. It is the start of a continuous conversation with your target audience and the fastest way to learn how to optimise your system. The sooner you can get something to market, the sooner you can make the system better. By the time you get to your deadline, your product should have been in market for multiple cycles.

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.

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.

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.

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.

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.

“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.