In partnership with
👋 Hey friends,
I used to think good product managers were the ones who asked the best questions.
That's still true. But I've been sitting with something lately that feels more urgent.
The PMs who are going to matter in the next two years aren't just the ones asking the right questions. They're the ones who can also show something before anyone else has thought to build it.
Stop babysitting your coding agents
Agents can generate code. Getting it right for your system, team conventions, and past decisions is the hard part – you end up wasting time and tokens in correction loops.
MCPs give agents access to information but not understanding. The teams pulling ahead use a context engine to give agents exactly what they need.
Join us April 23 (FREE) to see:
Where teams get stuck on the AI maturity curve
How a context engine solves for quality, efficiency, and cost
Live demo: the same coding task with and without a context engine
The shift I'm making
Earlier this year I started making a rule for myself: before I write a spec for something new, I try to build a version of it first.
However rough. However broken.
Not because it's faster. It's actually slower at first. There's definitely a learning curve.
But the feedback I get back is completely different.
Concrete instead of abstract. Specific instead of directional. "This is missing X" instead of "I'm not sure this is the right approach."
The deck tells people what you think. The prototype shows them what you mean.
Those are different conversations.
I opened a terminal for the first time a few months ago. Started learning how to use AI tools to move from idea to artifact faster.
I'm still not fast. But I'm faster than I was.
💡 Insight: The gap between "here's my thinking" and "here's what I mean" is the difference between abstract debate and specific feedback. A working prototype—even a rough one—changes the conversation entirely.
Leadership lessons from a record year of purpose-led growth
37 years in business. 2025 was Intrepid's biggest yet, with revenue up nearly 30%. The Integrated Annual Report gets into what drove that growth, what the leadership team got wrong, and how they reset their climate strategy along the way.
How to move from deck to prototype
You don't need to learn to code. You just need to spend 20 minutes making the idea visible.
1. Before you write the spec, open a prototyping tool
Spend 20 minutes in something like Lovable, Stitch, or Claude Artifacts. Not to build the thing. Just to see what it looks like.
If you can visualize it in 20 minutes, you know the idea is real. If you can't, you just saved yourself a week.
2. Lead with the prototype, not the explanation
When you show up with a working prototype, you skip the abstract debate.
The conversation becomes "This is missing X" instead of "I'm not sure this is the right approach."
Deck = directional feedback. Artifact = specific feedback.
3. Use the prototype to learn what you don't know
The goal isn't to have all the answers. It's to have something real enough to react to.
If the prototype makes you look stupid, that's the point. You learn it now, not in the roadmap review.
🎯 Try this: Pick one thing on your roadmap you're not sure about. Open a tool and spend 30 minutes building a rough version of it. You don't need to show anyone. You just need to see it exist. Not next sprint. This week.
Bottom line
The best PMs I know don't just ask better questions. They show up with something to react to.
A deck says "here's my thinking."
A prototype says "here's what I mean."
Those are different conversations. And the second one moves faster.
See you next week,
Stef
P.S. If you're an early-career PM and you want help figuring out how to build your first prototypes before your next review, that's exactly what we work on in my free 30-minute sessions on ADPList. Book here
Every Friday, I do the job hunting work for you.
5 fresh PM roles every Friday. Remote-friendly flagged. Direct apply links. No searching required. $7/month, cancel anytime.
I'm in, unlock full access