How to Build Product Teams That Actually Care (And Keep Them That Way)
What 12 years of building teams at Zalando, On, and GS taught Vivek Juneja about creating outcome-driven organizations [Slides Included]
When Vivek Juneja walked into On—the Swiss sportswear brand backed by Roger Federer—as one of their first engineering managers, he faced a problem most product leaders know too well. The company was scaling fast, but they needed to build a product and engineering organization from the ground up. Not just any organization—one that could move at startup speed while competing with retail giants like Zalando, where Vivek had spent years leading teams.
At ProductLab Conference 2025 in Berlin, Vivek shared 12 years of hard-won lessons from building outcome-driven teams at three major retailers. This wasn’t theory from a consultant. This was tactical gold from someone who’s been in the trenches, building teams that ship.
“Building these teams is hard,” Vivek told the 250+ product managers in the room. “But keeping them? That’s harder.”
Here’s what actually works.
The Three Pillars: Why Your Teams Need to Care About More Than Just Shipping Features
Most product leaders say they want empowered teams. They want people who care about customers and outcomes, not just shipping features.
But here’s the reality: saying you want it and actually building it are completely different things.
Vivek distilled 12 years of experience into one framework that cuts through all the noise. He calls it the three pillars of care:
→ Care for your customers — not just features, but the people using them
→ Care for the problem space — not the fancy new tool or API, but the actual problem you’re solving
→ Care for product economics — how your work affects revenue, retention, and costs
“If you don’t get anything from today,” Vivek said, “this slide is enough.”
The framework is simple. The execution? That’s where most teams fail.
Here’s how to actually build teams that demonstrate this level of care.
Everyone Should Be Selling (Yes, Even Your Engineers)
Here’s a story that Vivek keeps going back to, even years later.
During his first month at On, an engineer did something remarkable. Without anyone asking, this engineer set up a lab at home. He bought every On shoe model he could get his hands on using company vouchers. Then he started measuring them—literally taking measurements and creating spreadsheets comparing products.
Why? The engineer noticed something. On was labeling certain shoes as “wide fit,” but when he measured them, the data didn’t match up. So he posted his findings in Slack with detailed analysis and datasets.
“Who is this person?” Vivek wondered. “Is he part of the physical product development team?”
No. He was a web infrastructure engineer. Someone who could have easily said, “Not my job.”
But here’s what made it powerful: this engineer cared enough about what customers were buying to flag a problem that the physical product team had missed. When the company was small enough to move fast, they took his feedback, went back to the factory, and fixed the wide-fit issue.
Vivek has used this screenshot (with the engineer’s face hidden) in every talk he’s given since. It’s the perfect example of someone who gives a damn.
Action item: Rotate your team members through sales for a day. Not to make them better at selling—but to see the customer’s eyes light up when they actually get value from your product. It changes everything.
The Radical Ownership Toolkit: How to Build DRIs That Actually Own Outcomes
Everyone talks about ownership. CEOs say, “I want my teams to own everything.”
But what does that actually mean? And more importantly, how do you build it?
Vivek introduced a concept from Apple’s playbook: the DRI (Directly Responsible Individual). Ken Kocienda, the designer who built the Apple keyboard, embodied this perfectly. He was the IC (individual contributor) who scheduled meetings with the VP of legal to go over details himself. No middleman. Just pure ownership.
But here’s where most companies fail: they talk about ownership while operating in one of three modes:
Consensus-driven: Everyone needs to say yes before anything moves
Confrontational: Lock people in a room, let them argue, hope they come out aligned
Hierarchical: Can’t decide? Push it to the boss
“None of these is better than the other,” Vivek clarified. “Just know where you are. Know your operating environment.”
Once you know where you are, you can build real ownership using guardrails instead of rules.
The Guardrail Framework:
→ Constraints of time: Give people a deadline. Theory of constraints always works.
→ Constraints of budget: Here’s your budget. Play within it.
→ Constraints of scope: Here’s your playground. Build whatever you want within these boundaries.
→ Philosophy and principles: Document your design principles so teams aren’t fighting about whether a button should be red or blue.
→ Sacrificial vs. non-sacrificial beliefs: What can teams sacrifice? What’s sacred?
“We care about customers—that’s a sacrificial belief,” Vivek explained. “You can negotiate on execution, but the core principle is non-negotiable.”
Action item: Write down your team’s 3 non-sacrificial beliefs this week. What’s sacred? What absolutely cannot be compromised? Share it with your entire organization.
What Doesn’t Work: The Firefighting Trap That Kills Ownership
Here’s where Vivek got brutally honest about what keeps teams from staying outcome-driven.
Years ago, a manager told him: “Vivek, you’re too quick at firefighting. Let the spark and the fire be there for some time. Let it burn. We’re all adults. You don’t have to just jump in and throw water at it.”
Vivek’s instinct was to fix every problem immediately. No fires on his watch.
But his manager was right. By solving every conflict, every decision, every debate, he was preventing his team from developing the muscles they needed to own outcomes.
“Avoid the tendency as leaders to resolve conflicts—even decision conflicts about your product,” Vivek advised. “Let it not be resolved quite quickly, especially not through you. Just let it simmer. Let people debate, fight a bit, demonstrate the care, prove you wrong or right.”
One team Vivek worked with created a rotating “conflict resolver” role. It was like a hat that moved around the team. If you weren’t the conflict resolver that week, you could fight as hard as you wanted in discussions without worrying about facilitating.
The result? People actually started caring about decisions because they had to own them.
Action item: For the next 2 weeks, resist the urge to step in and resolve team debates. Let your teams argue (productively) and come to their own conclusions. Watch what happens.
The Question That Reveals Everything About Your Organization
Near the end of the talk, someone asked Vivek the question every product leader struggles with: How do you create an appetite for ownership in a team that’s gotten comfortable?
“It’s a good question,” Vivek said. “And I want to approach the answer by saying how I operate—and you would operate completely different, and that’s okay.”
Then he broke down two approaches:
Approach 1: The Incremental Shift
If a team has been comfortable for years, any idea about radical ownership is like a virus to that system. They’ll fight it.
So you find a medium-to-low-risk feature or capability—not a quick win, but something that gives people feedback on what ownership actually looks like. You celebrate it. You talk about it. You show people, “This is what ownership looks like.”
Approach 2: The Band-Aid Rip
Some leaders just say: “From tomorrow, you’re all going to be owning certain things. It’s absolutely okay if you don’t know that yet, but this is how we operate. We’re giving ourselves 4 months to settle in. From now on, everything we build has a single owner. No decisions by committee. If you want advisory, get advisors and move.”
“Both work,” Vivek concluded. “It depends on where you are and how much influence power you have within the organization.”
Keeping Teams: Why Sales Rotations Matter More Than You Think
Building outcome-driven teams is one thing. Keeping them as you scale? That’s where most companies fail.
Vivek’s advice: Sell, sell, sell.
Have periodic rotations where your teams spend time in sales. Let them experience what it’s like to convince a hard customer. Let them see the customer’s jaw drop when they realize your product solves their problem.
“One of my managers told me to just spend a day with sales,” Vivek recalled. “The excitement when you’re meeting a customer, when you convince them—it’s a whole different game when they actually get onboarded and start using your product.”
And here’s the controversial part: don’t fix all problems. Let some fires burn. Let adults figure it out.
Final action item: This quarter, have every product manager, designer, and engineer on your team spend 1 day shadowing sales or customer success. Not observing—actively participating. Watch how it transforms their perspective on what you’re building.
The Bottom Line
Building outcome-driven teams isn’t about copying Google’s playbook or reading another framework doc. It’s about building teams that demonstrate care—for customers, for the problem space, and for product economics.
It’s about giving people guardrails, not rules. It’s about letting fires burn so people learn to own their decisions. It’s about rotating engineers through sales so they understand what they’re actually building for.
As Vivek put it in his closing: “In the world of agentic systems and AI products, what will not change is building teams that can move fast and build towards outcomes.”
The tools change. The fundamentals don’t.
Connect with Vivek
Vivek Juneja has led product and engineering teams at Zalando, On, and GS, building outcome-driven organizations from the ground up. He’s also passionate about education and teaching, creating content to help product leaders build better teams.
→ LinkedIn: Vivek Juneja
→ Substack: Vivek Juneja
 | A guest post by
|
@vivek enjoy the post 🧡