Why I Refuse to Use the Word "Resources"
And Why Your Team is Your Most Important Product
We obsess over our external products in ways that would make a perfectionist blush.
We have roadmaps. We have OKRs. We write user stories like novels. We track KPIs with the precision of a chess grandmaster. We A/B test the color of buttons until our eyeballs hurt. We iterate ruthlessly. We chase product-market fit like it’s the Holy Grail - because for us, it might be.
We are obsessed.
Then we turn to our teams. And something strange happens.
We stop being product people. We become... managers. We “manage” them. We track their velocity like a factory floor supervisor counting widgets. We hold 1:1s talking about project status and call it leadership. We optimize their utilization rates like they’re servers in a data center.
We treat them like a list of line items on a spreadsheet. Cost drivers. Resource units. Something to be spent.
Here’s the uncomfortable truth I’ve learned the hard way a long time ago: This is our biggest strategic failure as leaders. And it all starts with a single, dehumanizing word.
That word is “resources”.
Why Language Matters More Than You Think
I refuse to use the word “resources”. Full stop. It’s non-negotiable for me. In every planning meeting, every strategy session, every moment where I might be tempted to say “we need more resources”, I pause and choose different language.
I talk about “team capacity.”
And before you dismiss this as semantic nitpicking - please don’t. This isn’t just word choice. It’s the most critical mindset shift a leader can make in the AI era.
Here’s why: A “resource” is something you spend. It’s a line item on a P&L. A cost to be minimized. You extract value from a resource until it’s depleted - and that’s exactly the operating model that produces burnout, attrition, and fractured teams. A resource gets used up. That’s its entire purpose.
“Capacity” is something you build. It’s a high-performing system you invest in. It’s an asset that grows in value, capability, and potential. Capacity compounds. It learns. It creates secondary effects. It gets better the more you invest in it.
Think about the difference in your mental model:
The “resource” mindset makes you a foreman. Your job is allocation. Utilization. Extraction.
The “capacity” mindset makes you a Product Manager. Your job is building, enabling, compounding.
This is the core insight behind what I call the “Team as a Product” framework. Your job isn’t to allocate resources. Your job is to build your team like you’d build your most important product. With the same obsession. The same iteration. The same ruthless pursuit of excellence.
This isn’t just a metaphor. It’s an operating system. And it runs on four core pillars.
Pillar 1: Shared Goals & Clear Accountability
You give a “resource” a list of tasks.
You give a “product” a vision and a clear win condition.
This is the foundation. Legendary teams - the kind that move the needle - start with obsessive clarity about what “winning” actually looks like. And I’m not talking about everyone nodding politely at quarterly priorities while thinking about their email. I’m talking about a single source of truth that unlocks autonomous decision-making across the entire team.
Shared Goals: Use outcome-driven frameworks like OKRs.
I know OKRs aren’t new. But they work because they do something brilliant: they clarify intent without prescribing solutions. The Objective is the “why” - the direction. The Key Results are the “how much” - the measures. This separation is powerful. It tells your team where you’re trying to go without handcuffing them to a specific path. They can innovate. They can adapt. But they stay aligned.
The magic happens when the entire team is working from the same source of truth. No more wasted cycles arguing about priorities. No more misalignment that masquerades as autonomy.
Clear Accountability: Use RACI matrices to define who owns what.
Here’s something I’ve learned through hard-won experience: When everyone owns the decision, no one does. Full stop. Research backs this up - decision-making speed and quality skyrocket when a single person is made the clear owner.
But here’s where most teams fail. They say “clear accountability” and then get fuzzy about it. They have meetings about ownership. They create slide decks about ownership. Nobody’s actually owning anything.
Get specific. Use a RACI matrix (or OCI if you’d like a lighter version of it). Responsible. Accountable. Consulted. Informed. It sounds mechanical, but the moment you name who makes the final call, something shifts. People stop jockeying for credit and start jockeying for impact.
Now Here’s My Real Take: Most teams talk about alignment like it’s a spiritual practice. But I’ve learned alignment isn’t something you say - it’s something you measure.
A “resource” is measured by utilization. “Are they 100% allocated?” That’s the question. It’s a trap. It’s an optimization for the wrong metric.
An owner is measured by impact. “Did they move the business forward?” That’s the only question that matters.
I will always bet on an owner over a resource, every single time. Because an owner doesn’t need to be managed. They don’t need to be pushed. They pull themselves toward the outcome.
Pillar 2: The Right Tools, Frameworks & Information
Empowerment without enablement is just cruel.
Think about it. You tell your team “you own this.” You inspire them with a clear vision. You give them autonomy. And then... they hit a wall. They don’t have the right tools. The data is siloed. The processes are clunky. They spend half their week just trying to figure out where to find the information they need.
That’s not empowerment. That’s abandonment.
A “resource” gets burned out by friction. By bureaucracy. By broken systems.
A “product” scales when the user experience is frictionless.
Here’s the reframe: Your team is your internal customer. And just like with your external product, you need to be obsessed with their Developer Experience - or in broader terms, their Work Experience.
And let me be clear: this isn’t just for engineers or data scientists. This is for everyone. PMs, designers, analysts, operations. Every person in your team deserves tools that enable them, not constrain them.
Codify Decisions with Frameworks
Don’t reinvent the wheel in every meeting. Your team should have simple, shared frameworks they can reach for instantly. RICE scoring for prioritization. Impact-vs-Uncertainty matrices for strategy. Decision trees for the choices they face constantly.
When you codify how you make decisions, you turn judgment calls into logical exercises. You remove the emotion. You create predictability. And you make it so new people can ramp up in days instead of months because they understand the system.
Enable Experimentation Infrastructure
Your team should be able to test hypotheses in hours, not quarters. This means building the plumbing. Feature flags. A/B testing infrastructure. Automated feedback loops. Low-friction deployment.
I’ve worked in environments where it took three weeks to deploy a change. And I’ve worked in environments where it took 15 minutes. The difference isn’t the talent. It’s the infrastructure. It’s the Work Experience.
Build the plumbing that lets your team move fast and stay safe.
Unify Data
How can I not talk about data?
This is non-negotiable. A single source of truth for data across your organization. When different teams are making decisions off different versions of the truth, you don’t have alignment - you have organized chaos.
I’ve watched teams spend weeks reconciling conflicting metrics, arguing about which dashboard was “right,” only to discover they were solving the same problem from different angles. It’s wasteful. It’s demoralizing.
Now - We’d fire a PM who ignored a broken checkout flow that loses 30% of users. Yet we let our teams work around broken build systems. Clunky data pipelines. Tools that were outdated three years ago.
We’re making a statement with that double standard: “Your time doesn’t matter as much as our external customers’ experience.”
That’s backwards.
Investing in your team’s Work Experience isn’t a cost center. It’s an R&D investment in your most critical product.
Pillar 3: Strong Culture & Engineering Rigor
This pillar takes the clarity and capability from the first two and turns them into excellence.
A “resource” is managed with a rigid process. Follow the steps. Execute the plan. Ship it.
A “product” is improved through a lifecycle. Discover. Iterate. Ship. Learn.
Your team’s culture is its lifecycle. It’s where you balance two forces that seem contradictory but are actually inseparable:
Psychological Safety
Research from leaders like Amy Edmondson has proven something profound: teams with psychological safety - the belief that you can take risks, ask “dumb” questions, and challenge the status quo without fear of punishment - those teams innovate.
They experiment. They learn. They adapt.
Without it, you get compliance. You get people covering their tracks. You get innovation theater while your competitors are actually moving.
Innovation Discipline
But - and this is crucial - safety without discipline is chaos.
You need to pair that psychological safety with ruthless discovery practices. Test assumptions before building. Rapid feedback loops. A culture that values speed and stability equally.
This is where engineering rigor comes in. Not as a constraint on innovation, but as its enabler. Automated testing. CI/CD pipelines. Small, frequent deployments. Blameless post-mortems.
These aren’t bureaucratic overhead. They’re cultural statements. They say: “We value learning. We value speed. We value safety.”
Now the CoE Piece - The difference between a team that stagnates in fear and a team that learns and accelerates comes down to this: How do you treat failure?
When a “resource” fails, it’s a blame event. Someone messed up. Someone’s on the hook. The message is clear: don’t fail again.
When a “product” fails, it’s a bug you fix in a blameless post-mortem. What went wrong? Why didn’t we catch it? What do we change so it doesn’t happen again?
This single distinction separates teams that are scaling from teams that are shrinking. Not in headcount - in spirit.
Pillar 4: Onboarding as a Product Feature
Here’s where the “Team as a Product” metaphor becomes most literal.
You acquire or assign “resources.”
You onboard new users to your product and activate their potential.
Your “hiring” is your “customer acquisition strategy.”
Your “onboarding” is your “new user experience.”
A “resource” gets a laptop. A calendar invite. Maybe a folder with some links.
A new team member - your “user” - is guided toward their “Aha!” moment. The moment where they understand not just what they’re doing, but why it matters. The moment where they feel like part of something bigger than themselves.
And here’s the thing: that moment doesn’t come on day one. It doesn’t come when the paperwork is signed. It comes when they ship their first meaningful contribution. That’s the activation moment. That’s when they become part of your product.
Now importantly - Most organizations treat onboarding like a checkbox. Paperwork done? Check. First day meeting done? Check. Great, now get to work.
But onboarding isn’t done until your new hire has shipped something real. Something they built. Something that moved the needle.
Every single step of their first 30 days should be designed to get them to that moment - that “Aha!” - as quickly and smoothly as possible.
Pair them with mentors. Give them small wins early. Let them see impact. Show them how their work connects to the larger mission.
That’s when onboarding is actually done.
The Human Truth: This Isn’t About Metaphors
“Resource” is a word from the industrial era. It’s a word of extraction and depletion. It’s a word that leads to burnout, attrition, and teams that check out.
The “Team as a Product” I’ve been talking about? That’s the word for the new era of leadership. It’s a word of investment and potential and compound returns.
Treating your team as your #1 product isn’t a clever framework. It’s not a trendy management technique. It’s a leadership philosophy. It’s the only way to stop spending talent and start building it.
It’s the difference between seeing a spreadsheet of costs and seeing a roster of people with unlimited potential.
The Question for You
What’s the one “bug” in your “team product” right now that’s draining your people?
And more importantly: What’s the one investment you can make this week to start fixing it?
Because the leader who answers that question isn’t trying to manage resources. They’re building something that lasts.