Parkinson's Law

What is Parkinson’s Law?

Parkinson’s Law states that work expands to fill the time available for its completion. In simple terms, a task that could take two hours may take a full day if a full day is available.

The idea is often used to explain why people procrastinate, why meetings take the full scheduled time, and why projects become larger than they need to be.

Work expands to fill the time available for its completion. – Cyril Northcote Parkinson

For product teams, Parkinson’s Law often appears when discovery work has no decision point, a roadmap has too much available capacity, or a feature grows because the deadline allows it.

Parkinson’s Law does not mean people are lazy. It means time, scope, and expectations shape how work behaves. When teams have loose deadlines, unclear definitions of done, or too much room for expansion, the work often grows.

Parkinson’s Law definition

Parkinson’s Law is a principle of time management and organizational behavior. It describes the tendency for work to take as much time as it is given.

A short deadline can create focus. A long deadline can invite extra scope, more discussion, unnecessary polish, or delayed decisions.

For example:

• A 30-minute decision takes 60 minutes because the meeting was scheduled for an hour.
• A small feature becomes a larger release because the team has a full quarter available.
• A stakeholder review turns into a long discussion because no decision rule was agreed in advance.
• A student waits until the last evening to finish an assignment because the deadline allows it.

The available time becomes a container, and the work expands to fill it.

Where did Parkinson’s Law come from?

Parkinson’s Law was introduced by British historian and author Cyril Northcote Parkinson in a 1955 essay published in The Economist. He later expanded the idea in his 1958 book Parkinson’s Law: The Pursuit of Progress.

Parkinson originally used the idea to describe bureaucracy. He observed that administrative work and staffing levels could grow even when the amount of useful work did not increase.

Over time, the idea became widely used in business, project management, software development, agile teams, and personal productivity.

In product development, the concept is useful because product work is often open-ended. Research, design, stakeholder alignment, prioritization, and delivery can all expand unless the team creates clear limits.

Parkinson’s Law examples

Parkinson’s Law is easy to recognize in everyday work.

Meeting example

A team schedules a one-hour meeting to make a decision. The decision could be made in 15 minutes, but the discussion continues until the full hour is used.

The meeting expands to fill the time available.

Product roadmap example

A product team has an open quarter in the roadmap. Instead of using the extra time to create focus, more features, requests, and improvements are added until the quarter is full.

The roadmap expands to fill the available capacity.

Feature scope example

A team plans a simple improvement to a signup flow. Because the release date is several weeks away, the work grows to include additional edge cases, copy changes, tracking updates, and design refinements.

Some of this work may be useful. Some of it may be unnecessary. Parkinson’s Law appears when the scope grows mainly because time is available.

Design review example

A design review begins with a narrow question about one screen. Because the purpose of the review is not clear, the conversation expands into layout, content, onboarding, brand, navigation, and future roadmap ideas.

The review expands because no boundary was set.

Discovery example

A product manager starts discovery to understand a customer problem. Without a clear decision deadline, discovery continues through more interviews, more synthesis, more stakeholder updates, and more analysis.

The team learns more, but the decision keeps moving.

Student example

A student has one week to complete an assignment. The work could be completed earlier, but the student starts late and uses the full week.

The assignment expands to fill the deadline.

Parkinson’s Law in product management

Product management is especially exposed to Parkinson’s Law because product work often has flexible boundaries.

Unlike a simple task with a clear endpoint, product work involves judgment. Teams need to decide what problem to solve, how much evidence is enough, which trade-offs to make, and when a solution is good enough to ship.

Without clear constraints, product work can expand in several ways.

Discovery expands without a decision

Discovery can continue for too long when the team does not define what decision the research is meant to support.

A better approach is to ask:

• What decision are we trying to make?
• What evidence would be enough?
• When will we decide?
• What will we do if the evidence is still incomplete?

Discovery should reduce uncertainty enough to act. It should not become a way to avoid making a decision.

Roadmaps expand to fill capacity

When teams plan by available capacity instead of strategic priority, the roadmap often fills with too many initiatives.

This creates the appearance of productivity, but it can reduce focus. Teams may become busy across many projects without making meaningful progress on the most important ones.

A focused roadmap should make trade-offs visible. It should show what the team will not do as clearly as what the team will do.

Features grow before release

When a team has more time than necessary, features can grow through extra requirements, optional refinements, and late stakeholder requests.

This can be valuable when the additions improve the outcome. But it becomes a problem when the extra scope delays learning, increases complexity, or reduces the chance of shipping.

A useful rule is to cut scope before extending time.

Meetings fill the calendar

Product teams often rely on meetings for alignment. But without clear decisions, agendas, and time limits, meetings expand.

A 60-minute meeting often becomes a 60-minute meeting even if the useful discussion only needs 20 minutes.

