Product Culture

You are trying to figure out whether your product organization is actually empowered to build great products — or whether it is a feature factory dressed up in agile terminology. This distinction matters because the difference between a healthy and unhealthy product culture is the difference between PMs who drive outcomes and PMs who take orders. And if you are a PM evaluating a new company, diagnosing the culture before you accept the offer can save you years of frustration.

Empowered Teams vs Feature Factories

Christian Idiodi, partner at Silicon Valley Product Group alongside Marty Cagan, has made this distinction the centerpiece of SVPG’s work. As he puts it, “The real essence of this job is that you wake up on behalf of someone else to solve a problem for them, and you have to do it well enough that they give you something back in return.” The framework is simple but cuts deep:

Dimension	Empowered Product Team	Feature Factory
What teams receive	Problems to solve (outcomes)	Features to build (output)
Who decides the solution	The product team (PM, design, engineering)	Stakeholders or executives
How success is measured	Did we move the metric?	Did we ship on time?
Role of the PM	Product discovery, strategy, decision-making	Project management, requirements documentation
Role of engineering	Co-creating solutions, technical innovation	Taking tickets, estimating effort
Speed of learning	Fast — teams test hypotheses weekly	Slow — teams build for months, then launch and hope
Ownership	Teams own outcomes end to end	Teams own delivery; someone else owns the result

Idiodi observes that most organizations operate as feature factories, even ones that believe they are empowered. The tell is not what leaders say about their culture — it is how decisions actually get made. As he explains, “When I think through the companies I’ve worked with, where I see this discipline really eroded is where there is just not a competent level of product management.” If the roadmap is decided in a quarterly planning meeting by executives, and the product team’s job is to figure out how to deliver that roadmap, that is a feature factory regardless of what the mission statement says.

How to Diagnose Which One You Are In

A diagnostic checklist, synthesized from Christian Idiodi, Geoff Charles, and Melissa Perri:

You are likely in an empowered org if:

• Product teams are assigned problems (e.g., “improve activation rate for new users”) rather than solutions (e.g., “build an onboarding wizard”)
• PMs have direct access to customers and data without going through a gatekeeper
• Engineers participate in discovery — they attend customer calls, contribute solution ideas, push back on PM assumptions
• Teams can kill projects that are not working without executive approval
• The roadmap is a set of bets and hypotheses, not a Gantt chart of committed features
• Success is celebrated when metrics move, not when code ships

You are likely in a feature factory if:

• The roadmap is a list of features with delivery dates, decided by stakeholders
• PMs spend most of their time writing requirements and managing timelines
• Engineering receives specs and is measured on velocity and story points
• Customer research happens once a year (or never), not continuously
• Stakeholders review progress by asking “when will it ship?” rather than “what did we learn?”
• Shipped features that do not move metrics face no accountability — the team is already working on the next feature

What “Product-Led” Actually Means Organizationally

The phrase “product-led” gets overused. It does not mean the PM is the boss. It means the product team — the triad of PM, design, and engineering — is trusted to discover and deliver solutions to customer problems.

Geoff Charles, VP of Product at Ramp, describes how this works at one of the fastest-growing SaaS companies in history. He calls it “context over control”: “Whenever things went wrong at Ramp, it was when I was being prescriptive with regards to the solution without actually explaining and aligning upstream on the goal, the hypothesis, and the data. If you do that, you realize that the solutions actually can come much better from teams that are much closer to the ground.”

This is the critical point most companies miss. You cannot empower teams without first solving the context problem. As Melissa Perri frames it from her experience with thousands of product managers: “I’ve met a lot of organizations that think most of their issues are in the training of their people. And 99% of the time I see that it’s actually in the way that they’re setting their goals and deploying their strategy. Because once you train those people, they have no context on what to work towards.” If teams do not understand the strategy, do not have access to data, and cannot talk to customers, giving them “autonomy” just produces chaos. Empowerment requires infrastructure.

Ravi Mehta, former CPO of Tinder and product director at Facebook, offers a useful matrix for thinking about this. As he explains, “Your ideal goal is to lead in a scalable way, which means you feel really confident about the direction of your team and your team has the autonomy to move in that direction.” The prerequisites for empowered teams:

1. Clear product strategy. Teams need to know where the company is going and why.
2. Specific team objectives. Each team has a well-defined problem space with measurable outcomes.
3. Competent product trios. The PM, designer, and tech lead must each be skilled enough to operate without constant oversight.
4. Trust from leadership. Leaders must actually let teams make decisions, including ones they disagree with.

