The Importance of Working Agreements - ProductFTW #60

Working agreements are one of the most underrated tools for improving collaboration between product and technology teams. They establish clear expectations, reduce friction, and create a shared understanding of how work gets done. A strong working agreement ensures that teams speak the same language, define success in the same way, and know how to communicate effectively.

I have seen firsthand how misalignment between product and technology teams can slow down progress. One of the most common issues is when there is no shared definition of done. Product may think a feature is complete when it has been developed, but engineering may still need to conduct performance testing, deploy it to production, or clean up technical debt. Without an agreed-upon definition of done, teams constantly find themselves at odds over whether work is actually finished.

Similarly, a definition of ready is just as important. If engineering starts working on a feature before product requirements, designs, or technical specifications are fully fleshed out, it can lead to delays, rework, and unnecessary back-and-forth. When teams agree on what “ready” means before work begins, they minimize blockers and set themselves up for success.

But working agreements go beyond defining when work starts and ends. They shape how teams communicate, collaborate, and operate together. They ensure that teams are aligned not just on what they are doing, but how they are doing it.

Why Working Agreements Matter

A well-crafted working agreement helps teams:

• Reduce confusion by establishing clear expectations for how work is done.
• Improve efficiency by removing unnecessary friction in decision-making.
• Create transparency around priorities, dependencies, and progress.
• Align teams by ensuring everyone is working toward the same goals.

Without a working agreement, teams default to their own assumptions about how things should be done. That might work in a small startup with just a few people, but as teams grow, misalignment starts to create delays, misunderstandings, and frustration.

One of the biggest benefits I have seen from implementing a working agreement is having a common language. Every company, product, and industry has its own terminology, and if teams are not aligned on what certain terms mean, miscommunication becomes a regular occurrence.

For example, I have worked at companies where “customers” meant end users and others where “customers” meant business partners. If these definitions are not clarified upfront, teams end up talking past each other. Creating a shared dictionary of key terms as part of a working agreement helps eliminate unnecessary confusion.

Defining “Ready” and “Done”

One of the most practical ways to use a working agreement is by establishing clear definitions of ready and done.

Definition of Ready: When is a task ready to be worked on?

• Product requirements are clearly documented.
• Designs are finalized and approved.
• Error states and edge cases are defined.
• Backend dependencies are identified and documented.
• No major unanswered questions remain.

If any of these are missing, the work is not ready to be pulled into development. This prevents teams from starting work on incomplete tasks, only to hit roadblocks that could have been avoided.

Definition of Done: When is a task considered complete?

• The feature is fully developed and has passed all functional tests.
• Performance and security checks have been conducted.
• Documentation has been updated.
• The feature has been successfully deployed to production.
• Any necessary monitoring or alerts have been set up.

A common mistake is assuming that work is done as soon as the code is written. A proper definition of done ensures that teams do not just build something, but they deliver a complete and functioning product.

Standardizing Communication and Collaboration

Another critical aspect of a working agreement is defining how teams will communicate and document work.

• Where is documentation stored? Product specs might live in a product management tool, while technical documentation may be in GitHub. Teams need to know where to find key information.
• How are questions asked? Is Slack the primary tool for quick discussions? Should certain topics be addressed in a weekly meeting?
• When should teams use synchronous vs. asynchronous communication? Urgent topics might need a live meeting, while non-urgent questions should be documented for review later.

I have noticed that communication preferences vary widely based on past experiences. Someone coming from an enterprise background might default to email, while a startup veteran may expect everything to happen in Slack. Without setting expectations, people may unintentionally frustrate each other just by using the wrong communication channel.

I have also worked with teams where Slack threads were a mess, and important information got buried. A simple guideline like “keep Slack conversations in threads and summarize decisions in a shared document” can drastically improve clarity and prevent miscommunication.

Meeting Culture and Remote Work Norms

Meetings are another area where working agreements help eliminate unspoken expectations and cultural differences.

• Should cameras be on during meetings? Some teams expect video to be on at all times, while others leave it optional.
• What is considered “on time” for a meeting? In some companies, people routinely show up 5-10 minutes late, while others expect meetings to start at the exact scheduled time.
• Is multitasking acceptable? Some teams have a strong expectation that attendees are fully present, while others assume that people will work on other tasks during meetings.

At one company I worked at, being late was normal. The campus was so large that people were constantly walking between buildings, and meetings were often back-to-back. It was understood that people would arrive 10-15 minutes late. But in a remote-first company, that same habit would be seen as disrespectful.

A simple conversation about what is considered acceptable prevents misunderstandings and frustration. If a company values full engagement in meetings, then establishing that, for example, “no multitasking unless it is directly related to the discussion” can help set the right expectations.

Making Working Agreements a Living Document

A working agreement is not something you create once and forget about. It should evolve as the team grows, the product changes, and new challenges emerge.

I have found it helpful to review working agreements quarterly and ask:

• Are there new challenges that should be addressed?
• Are there areas where communication is breaking down?
• Are teams following the agreement, or does it need adjustments?

By keeping the document up to date, teams stay aligned as they scale.

Setting Teams Up for Success

At its core, a working agreement is about helping teams work efficiently with as little friction as possible. It is not about creating rules for the sake of rules. It is about ensuring that everyone has a shared understanding of how they work together.

Too often, teams assume that alignment happens naturally, but it does not. Small misunderstandings turn into bottlenecks, simple miscommunications cause unnecessary frustration, and vague expectations lead to wasted time.

Taking the time to establish a clear working agreement ensures that teams are set up for success, expectations are clear, and collaboration is smooth. When done right, it is one of the most valuable tools a company can use to create a high-functioning and engaged team.

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.

Part of the Product Requirements Field Guide — ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.