Shorter meetings, written updates, and decision-focused agendas help prevent this.

Why Parkinson’s Law happens

Parkinson’s Law usually happens because of unclear constraints.

1. The deadline is too loose

When a deadline is far away, people naturally delay hard choices. Work may start slowly, expand in scope, or become more complex than necessary.

2. The Definition of Done is unclear

If the team has not agreed what “done” means, work can continue through endless improvement.

This is common in design, research, writing, strategy, and product discovery. There is always another improvement to make.

3. Scope is easier to add than remove

Stakeholders often find it easier to add ideas than to remove them. Without strong prioritization, the work grows.

4. People want to look busy

In some organizations, effort is more visible than outcomes. When busyness is rewarded, work expands to show activity.

5. Decisions are delayed

When teams avoid difficult trade-offs, they may keep working instead of deciding. More research, more meetings, and more analysis can become a substitute for commitment.

6. Perfectionism feels safer than shipping

Shipping creates feedback. Feedback can reveal mistakes. Because of this, teams may continue polishing work longer than needed.

How to avoid Parkinson’s Law

The goal is not to create unrealistic pressure. The goal is to create useful constraints.

Product teams can avoid Parkinson’s Law by making time, scope, and outcomes explicit.

1. Timebox the work

A timebox is a fixed period of time for a task, discussion, or project phase.

Examples:

• 25 minutes to draft a decision memo
• 45 minutes for a design critique
• 2 days for initial research synthesis
• 1 week to test a prototype
• 2 weeks to ship a small version of a feature

When the timebox ends, the team decides what to do next. The decision might be to ship, stop, cut scope, or continue deliberately.

The key is that continuation should be a choice, not the default.

2. Define what done means

A clear Definition of Done helps prevent work from expanding through ambiguity.

For a product team, “done” might mean:

• The user problem is clearly stated.
• The success metric is agreed.
• The design is reviewed.
• The feature works for the target use case.
• The release notes are ready.
• Tracking is implemented.
• The team has agreed what will not be included.

A Definition of Done creates a stopping point.

3. Cut scope before extending time

When work is too large, teams often ask for more time. Sometimes that is necessary. But the first question should be:

“What can we remove?”

Scope cuts might include:

• Shipping to fewer user segments
• Supporting fewer edge cases
• Removing low-value settings
• Delaying secondary features
• Replacing a custom solution with a simpler one
• Launching manually before automating

This keeps the team focused on the core outcome.

4. Use decision deadlines

Many product activities are not complete until a decision is made.

Examples include:

• Choosing which customer segment to prioritize
• Selecting a design direction
• Deciding whether to build, buy, or delay
• Committing to a launch scope
• Prioritizing one opportunity over another

A decision deadline prevents the work from expanding into endless analysis.

5. Make trade-offs visible

Parkinson’s Law thrives when teams pretend they can do everything.

Good product management requires visible trade-offs:

• What matters most?
• What can wait?
• What are we willing to ignore?
• What risk are we accepting?
• What will we stop doing?

Clear trade-offs reduce unnecessary work.

6. Start with the smallest useful version

Instead of asking, “What could this become?”, ask:

“What is the smallest version that creates value or teaches us something useful?”

This helps teams avoid overbuilding.

A smaller version may be:

• A prototype
• A concierge test
• A landing page
• A manual workflow
• A limited beta
• A single-path implementation
• A feature for one customer segment

The point is to learn or deliver value before the work expands.

7. Shorten meetings

Meetings often expand because they are scheduled in default blocks.

Try replacing:

• 60 minutes with 25 minutes
• 30 minutes with 15 minutes
• Status meetings with written updates
• Open discussion with a decision agenda

Every meeting should have a purpose. If the purpose is a decision, name the decision before the meeting starts.

8. Measure outcomes, not effort

When teams are measured by effort, work expands. When teams are measured by outcomes, focus improves.

Instead of asking:

• How busy is the team?
• How many meetings happened?
• How many tasks were completed?
• How many documents were created?

Ask:

• What decision did we make?
• What did we ship?
• What did we learn?
• What customer problem did we solve?
• What changed in the product or business?

Outcome-based measurement reduces unnecessary activity.

Parkinson’s Law and agile teams

Agile teams often use practices that help limit Parkinson’s Law.

Sprints, timeboxes, retrospectives, and incremental delivery all create constraints. They encourage teams to deliver smaller pieces of work more frequently.

However, agile does not automatically prevent Parkinson’s Law. A sprint can still fill with unnecessary work. A backlog can still grow without discipline. A planning meeting can still expand without a clear decision.

To reduce Parkinson’s Law in agile teams:

• Keep sprint goals focused.
• Limit work in progress.
• Split large stories.
• Use clear acceptance criteria.
• Avoid adding scope during the sprint.
• Review what was delivered, not just what was started.
• Keep retrospectives focused on concrete improvements.