When any of these prerequisites is missing, empowerment fails — and leaders use the failure as evidence that teams cannot be trusted, which reinforces the feature factory pattern.

Signs of a Healthy Product Culture

Beyond the empowered-vs-factory spectrum, several cultural signals differentiate organizations where product people thrive:

Intellectual Honesty About Results

Healthy product cultures track outcomes, not just outputs. When a feature ships and does not move the target metric, the team conducts an honest retrospective rather than moving on. Dharmesh Shah, co-founder and CTO of HubSpot, built radical transparency into the company from day one — literally designating every single employee as an insider when HubSpot went public so they could maintain their policy of sharing all financials with everyone. As he describes: “All information within HubSpot is equally shared with everyone in the company, period. Everything. So our balance sheet, what we raised capital at, whether we’re going to be able to meet payroll in six weeks.” That level of transparency creates the intellectual honesty required for a healthy product culture.

Tolerance for Experimentation (and Failure)

At companies with strong product cultures — Shopify, Airbnb, Netflix, Spotify — teams are expected to run experiments that might fail. The ratio matters: Netflix ships roughly one out of every ten experiments as a permanent feature. That means nine out of ten ideas do not work. If your organization punishes teams for running experiments that fail, people will stop experimenting and start building only safe, incremental features.

Cross-Functional Respect

In a healthy culture, engineering is not “the department that builds what PM spec’d.” Design is not “the team that makes it look pretty.” Each discipline has a seat at the table during discovery and strategy. Idiodi frames it through competency: “Imagine if you had [deeply competent product people] on every team. Imagine how much you can accomplish.” When the product function earns trust through demonstrated competency, other disciplines naturally engage as partners rather than order-takers.

Decision-Making Velocity

Geoff Charles describes how Ramp operationalizes fast decision-making: “The contract between me and the team is really their strategy and their roadmap. And as long as we are aligned on the strategy and aligned on the roadmap and the timing, that’s their contract. My goal is to continue to give them context to execute on that and to coach them through that.” Teams surface one-way, high-stakes decisions upward; everything else they own. Unhealthy cultures treat every decision as high-stakes — requiring multiple reviews, stakeholder sign-offs, and committee approval for decisions that could be reversed in a sprint.

A practical test: how long does it take for a PM to go from “I have a hypothesis” to “I am testing it with users”? At empowered organizations, this is days. At feature factories, it is months.

How to Shift the Culture

If you are a product leader trying to move from feature factory to empowered, the transition is difficult and gradual. Melissa Perri, who has worked with north of 4,000 product managers, recommends starting small:

1. Pick one team. Find a team with a strong PM, a willing engineering lead, and a tractable problem. Run them as an empowered team for one quarter.
2. Define the outcome, not the output. Give them a metric to move, not a feature to build.
3. Protect them. Shield the team from stakeholder requests and re-prioritization during the quarter.
4. Publicize the results. If the team moves the metric (and they usually do), use the case study to justify expanding the model.

The biggest obstacle is not the team — it is the stakeholders who lose their direct line to the roadmap. Empowered teams mean executives can no longer dictate features. That is a political transition as much as an organizational one, and it requires top-down commitment.

Key Takeaway

• If your roadmap is a list of features with delivery dates, you are in a feature factory — regardless of what your mission statement says. Empowered teams receive problems to solve, not solutions to implement.
• You cannot empower teams without first solving the context problem. Strategy, data, and customer access must be accessible to every team.
• Test your culture with one question: how long does it take to go from a hypothesis to a user test? Days means empowered. Months means feature factory.

Related

• Hiring PMs — The kind of PM you hire should match the culture you are building
• OKRs — Outcome-based OKRs are a precondition for empowered teams
• One-on-Ones — Where cultural problems surface first
• IC vs Management Track — Culture determines whether senior ICs can have real impact

Sources

• Dharmesh Shah on building HubSpot’s culture — Radical transparency, designating all employees as insiders, leaning into strengths over management conventions
• Geoff Charles on Ramp’s velocity culture — Context over control, single-threaded teams, empowering small teams to ship fast
• Christian Idiodi on the essence of product management — Competency-based trust, why product management is disliked, earning the right to make decisions
• Melissa Perri on product org transformations — Strategy deployment, the context gap in most organizations, signs you need a CPO
• Ravi Mehta on product leadership — Scalable leadership matrix, autonomy vs micromanagement, product strategy stacks