It’s a common practice for art students to critique each other’s work as a means to improve. To conduct a critique, one student shares their creation. Then, the artist’s peers describe, analyze, and interpret what they see and feel. The ensuing discussion covers the holistic impact of the work and the details of how it was constructed through the use of mediums, composition, forms, and colors.
The critique process benefits both the subject and the onlookers. The presenting artist digests the feedback to improve their craft. The critiquers, through articulating their own reactions, become more conscious of how audiences perceive art.
When you’re building products, it’s common to critique an interface design mockup. Designers typically go through many revisions, collecting feedback each time to improve aesthetics, usability, messaging, feasibility, and alignment with brand and product strategy.
It’s also common for engineers to critique each other’s code. For most dev teams, pull requests must be reviewed by peers before code is merged into the main branch. The practice improves code quality, cultivates learning, and distributes knowledge across the team.
But how can we critique the work of product management?
Product management work cannot be reduced to design or code. To help PMs improve, it’s not useful to critique the actual product in its current form. When a PM is hired, they wake up inside a product organism that has been created by many individuals over months or years. Understanding why a product is the way it is today requires a deep historical context. PMs can’t undo previous decisions that limit their options moving forward. They can’t wave a wand to fix the problems that exist today. Every product change takes effort and comes with trade-offs.
Getting product feedback from other PMs can be frustrating. Problems seen by other practitioners are often known issues. For example, it’s easy to critique the function of a grocery delivery app or voice assistant software. But many product problems are hard to fix given technical and business constraints.
Consequently, for product managers to help each other improve, the secret is to critique each other’s iterations, not their products.
In shaping product iterations, PMs navigate questions, like these, that are often invisible to the rest of the organization:
- With this new feature, what is our hypothesis?
- Given two features that I know we need to build, how should we sequence them?
- Should we deploy these changes together or break them up over multiple releases?
- Should we ship a primitive version of this feature or does it need to be polished out the gate?
- Should we launch this feature to all users at once or roll it out gradually?
- Should we user test the design pre-implementation or ship it fast and get feedback post-launch?
- How will we know if this feature was successful or not?
- How should we balance building low-effort front-end improvements with high-effort platform improvements?
- When and how should I analyze the outcome of this change?
To critique how a PM conceptualizes product iterations, you can’t look at each iteration in isolation. The product release cadence and embedded feedback loops tell much of the story.
While it’s tempting to discuss questions like the above in the abstract, I’d like to make it more concrete: at DoubleLoop, we’re organizing guilds of product managers to critique each other’s product iterations.
At each meeting, a product manager will share a series of their previous iterations, including the necessary business context and the results, positive or negative, of those iterations. The group will then discuss those iterations, the underlying decisions, methods, and outcomes. The goal is to help each other improve.
If you are interested in participating in our product iteration critique experiment…
→ SIGNUP HERE.
DoubleLoop is the tool that we’ll use to record and share product iterations, like the PM’s equivalent of a design portfolio or GitHub profile.
Product Logic 