In fast-moving product organizations, the skills that got us here won’t carry us through the next wave of change. I’ve learned that future-proofing a team is less about hiring unicorns and more about deliberately growing the skills we already have—and doing it with intention.
Upskilling and reskilling aren’t the same. Knowing the difference can help you build smarter teams and avoid costly missteps in your L&D strategy.
Here’s how I frame it with my leaders: upskilling deepens capability in the role someone already holds—think strengthening discovery, data fluency, or stakeholder management inside an existing lane. Reskilling pivots talent into a new lane—say, a support engineer into data engineering or a product marketer into product operations. Both are essential to building empowered product teams, but they solve different problems.
Deciding which path to take starts with the roadmap and strategy. If your outcomes vs output OKRs signal a need for better execution in current domains, upskilling is the lever. If your strategy introduces new bets—gen AI, privacy-by-design, or a shift to platform architecture—reskilling becomes a strategic investment. I run a simple gap analysis: inventory current skills, map them to near-term outcomes, and identify high-leverage gaps by team.
When I upskill, I prioritize learning in the flow of work. That means structured practice—not just courses—embedded into product discovery, product trios rituals, and code reviews. Shadow sessions, lightweight playbooks, and in-app guides turn new concepts into repeatable muscle memory. For new managers, I add targeted coaching for the IC to manager transition, because role clarity and feedback fundamentals compound quickly.
When I reskill, I treat it like a product launch. There’s a clear charter, staged milestones, a mentor, and onboarding tailored to the new role. I timebox practice projects, use product tours and internal sandboxes, and pair people with forward deployed engineers or senior PMs to accelerate context. The goal is confidence and competence, not just completion.
Measurement keeps the investment honest. I track time-to-productivity during onboarding, deployment frequency and DORA metrics for engineering-heavy paths, and retention analysis for people outcomes. For product and design, I look at decision quality in discovery, reduced cycle time from insight to iteration, and the clarity of written strategy. All of it rolls up into OKRs so learning is tied to business outcomes, not just activity.
The AI wave has made this even more urgent. I’m deliberately upskilling PMs on LLMs for product managers, responsible AI Strategy, and data governance, while reskilling a subset of engineers and analysts into applied gen AI roles. We cover prompt design, evaluation frameworks, and privacy-by-design basics, then ship small internal tools to turn theory into practice.
Culture makes or breaks all of this. I set explicit learning budgets, protect focus time, and model the behavior—publishing my own learning roadmaps and post-mortems. Stakeholder management matters too: I align expectations in QBRs vs OKRs, broadcast progress, and celebrate skill gains the same way we celebrate product wins. When people see that growth is visible and valued, momentum builds.
One example that sticks with me: we reskilled a cross-functional cohort into analytics and experimentation while simultaneously upskilling our existing PMs in discovery synthesis. Within a quarter, decisions got crisper, experiments shipped faster, and collaboration across product trios felt effortless. The compounding effect was unmistakable.
If you’re starting from zero, keep it simple: map the skills you have, the outcomes you need, and choose one upskilling and one reskilling initiative you can deliver in the next 90 days. Make learning visible, measure what matters, and iterate. The teams that master this discipline won’t just keep up—they’ll set the pace.
Inspired by this post on Product School.













