Every product team runs on processes that somebody chose at some point. Standups happen at a certain time. Requirements travel in a certain direction. Sprint planning follows a rhythm that made sense when it started and has continued on momentum ever since. If you want to improve team processes, the instinct is usually to schedule a retrospective, collect feedback, and redesign the workflow. Merziyah Poonawala, Principal Product Manager at MFP Services, takes a different approach.
Why Team Processes Go Stale
Processes tend to solidify quickly. A team tries something during its first few sprints, it works well enough, and it becomes the default. Over time, the team grows, the product changes, and the original conditions that made the process effective shift underneath it. The process stays because nobody has a strong enough reason to change it, and changing it feels like a bigger commitment than keeping it.
The result is that many teams are running on assumptions about their own workflows. Requirements might flow in one direction because that is how it was set up, not because the team tested alternatives. Standups might follow a format that made sense for a five-person team but creates friction for a team of twelve. The processes work well enough to avoid a crisis, which means they rarely get examined. Teams that start questioning their defaults, even informally, often find that the process they assumed was working was actually absorbing effort that could go elsewhere.
The Experiment Mindset
Merziyah’s approach reframes process improvement as something that can happen in small, reversible increments. Instead of overhauling a workflow after a retrospective, she identifies one variable, changes it for a fixed period, and lets the team evaluate the result together. The scope stays small enough that nobody is committing to a permanent change. A team that knows it can revert in two weeks will try things it would resist if the change felt permanent.
What makes this effective is the evaluation step. The team does not just try something new and let it drift into a default. There is a defined moment where everyone assesses whether the experiment improved things, made them worse, or produced no change. That structure turns a casual suggestion into a real test with a real conclusion.
What Changes When Teams Adopt This
Teams that experiment with their own processes start surfacing assumptions they carried for months. Communication patterns shift because people articulate things they previously absorbed in silence. The team builds a shared understanding of why their processes work, because they have tested the alternatives and seen the results. Even experiments that fail produce clarity. A team that tries a different approach and returns to the original now understands the original in a way it could not have before.
Merziyah walks through two specific experiments in her How I PM tip, each with a different outcome and a different lesson for the team.
“We were able to identify a lot of the misunderstandings because I was getting their explanation and not just my explanation.”
Merziyah Poonawala, Principal Product Manager, MFP Services
Connect with Merziyah: https://www.linkedin.com/in/merziyahpoonawala/
The Product Guy 