Big Slice / Small Slice (BSSS)

The General Idea
When working with friends on projects I always run into the problem that everyone has hidden expectations about ownership and what it means to be successful. Many of us don’t even know that we have these expectations. They are based on how we were raised and what we value. Thus they are very personal, hidden, and can easily destroy a friendship if you become successful. On the flipside of this is the overthinking that happens from creating shares too early. It cost a real money, momentum, and energy to create shares and a vesting schedule. Suddenly that playful idea feels like work and it kills the joy of creation with adulting.
Therefore I invented these rules as insurance against the misscomunications that form when we all are excited to build something and don’t want to think about how much of nothing each of us will own… Until it isn’t worth nothing.
The Big Slice / Small Slice idea originated as a design pattern for allocating ownership dynamically and transparently in early ventures. It was first described as a way to prevent resentment, hidden dilution, and retroactive negotiation when teams were contributing unevenly under high uncertainty.
Vocabulary
Big Slices
A Big Slice represents a major milestone in the life of a project.
Each Big Slice:
- Consumes a declared percentage of the total 100%
- Is tied to a specific Release Level (RL1–RL10)
- Has a point budget for contribution tracking
- Opens when work begins
- Closes when the Release Level is achieved
Critical rule:
Once a Big Slice is created, its percentage must never change.
Point budgets may increase.
Ownership percentages may not.
Small Slices
Contributors earn Small Slices inside a Big Slice.
A Small Slice represents a contributor’s proportional share of that Big Slice, calculated as:
(points earned / total points in the Big Slice) × Big Slice percentage
When a Big Slice closes, ownership earned inside it is locked.
The Rules
Rule 1: Treat ownership as a fixed whole:
A project begins as 100% ownership. Think of a pie. Now budget out what milestones the project is going to go through. Set a percentage to each milestone and lock that down with your group.
Rule 2: Track effort from each contributor in each phases
The philosophy is that progress earns ownership, time alone does not.
You can track hours, you can use dubloons, you can track happy points, it doesn’t really matter. I prefer to use a point system because then effort like sales or connections can be trued up against hours. Sales, networking, and engineering work very differently and the contributions are not equivalent.
I think the easiest way to do this is to setup a regular meeting where everyone involved shows up and says how many points they contributed to this project. Then the group agrees or debates it, and records the decision in a journal. This turns one giant akward discussion into lots of little akward discussions.
Rule 3: At the end of each Big Slice (milestone) tally up the small slices.
Ownership is divided into:
- Big Slices — milestone-level allocations
- Small Slices — individual shares earned within a milestone
So at the end of each milestone tally up how many points each contributor made and then proportinaly split up the big slice they just worked through. Then move onto the next phase.
That ownership is not assigned to people upfront. Instead, it is earned over time as the project progresses through meaningful milestones.
Recommended Ownership Allocation
The following table represents a recommended allocation of ownership across Release Levels.
This is not universal law.
It is an opinionated default that reflects where risk and value tend to concentrate.
| Release Level | Description | Slice % |
|---|---|---|
| RL1 | Idea | 4% |
| RL2 | Vision | 4% |
| RL3 | Prototype | 4% |
| RL4 | Play Test | 12% |
| RL5 | Release | 16% |
| RL6 | Users | 12% |
| RL7 | Audience | 12% |
| RL8 | Monetized | 12% |
| RL9 | Scalable | 12% |
| RL10 | Stable | 12% |
| Total | 100% |
Regarding this Allocation Philosophy
- Early stages matter, but are highly speculative
- Mid-stage execution carries the highest product risk
- Late stages reward durability, scale, and operational excellence
To Conclude
What This Is (and Is Not)
This system is:
- A contribution accounting model
- A milestone-based ownership framework
- A pre-equity alignment tool
This system is not:
- Legal equity
- A cap table
- A shareholder agreement
It is a bridge between ambiguity and formality. Assuming success then you can transition to something more formal like a captable and preferred shares. But until then it can just be a spreadsheet.
Bonus
I did build this into my system on The Idea Is in case you want to use it when you get to the implementation level.