Agile works best when timeboxes are paired with strong prioritization.

Parkinson’s Law vs. procrastination

Parkinson’s Law and procrastination are related, but they are not the same.

Procrastination is delaying the start of work.

Parkinson’s Law is work expanding to fill the available time.

A person can procrastinate because of Parkinson’s Law. For example, if a deadline is far away, they may wait until the deadline creates pressure.

But Parkinson’s Law can also happen without procrastination. A team may start on time and still use the full timeline because the work grows, the meetings expand, or the definition of done remains unclear.

Parkinson’s Law vs. scope creep

Parkinson’s Law and scope creep are also related.

Scope creep happens when the amount of work increases beyond the original plan.

Parkinson’s Law helps explain why scope creep happens: when more time is available, more work is added.

For example, a team may begin with a simple feature. Because the deadline is flexible, stakeholders add more requirements. The project grows, and the team uses the full available time.

The best response is to make scope explicit and protect the smallest useful version.

Parkinson’s Law of Triviality

Parkinson’s Law is sometimes confused with Parkinson’s Law of Triviality.

They are related, but they describe different problems.

Parkinson’s Law says work expands to fill the time available.

Parkinson’s Law of Triviality, also known as the Bike-Shedding Effect, says people often spend too much time on minor issues and too little time on important ones.

The classic example is a committee spending more time discussing a bike shed than a complex power plant. The bike shed is easier to understand, so more people have opinions about it.

In product teams, the Law of Triviality appears when stakeholders spend too much time debating button labels, colors, or minor copy changes while avoiding harder questions such as positioning, prioritization, technical risk, or customer value.

To avoid the Bike-Shedding Effect:

• Separate small decisions from large decisions.
• Give minor decisions a short timebox.
• Name the decision owner.
• Keep strategic discussions focused on impact.
• Do not let easy topics consume time needed for important ones.

Practical checklist for product teams

Use this checklist when a task, meeting, or project starts to expand.

Before starting work

• What outcome are we trying to create?
• What is the smallest useful version?
• What is the deadline?
• What is explicitly out of scope?
• Who owns the decision?
• What does done mean?

During the work

• Are we adding scope because it is necessary or because time is available?
• Can we cut scope instead of extending the deadline?
• Are we making progress toward an outcome or just creating activity?
• Is another meeting needed, or can this be decided asynchronously?

Before extending the work

• What new information justifies more time?
• What will we learn or deliver by continuing?
• What will we stop doing to make room?
• Who is accountable for the decision?

Frequently asked questions

What is Parkinson’s Law in simple terms?

Parkinson’s Law means that work tends to take as much time as you give it. If you give a task one week, it may take one week, even if it could have been finished in a day.

What is an example of Parkinson’s Law?

A common example is a one-hour meeting that only needs 20 minutes. Because the meeting is scheduled for an hour, the discussion expands until the full hour is used.

Another example is a product feature that grows because the team has extra time before release.

How does Parkinson’s Law affect product teams?

Parkinson’s Law can make product teams slower and less focused. Discovery can continue without a decision, features can become larger than necessary, meetings can expand, and roadmaps can fill with low-priority work.

Is Parkinson’s Law true?

Parkinson’s Law began as a satirical observation, not a scientific law. However, it describes a common pattern in work, planning, and organizations. Many teams experience some version of it when deadlines, scope, or definitions of done are unclear.

Is Parkinson’s Law good or bad?

Parkinson’s Law can be useful when teams use it to create focus. A short, realistic deadline can help people prioritize and avoid unnecessary work.

It becomes harmful when it leads to rushed work, artificial pressure, poor quality, or a culture where people are always busy but not effective.

How do you overcome Parkinson’s Law?

You can reduce Parkinson’s Law by setting clear deadlines, using timeboxes, defining what done means, cutting scope before extending time, and measuring outcomes instead of effort.

What is the difference between Parkinson’s Law and the Law of Triviality?

Parkinson’s Law says work expands to fill the available time.

The Law of Triviality says people spend too much time on minor issues because they are easier to understand and discuss.

Both can waste time, but they describe different patterns.

What is Parkinson’s Law in project management?

In project management, Parkinson’s Law means projects often expand to use the full available timeline and budget. This can happen through extra scope, delayed decisions, unnecessary meetings, or over-polishing.

Project managers can reduce it by creating clear milestones, limiting scope, defining done, and making trade-offs explicit.

Summary

Parkinson’s Law states that work expands to fill the time available for its completion.

For product teams, this can show up as longer meetings, overgrown roadmaps, delayed decisions, and features that become larger than necessary.

The solution is not to rush. The solution is to create better constraints: clear deadlines, smaller scopes, timeboxed work, decision points, and a shared understanding of what done means.