Have you ever observed that your product development often meets the deadline, but rarely leaves you with much time left? Or that software development tasks often take more time than estimated and rarely less?
There is a name for that: Parkinson’s Law. It describes the phenomenon where work expands to fill the time available, or even longer in some cases. You can use the knowledge of this organizational and psychological “law” to optimize your processes and product success.
In this article, you will learn what Parkinson’s Law is and its implications for product development.
Parkinson’s Law says that work expands to fill the time that you budget for its completion. Cyril Northcote Parkinson first coined the concept about 70 years ago.
Specifically, Parkinson showed how a bureaucratic organization grows unrelated to its actual workload because people create more work for each other. Originally, his finding was that a public administration will always grow, independent of its workload.
He found this to be true based on the Law of Multiplication of Subordinates, which means that an overworked person is incentivized to multiply subordinates instead of sharing their work with peers. And second, The Law of Multiplication of Work, which means that people will create work for each other by complicating it. This leads to the impression that the employees are overworked and therefore more people are being hired.
Parkinson’s Law is now known as the productivity law that states people will spend all the time available for a task, regardless of its actual size or complexity. The task will be either completed on time, or delayed, but it won’t be completed before the deadline.
If you know how people work and consider the tendency for tasks to take as much time as you’re allotting to them, you can mitigate the risk of becoming inefficient. Knowing about it is already an advantage.
The effect can show especially in product development timelines and processes. Let’s say you’re in the early phase of a new product and want to spend some time on initial product discovery, as well as creating a vision and a strategy. If you don’t restrict the time to spend on this, it can take you months to come up with a direction.
So for the early phase of product development, make sure to define what is really necessary to get started building the product. How much market research and user interviews do you really need? When is it time to create something that you can publish and learn from actual user behavior? By defining this upfront, you can avoid getting stuck.
For big decisions, you can also observe this. Instead of tackling a big strategic decision, a product team might just continue on their current path because there is no deadline to change something. Initiatives that tackle the big topic, might never lead to any results, because you can always do more research.
A helpful strategy might be to do a workshop format like a design sprint. This is a process, where a cross-functional team builds and tests a prototype in just five days. There are also versions of this workshop method that do it in four days or less.
Then there’s the product development process. Parkinson’s Law can play a role in many small aspects of it. Teams that use estimation techniques to plan their development work, be it with T-Shirt sizes, story points, or hours/days, need to be aware of Parkinson’s law. By doing an estimation, they might unconsciously allot a certain amount of time to the task and then will most likely need all of that time.
My advice would be to use estimations as a way to facilitate the conversation about the task and its logical or technical risks and challenges and not do estimations to define how long the development work will take. With estimations, it’s better to estimate complexity and not time.
You can also incentivize or encourage early completion of tasks. As a product manager, make sure to keep track of the progress and celebrate progress authentically. Organizations can also provide feedback loops to developers (or whoever estimates something) regarding estimation accuracy, to cultivate an environment where processes are continuously improved and progress is celebrated.
Another important aspect that helps counteract Parkinson’s Law, is the “definition of done.” It should be clear, when a task is complete, to avoid uncertainty and lingering. This applies to tasks and stories or epics. And it’s also helpful to set clear goals for a sprint, for a project or for any initiative, so it’s easier to determine when you’re done, if the thing is complete and also, if it is successful.
First of all, you should set strategic constraints regarding your value proposition, your target group, and the problems you want to solve with your product. If you don’t restrict yourself with these basics, you won’t know if you’re successful.
When you’re improving your product, make sure you know which outcome to target. Focus on one opportunity at a time, building one solution to a problem at a time. Be clear on what you’re working on.
Working with OKRs is a popular way to set clear objectives, align teams, and track the progress toward your high-level goals.
Most digital product managers work in a more or less agile environment, and some also have the role of the product owner, according to scrum. There are some aspects of scrum that incorporate constraints and help use Parkinson’s Law to their advantage.
In scrum, you divide the work into windows of time, called sprints. When a sprint starts, the team commits to its scope. This means you need to be intentional about the scale of the scope. If the tasks are too small, you’ll create inefficiencies and if they are too large, you’ll breed resentment.
My advice for productive sprints is to be intentional with sprint planning. In the sprint planning meeting and beyond, you should foster a supportive team culture with psychological safety so that every team member feels safe to voice their concerns.
Another helpful aspect of sprints is the sprint goal. If you create it together with the team, while in alignment with the overall product strategy, it helps the team decide which tasks to tackle, and it helps them focus and get things done.
In the last 11 years in my work as a digital product manager and as an organizer of technology conferences, I have often witnessed the effects of Parkinson’s Law. These are the most common problems that arise:
Parkinson’s Law is the concept that describes how work expands to fill the time available. It plays a big role in the productivity of product teams, especially in areas where you’re working with new and innovative technology.
When you understand Parkinson’s Law, you can use this knowledge to avoid inefficiencies and optimize your product development processes. You can counteract it by setting clear objectives, being clear about what “done” means, creating constraints, and fostering frequent and open communication.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
