Funding Models
How teams fit into your organization's resource allocation
General Funding Models and Fundable Units
Once you've defined the teams, the individuals on those teams, their topologies, and their scopes, you're ready to have meaningful conversations about how teams fit into your Product Operating Model.
But one vital issue remains: funding.
This is where context really matters. There is no one-size-fits-all model. However, the Dotwork Starter Pack provides enough structure to help you describe and experiment with how funding decisions are made—and how teams or units are positioned in that system.
First: What Is the Fundable Unit?
The first step is determining whether a team is a fundable unit on its own—or whether funding is applied to something broader that the team contributes to.
Example 1: Fundable Team
Imagine a 10-person team responsible for a product-led growth (PLG) motion focused on a key touchpoint. Their work is clearly tied to revenue, they operate relatively independently, and progress is easy to measure. In this case, the team itself may be treated as a standalone fundable unit.
Example 2: Shared Customer Journey
Now imagine a dozen teams contributing to a shared customer journey—say, onboarding or renewals. In this case, individual teams may be assessed on contribution, but funding flows toward the value stream or customer journey as a whole.
Example 3: Project-Oriented Funding
Some organizations operate on a project funding model, where teams are staffed based on their ability to execute scoped work. Projects carry their own business cases, ROI estimates, and time frames.
Example 4: Internal Platform Teams
A platform team may enable dozens of other teams to do customer-facing work. You can treat the internal teams as customers and model the relationship as transactional, or model the platform team's value indirectly based on how well the downstream teams succeed. Neither approach is universally right. The goal is to make the model explicit.
How the Starter Pack Supports Funding Models
In the Starter Pack, each team, group, or area can be marked as:
- A fundable unit (i.e., receives budget independently), or
- A contributor to something that is funded (e.g., customer journey, product, strategic theme, etc.)
For those marked as fundable, you can specify one or more funding models that describe how they are resourced and evaluated.
Use the phrase: "This team is funded based on…" to brainstorm relevant funding models.
Example Funding Models
| Funding Model | Description |
|---|---|
| …measurable business performance | The team is funded based on impact metrics such as revenue, growth, retention, cost reduction, etc. |
| …continued ownership of a key capability or service | The team owns and maintains a critical system or capability that must remain operational and improve over time. |
| …delivery of funded projects | The team receives resources to complete scoped, funded initiatives aligned to business cases. |
| …supporting a customer journey or value stream | Funding is directed at the journey level, and the team is one of many contributing to outcomes in that stream. |
| …platform adoption by internal customers | The team is funded based on the degree to which internal teams successfully adopt and rely on its platform or tools. |
| …strategic alignment with company priorities | The team is funded based on alignment to high-level strategic goals (e.g., AI enablement, international expansion). |
| …regulatory or compliance necessity | The team is funded to meet legal, safety, or compliance obligations (e.g., GDPR, security certifications). |
| …core infrastructure stewardship | The team manages underlying systems or infrastructure required for the business to operate effectively. |
You can use one or more funding models per team to reflect blended reality—many teams are funded through a mix of direct ownership, platform enablement, and project delivery.
Advanced Funding—Team Stages
So far, we've looked at how to define fundable units and assign funding models. But for certain types of autonomous teams a critical next layer is understanding the team's stage.
Not all teams will (or should) define a stage. This concept is reserved for teams/groups with a higher degree of autonomy—where leadership wants to make differentiated investment, staffing, and governance decisions based on the team's current lifecycle stage.
Even highly independent teams don't operate in a static state. They evolve over time—launching new offerings, finding product-market fit, scaling operations, or optimizing for efficiency. Applying the same funding and staffing logic to a team searching for PMF as you would to a scaling unit simply doesn't work. The nuance matters.
Example Team-Context Stages
These stages are meant to capture the dominant posture of a team at a given time. The exact boundaries may blur, but the funding logic and decision-making implications shift meaningfully across each:
| Stage | Description | Funding Logic |
|---|---|---|
| New Offerings | High-risk exploration of a new product, problem space, or market. Team is validating assumptions and running rapid experiments. | Milestone-based, iterative funding with frequent reassessment—similar to early-stage startup logic. |
| Strategic Expansion | Extending a validated offering into new geographies, verticals, or channels. | Funded via targeted burn, with focus on feasibility, alignment to strategy, and path to scale. |
| Growth Accelerator | Team has product-market fit and is working to scale adoption and revenue. | Funded by ROI-driven models (e.g., rule of 60, CAC payback), with performance-based expectations. |
| Margin Optimizer | Proven business, now focused on driving margin and efficiency. | Funded by efficiency targets, process refinement, and cost-structure improvements. |
| Operational Optimizer | Team focuses on improving internal tools, quality, or reliability. | Funded via internal satisfaction metrics, usage, and throughput metrics. |
| Rebuilding After Breakdown | Team has lost alignment, clarity, or capability—may be coming off failed initiatives or turnover. | Funded based on reset logic: cost to restore productivity vs. expected long-term value. |
These stages aren't just labels—they shape how you plan, staff, and support teams. A New Offerings team might need design researchers and fast-access funding. A Margin Optimizer team might need financial analysts and lean ops coaching.
In the Starter Pack
- Only certain teams (typically those with autonomy and ownership of a product or capability) can be assigned a Team Stage.
- Teams not eligible for a stage assignment can still be linked to funding models, topologies, and scopes, offering plenty of flexibility without overfitting.
This model balances flexibility and realism: it's enough structure to reflect real variation across your org, without forcing every team into the same mold.
A Note on Funding ↔ Topology Dependency
Both Funding Models and Team Stages are often heavily influenced by a team's topology.
For example:
- A Stream-Aligned Team focused on a specific customer journey might be a strong candidate for a standalone funding model or a defined stage (e.g., Growth Accelerator).
- An Enabling Team may not have a direct funding model of its own but instead contribute to the success of other fundable teams.
- A Platform Team might use internal adoption and service metrics as a proxy for value, aligning with models like Platform Adoption or Operational Optimizer.
- A Complicated Subsystem Team might be funded for ongoing capability maintenance or embedded within project-based funding flows.
Your Team Topology shapes expectations for how a team contributes, collaborates, and gets funded. It's important to reflect those dynamics explicitly when setting up funding structures in your Product Operating System.
This is why, in the Starter Pack, funding options and team stages are configurable but constrained—so that they remain aligned with the team's fundamental purpose and design.