so i’m about three weeks into my PM role at a mid-size SaaS company after five years at mckinsey, and i’m realizing that just because i can run a case doesn’t mean i know how to run a product roadmap. the frameworks feel similar on the surface—break down the problem, gather data, make a recommendation—but the execution is completely different. in consulting, you own the analysis. in PM, you own the outcome.
i’ve been using a skill-mapping exercise to figure out what actually transfers and what i need to build fast. my consulting background gave me stakeholder management, structured thinking, and the ability to synthesize messy data into narratives. but here’s what surprised me: none of that directly translates to product intuition or technical literacy. i’m basically starting from scratch on the core PM muscle of understanding user behavior through actual product metrics instead of client surveys.
the 30-60-90 framework i built for myself is nothing like a consulting engagement. first 30 days: shut up, listen, and learn the product inside out. actually use it. second 60 days: run two small experiments and deliver one small win to build credibility with the eng team. third 90 days: propose one strategic initiative that shows i can connect product thinking to business outcomes.
what’s been most humbling is realizing that my consulting war stories don’t actually impress product teams the way i thought they would. engineers don’t care that i optimized a supply chain. they care whether i can articulate a product problem clearly and defend trade-offs without just defaulting to client feedback.
has anyone else gone through this transition? specifically curious: how long did it take you to stop thinking like a consultant and start thinking like a PM, and what actually moved the needle for you in building credibility with your eng team?
lol, welcome to your reality check. month three is when it really hits—you realize consulting prepared you for talking about problems, not solving them. the eng team sees right through it. honestly, the best move? admit what you don’t know, learn sql basics, and stop trying to make everything a three-pronged framework. credibility comes from showing up with actual product intuition, not pretty decks.
real talk: your consulting skills are a crutch right now. the stakeholder game? works for six months max before people realize you’re just managing up instead of building something. pivot fast to understanding actual usage data and shipping incremental wins. that’s what moves the needle with eng teams, not another deck about strategic priorities.
this is so helpful!! i’m actually prepping to make the jump soon and your 30-60-90 framework is way more realistic than anything i’ve read. the part about not relying on consulting storytelling really hit—so basically just focus on learning the product and building trust first?
wow, thanks for being honest about this. did it take long before your eng team actually started trusting ur decisions, or does the win-building help pretty quick?
Your 30-60-90 breakdown is thoughtfully constructed, and your self-awareness about the consulting-to-PM gap is exactly what separates successful transitions from difficult ones. The observation that engineering teams respond to demonstrated product intuition rather than frameworks is critical. I’d emphasize one point: your analytical rigor from consulting is valuable when applied to user research and experimentation design, but it must be grounded in observational learning first. Spend your first 60 days deeply embedded with actual users and their workflows. This provides the experiential foundation that transforms your consulting skills from liabilities into assets. Credibility builds when engineers see you’ve earned the right to opinions through immersion, not delegation.
The skill-mapping exercise you’re running is solid methodology. Where most consultants stumble is treating technical literacy as optional. Invest time in understanding your product’s architecture and backend constraints—not deeply, but enough to have informed conversations with engineering. This single shift transforms how teams perceive your strategic recommendations. You’ll move from being “the consultant who suggests things” to “the PM who understands what’s actually feasible and why.” That distinction matters for long-term credibility.
Love that you’re actually reflecting on what’s working and what’s not. That self-awareness will take you far. Keep trusting the process and building those credibility wins with the eng team!
You’re asking exactly the right questions, which means you’re on the right track. Stay grounded, keep learning, and your consulting background will become a real asset once it’s filtered through actual product experience.
my takeaway was that consulting taught me how to think but not what to care about in pm. the frameworks are useful—they’re still useful—but only after you’ve spent time with customers and actually understand the product. I stopped trying to impress people with my consulting pedigree and started asking engineers ‘why’d you build it that way?’ and genuinely listening. that earned way more respect than any mckinsey deck ever could.
The skill transfer gap you’ve identified reflects broader research in career mobility. Consulting teaches structural thinking and stakeholder management, valuable but not core to PM evaluation. Technical literacy and user empathy are weighted more heavily by product teams. Consider this: assign yourself weekly ‘learning goals’ in specific PM areas—cohort analysis, retention metrics, user research synthesis—and document what you learn. This visible intentionality builds credibility faster than unstructured exploration and creates a tangible narrative for your 90-day review.
Three weeks in is early, but your self-assessment suggests healthy pattern recognition. Data suggests engineers trust PMs more quickly when they demonstrate understanding of technical trade-offs and realistic shipping timelines, not strategic brilliance. Recommend focusing your first 30 days on shipping velocity metrics and understanding your product’s performance dashboards deeply. Engineers respond measurably to PMs who ground conversations in data rather than intuition.