In this episode of the Science of Excellence, I sat down with Rashi Kakkar, who's leading a transformation at McKinsey's L&D function by applying product operating principles to learning and development. She's tackling one of the most common frustrations in L&D: how to move from being order takers to strategic advisors.
The conversation revealed a powerful insight: the order taker problem is built into how most L&D teams are structured. By changing the operating model, teams can solve the root cause rather than just the symptoms.
These 5 insights stood out from our conversation:
- Recognize Order Taking as Structural
- Embrace Product Operating Models for Strategic Impact
- Structure Teams Around Learner Journeys
- Decentralize Decision Making Authority
- Start Small, Scale Strategically
1. Recognize Order Taking as Structural
In Rashi's Words: "When you are constantly getting lists of requirements and only looking at a problem when someone tells you, 'this is the problem, this is the scope, go build this,' and then you give it back to someone else, you can never be strategic because by its very nature, you're taking in orders and instructions."
The order-taking dynamic is built into how L&D teams operate. Traditional project-based structures create a cycle where stakeholders define problems and scope, L&D executes, then hands solutions back. This system positions L&D as receivers of requirements rather than owners of solutions.
L&D professionals often feel frustrated because they want to be more strategic, but the operating model prevents it. When you never get full context or ownership of problems, strategic thinking becomes nearly impossible. The structure creates the behavior.
2. Embrace Product Operating Models for Strategic Impact
In Rashi's Words: "A product really is something that adds value to an end user. The big difference between product versus project is a project by its nature is supposed to end. A product really goes on in perpetuity. So what the product operating model really is, is how your team is set up to serve those different products that eventually go to your end user versus being siloed in ways in which traditional organizations operate."
There are a few key differences between the two models.
Project-Based Model: Focuses on completing a defined scope of work within a fixed timeframe and budget. Success is measured by adherence to timelines, budgets, and delivery of specific outputs.
Product-Based Model: Focuses on continuous delivery of value to end users. Success is measured by product performance, user satisfaction, and business impact over time.
In a product model, L&D teams own outcomes. This ownership creates the context and authority needed for strategic thinking. Teams must understand their learners' world, anticipate needs, and make recommendations—positioning them as strategic advisors.
3. Structure Teams Around Learner Journeys
In Rashi's Words: "There's one person who looks at onboarding as a journey. There's someone who looks at the IC journey, someone middle management, and someone executive. These are the people who are continuously talking to their counterparts, continuously learning more about who these people are, how their interventions are doing. They're the ones who are thinking about what are the feature sets, what needs to be built, what needs to be updated."
Journey ownership creates strategic perspective. Instead of organizing around individual programs or functions, product-based L&D teams organize around learner experiences. One person owns the entire onboarding journey, another owns the new manager experience, and so on.
Those who own the journey become the voice of their audience with complete context. When stakeholders make requests, they can explain how those requests fit into the broader experience.
4. Decentralize Decision Making Authority
In Rashi's Words: "It requires a lot of empowerment of teams and those product teams, which are typically a couple of levels removed from maybe the executive. You've got to empower the product teams at that level to do the user research, do the continuous discovery, take out MVP products, test them and actually say, 'this is what we think we should build. This is why we're building it.'"
Product operating models require distributing decision-making power to teams closest to users. Teams need authority to research users, test solutions, and make build decisions without constant approval.
When teams can make decisions based on user research, they develop expertise and confidence in their recommendations. They become strategic advisors with both the authority and knowledge to guide stakeholders.
5. Start Small, Scale Strategically
In Rashi's Words: "Instead of a big bang saying, 'my entire team's operating model will switch,' make sure that it's critical but if it blows up, it doesn't take everything down, but it also should not be something that nobody cares about. Just identify the right cohort or the right level. Just find a couple of people who you can upskill in this way of being."
Operating model changes require careful piloting. Choose a meaningful but contained area—important enough to matter but small enough to manage if adjustments are needed.
Success in the pilot creates momentum for broader adoption. Teams can demonstrate improved outcomes and stakeholder satisfaction, making it easier to expand the model and gain organizational support.
Until next time,
Vince
.png)
.png)