#HowIPM · 2026-06-23 · 2 min
Key moments - from our scoring
Substance score
22 / 100
Five dimensions, 20 points each
Marzia, a senior product manager at Depth Method, demonstrates how small, low-risk experiments can surface and solve team process problems without requiring major organizational overhauls. She shares two concrete examples: instituting engineer-led user story walkthroughs during sprint planning to identify comprehension gaps and prevent over-dictation of requirements, and a two-week trial of Slack-based stand-ups on Fridays that ultimately proved ineffective due to conflicting delivery schedules. The key insight is that experimentation with tight time boundaries - like a single sprint or two-week window - creates psychological safety for change while generating real data about what actually works for your team. This approach is valuable for product managers struggling with team communication breakdowns, engineers who don't fully grasp requirements, or managers considering process changes but uncertain about viability. Rather than rolling out sweeping changes, small, reversible experiments let teams identify friction points and validate improvements before committing.
Have each engineer pick a user story and explain it to the product owner or client during sprint planning. This reveals gaps between your intended requirements and their actual understanding that wouldn't surface otherwise.
Setting a specific duration like two weeks creates a natural decision point to evaluate what worked. It removes friction from trying something new because everyone knows it's temporary and subject to review.
Stop doing it. In Marzia's example, Slack stand-ups on Fridays conflicted with QA and delivery work, so the team discontinued the experiment and returned to synchronous calls.
Our reviewer’s read on each dimension, with quotes from the episode.
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
'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
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
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
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.
Computed from the transcript - who did the talking, and the words that came up most.
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:
Transcribed 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.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.
Why AI and PowerPoints Are Quietly Killing Your Product IntentDefinitely, Maybe Agile · on User stories73 / 100
How to Ensure Collaboration Between Project Managers and Product ManagersProjectified · on Sprint planning72 / 100
Breaking Bad Habits in Product ManagementPractical Product Management · on User stories64 / 100
S12 E10: A Few of My Own First-time F*ckups + Some Jaw-Dropping HR Horror StoriesI Hate It Here · on User stories58 / 100
Kim Scribner - Deep Dive into Agile Marketing Podcast (Episode Thirty-Five)Deep Dive into Agile Marketing · on User stories58 / 100
Get the Most Out of Your Agency Feat. Shero Commerce Co-Founder & CEO, Beth SheroShaping eCommerce with IronPlane · on QA processes57 / 100
Why Your Timelines Sound Like Promises33 / 100Stop Judging Ideas by Job Title31 / 100Stop Putting Features on Your Roadmap43 / 100Tell Your Product Story with a Strategy-Based Roadmap (#HowIPM)31 / 100Tell Your Product Story with a Strategy-Based Roadmap