How Small Experiments Improve Team Processes
#HowIPM - Bi-Weekly Product Management Tips and Tricks · 2026-06-23 · 2 min
Substance score
22 / 100
Five dimensions, 20 points each
What our scoring noted
Our reviewer’s read on each dimension, with quotes from the episode.
Insight Density
The episode is roughly two minutes of a single practitioner tip, and both examples—having engineers narrate user stories and trialling async standups—are textbook agile hygiene with no non-obvious claims. The density of novel ideas per minute is extremely low, and the conclusion is purely generic.
using small, little, small tweaks to your processes, you can really kind of pull out some of the trouble spots that you have
we experimented for two weeks where we said we will do slack stand ups on Friday and we'll decide if that works or not
Originality
'Run small experiments to improve processes' is foundational lean/agile doctrine recycled without any contrarian angle, first-principles reasoning, or new framing. Nothing here would surprise a PM who has read a single book on agile.
My product management trick is using small experiments to improve your team processes
using small, little, small tweaks to your processes, you can really kind of pull out some of the trouble spots
Guest Caliber
Marzia is a self-identified senior PM at an unknown company called Depth Method; she is a practitioner rather than a thought-leader, which counts for something, but there is no evidence of scale, notable outcomes, or domain depth beyond a two-minute anecdote.
I'm a senior product manager at Depth Method
I had a project where my engineers, I wasn't sure how fully they were grasping the user stories
Specificity & Evidence
There are a handful of concrete details (two-week experiment window, Fridays as delivery/QA days) but zero metrics, no named clients or products, no measurable outcomes—just thin anecdotes that stop well short of evidence.
we experimented for two weeks where we said we will do slack stand ups on Friday
because Fridays were delivery days, a lot of QA going on, it was actually better to get everyone on the call
Conversational Craft
This is a solo monologue tip segment with no host, no interviewer, no questions, no pushback, and no follow-ups whatsoever; the format makes any evaluation of conversational craft essentially inapplicable, and what structure exists is loose and repetitive.
And so using small, little, small tweaks to your processes, you can really kind of pull out some of the trouble spots that you have and improve your improved team processes in general. Sa.
Conversation analysis
Computed from the transcript - who did the talking, and the verbal tics along the way.
Filler words
Episode notes
Every team runs on processes that started as someone's best guess and hardened into routine. The defaults rarely get tested because changing them feels like a bigger commitment than keeping them. What if the commitment were two weeks instead of permanent? Merziyah Poonawala, Principal Product Manager at MFP Services, shares her approach to running small, reversible experiments on team processes. She walks through two real examples with different outcomes, one that stuck and one that sent the team back to the original with a clearer understanding of why it worked. Merziyah previously served as Senior Product Manager at Def Method, building and refining product team operations across client engagements. The How I PM collection includes 50 strategies from practicing product leaders. Most are available exclusively to Product Way members. Join The Product Way for the full collection, plus PM Select, exclusive introductions between PMs and hiring managers:
Full transcript
2 minTranscribed and scored by The B2B Podcast Index.
I'm Marzia, I'm a senior product manager at Depth Method. I'm also working through the Wheel of Time series and this is how I pm. My product management trick is using small experiments to improve your team processes. So as an example, I had a project where my engineers, I wasn't sure how fully they were grasping the user stories and I was dictating a lot of the user stories, the requirements. And so what I did was I said, starting next our Sprint planning meeting, each engineer will pick a user story to describe to the client, to the product owner, and if there are any obviously discrepancies, we can solve it. What that did was get the engineers speaking. We were able to identify a lot of the misunderstandings because I was getting their explanation and not just my. Another example of this was something really simple. We had someone on our team say, hey, it's kind of nice not to have to dial into stand up once a week. If you can avoid it, why don't we do slack stand ups? Fair enough. So we experimented for two weeks where we said we will do slack stand ups on Friday and we'll decide if that works or not. At the end of the two weeks we concluded it didn't really work. We because Fridays were delivery days, a lot of QA going on, it was actually better to get everyone on the call. And so we decided not to do it. And so using small, little, small tweaks to your processes, you can really kind of pull out some of the trouble spots that you have and improve your improved team processes in general. Sa.