Company as a Product

“One of the things that we do differently is that we treat our company as a product” — Jason Fried, CEO and co-founder of 37signals (Wisdom From The Top with Guy Raz). Dharmesh Shah makes a similar point: “Culture is a Product. Every company builds two products — one is the product they build for their customers, and the other is a product they build for their team.”

That is the idea most organizations miss. The organization itself is a product. It has users, friction, experience problems, adoption curves, investment choices, and outcomes. If you treat it as background machinery, it drifts. If you treat it as a product, you can discover, design, fund, and improve it deliberately.

Treating the company as a product means applying the same disciplines that make great product teams effective — customer discovery, iterative delivery, outcome orientation, and continuous improvement — to the development of the organization itself. Through the lens of a Product Operating Model, this breaks into three dimensions. Each one changes a different part of how leaders think about the company they are building:

• Mindset — Approach every organizational challenge with a view to stakeholders, users, outcomes, dependencies, ownership, and value. Ask “who are the customers of this internal process or experience?” before asking “what should we build?” One concrete example: seeing yourself as a Steward of the employee experience. One of Yuval’s clients — a COO in everything but title — chose the title “Head of Stewardship” to make this mindset explicit and visible to the organization.
• Alignment — Organize, structure, and manage to a product model. Define cross-functional teams around company-as-a-product challenges. Align them to shared outcome-oriented goals (OKRs, for example). For instance: who needs to be involved to improve the hiring and onboarding experience? One organization carved out a small cross-functional team involving People, IT, and hiring managers to collaborate on the whole experience, as customers of this product and as a team aligned to a shared OKR.
• Investment — Plan and invest in your company like it is one of the products in your portfolio. Define a strategy for it. Set intermediate goals. Make conscious investment choices between improving the company vs. building customer-facing products. Manage the flow of those investments.

Most organizations invest heavily in developing products for customers and almost nothing in deliberately developing themselves as organizations. The result is that the management operating system — how decisions are made, how teams are structured, how work flows, how strategy is executed — becomes increasingly misaligned with the complexity of the work. The company-as-a-product idea closes this gap by applying the same rigor to internal development that ambitious product organizations apply to their customer-facing products.

The practical implications are significant:

• Internal customers — employees, teams, and leaders are customers of internal products (HR processes, tooling, communication systems, reporting). Treating them as customers changes how you design and improve these systems.
• Outcomes over outputs — rather than measuring “we held 200 onboarding sessions,” you measure “new joiners reach full productivity 30% faster.” The outcome frame changes what gets prioritized.
• Continuous improvement — rather than running an annual reorganization or a once-a-decade ERP replacement, you improve the organization iteratively, with frequent inspection and adaptation.
• Explicit investment — rather than letting the organization drift, you make deliberate portfolio decisions about where to invest in organizational capability vs. customer-facing product capability.

The agile and Product Operating Model layer makes “company as a product” actionable rather than a metaphor. It turns the idea into concrete choices about teams, goals, cadence, and investment:

• Designing self-managed, empowered teams with minimal dependencies, applying the same team topology thinking to internal teams (People, Finance, IT, Legal) as to product teams. The test is whether the team can improve an internal experience without waiting on half the org chart.
• Working in quick iterative cycles, building increments of organizational value, testing them with internal customers, inspecting results, and adapting. The equivalent of “working software” for internal products is a meaningfully improved employee or team experience.
• Aligning to outcome-oriented goals, using OKRs or similar goal systems for organizational improvement work, with leading indicators to track whether the change is actually working.
• Focusing on the right things, because even organizational improvement work can become a portfolio of too many simultaneous initiatives, each competing for the same leadership attention.
• Using proven frameworks carefully, adapting Scrum, Kanban, and SAFe practices that work for product development to complex organizational change. The point is to borrow the useful mechanics, not to turn the company into a ceremony factory.

• Developer Experience as a Product — a team explicitly responsible for the tooling, build systems, testing infrastructure, and developer workflows that make the engineering organization faster and less frustrated. This team has a Product Owner, a roadmap driven by developer satisfaction and productivity metrics, and a regular cadence of shipping improvements.
• Employee Onboarding as a Product — instead of an onboarding “program” run by HR, a cross-functional team continuously improves the new joiner experience: measuring time-to-productivity, testing different onboarding structures, and treating new joiners as customers whose experience needs to be designed and optimized.
• Hiring Process as a Product — applying product discovery to recruiting: interviewing candidates, hiring managers, and successful hires about where the hiring funnel creates friction, then iterating on the process. The customer is not only the hiring manager; candidates experience the product too.
• Internal Knowledge Systems as a Product — wikis, documentation, and knowledge management systems treated as products with users, metrics, and a team accountable for whether the information people need is actually findable.

The company-as-a-product mindset applies across leadership levels:

• Team leads and managers can apply it to the team experience they are creating for their reports — the psychological safety, clarity of direction, quality of feedback, and fairness of process.
• Functional leaders (People, Finance, Legal, IT) can apply it to the internal services and experiences their functions deliver to the broader organization.
• COOs and Chief of Staff leaders can apply it to the company’s operating system — how decisions are made, how information flows, how resources are allocated.
• CEOs and founders like Jason Fried and Dharmesh Shah can apply it to the organizational design and culture they are actively building, rather than passively experiencing.

At every level, the shift is the same: stop managing the organization as an inherited system, and start actively developing it as a product. That changes the leadership conversation from “how do we keep the machine running?” to “what experience, capability, or operating constraint should we improve next?” It also makes organizational improvement less abstract, because the work is tied to users, outcomes, feedback, and investment choices.

The practical first move is not a company-wide reorg. Pick one high-friction internal experience — onboarding, hiring, meeting culture, developer experience, decision-making, or knowledge flow — and treat it as a product. Name the internal customers, define the outcome you want to change, and give a small cross-functional group enough ownership to improve it.

That is where “culture work” becomes operational. Instead of running another values workshop, you improve the system people actually experience every day and check whether the change made work better.

Interested in applying product thinking to organizational development? Explore the Company as a Product approach or connect with Yuval to discuss how this applies to your context.