Why Teams Need Standards, Not More Meetings

A little reflection on digital product work, shared decision-making, and the hidden cost of ambiguity.

The quick version

Most product teams do not need more meetings. They need fewer repeated decisions.

Standards help teams move with less friction because they make expectations visible.

The goal is not control. The goal is clearer, more humane operating conditions.

I’ve been thinking a lot about why some digital product teams feel heavier than they should.

Not because people are lazy. Not because teams don’t care. Not because no one knows what they’re doing.

Usually, it’s the opposite.

Smart people are trying very hard to do good work inside systems that make the work harder than it needs to be.

And when things get messy, the instinct is almost always the same: let’s have a meeting.

• A kickoff meeting.

• A sync meeting.

• A review meeting.

• A follow-up meeting.

• A working session before the actual working session.

Sometimes meetings are necessary. Product work is collaborative by nature.

People need space to talk through tradeoffs, constraints, risks, timelines, user needs, technical realities, and business goals.

But I don’t think most teams are suffering because they haven’t talked enough.

I think they are often suffering because they do not have enough shared standards.

The hidden work underneath the work

On a digital product team, there is the visible work:

• the roadmap

• the designs

• the tickets

• the launch plan

• the dashboard

• the stakeholder update

Then there is the invisible work underneath all of that.

That invisible work is where a lot of cognitive load lives.

The questions that quietly drain teams

What do we call this thing?

Who owns it?

Is this a one-off solution or a reusable pattern?

Does this need review?

What does “done” mean?

Where does this information live?

Is this the source of truth?

Can another team use this later?

Are we solving the user problem, or just moving friction somewhere else?

When teams do not have shared answers to those questions, every project has to figure them out all over again.

That is exhausting.

It also makes meetings feel more important than they are, because the meeting becomes the place where all the missing structure has to be recreated in real time.

A redacted example

In one large enterprise environment, I saw a version of this play out across digital product, content, knowledge, and operational experiences.

Teams were moving quickly. They were building important things. The work touched customers, employees, internal platforms, service experiences, and the systems people relied on every day to make decisions.

But over time, small inconsistencies started to add up.

• A term meant one thing in one part of the experience and something slightly different somewhere else.

• A workflow made sense for one team but created confusion for another.

• A repository existed, but it was not always clear what was current, reusable, or owned.

• AI and automation were becoming part of the conversation, but the underlying information was not always structured, governed, or trusted enough to support those ambitions.

None of this was dramatic on its own.

That’s part of the problem.

Digital product debt often does not announce itself loudly. It shows up as friction.

• A little more rework.

• A little more clarification.

• A little more debate.

• A little more “who needs to weigh in on this?”

• A little more “didn’t we already decide that?”

The pattern

Eventually, the work starts to feel slow even when everyone is moving fast.

Meetings become a workaround

When standards are missing, meetings become the workaround.

They become the place where teams try to answer questions that probably should have had a shared answer already.

• What pattern should we use?

• Who gets to decide?

• Does this need to match the other experience?

• Is this good enough to ship?

• What happens when this changes later?

• How will we know whether it worked?

Those are reasonable questions.

But when teams have to answer them from scratch every time, the organization pays for the same ambiguity again and again.

• It pays in time.

• It pays in rework.

• It pays in inconsistent experiences.

• It pays in stakeholder fatigue.

• It pays in product teams feeling like they are always aligning, but never quite aligned.

Standards do not have to be heavy

Part of the problem is that the word standards can sound bureaucratic.

It can sound like a giant PDF. Or a governance committee. Or someone saying no from very far away.

That is not what I mean.

Good standards are not about slowing people down. They are about helping people stop reinventing the same decisions.

A useful standard says:

Here is how we usually handle this.

Here is where teams have flexibility.

Here is where consistency matters.

Here is who owns the decision.

Here is what good looks like.

Here is when something needs a deeper conversation.

That kind of standard does not replace judgment.

It protects it.

It lets teams spend energy on the decisions that actually need thought, instead of burning time on the same foundational questions over and over.

Templates are helpful. Standards do something different.

I love a good template.

But templates are not the same as standards.

Simple distinction

A template helps you complete a task.

A standard helps you make a decision.

Template	Standard
A product brief template asks for goals, users, risks, dependencies, and success measures.	A product standard helps teams understand how those things should be evaluated.
A design template organizes a screen.	An experience standard helps teams know when to use a pattern, when to break it, and what consistency means across the ecosystem.
A content template structures information.	A content standard helps teams understand what needs to be findable, reusable, governed, maintained, and trusted.

The template is the container.

The standard is the shared logic.

Most teams need both. But the second one is usually where the real leverage is.

AI makes the messy parts louder

AI has made this conversation feel more urgent to me.

Because AI does not magically fix messy systems. It often reveals them.

If an organization has five sources of truth, AI does not automatically know which one to trust.

If ownership is unclear, AI does not solve that.

If information is outdated, duplicated, inconsistent, or poorly structured, automation can make the problem bigger and faster.

The AI-readiness question

Can people trust the systems they are being asked to use?

That does not mean teams need to stop experimenting.

It means the foundations matter more than ever.

Digital products that rely on AI, automation, personalization, or self-service need clear standards around information quality, structure, governance, feedback, measurement, and accountability.

That sounds technical, but it is also deeply human.

Fewer meetings, better conversations

I’m not arguing for fewer conversations.

I’m arguing for better ones.

When teams have standards, meetings can focus on the work that actually needs people in the room.

• What tradeoff are we making?

• What risk are we accepting?

• What user problem are we prioritizing?

• What are we learning?

• What needs to change?

• Where should we be consistent, and where should we adapt?

Those are useful conversations.

But too many teams are stuck in meetings about things that should already be easier to answer.

• What do we call this?

• Where does it go?

• Who owns it?

• Is this the right pattern?

• Can we reuse this?

• What does “done” mean?

At some point...

Those are not meeting questions. They are operating model questions.

Standards are care work

This might be the part I care about most.

Standards are often framed as control.

But at their best, standards are care work.

• They care for the user, because the experience becomes clearer and more consistent.

• They care for the team, because people do not have to carry every decision in their heads.

• They care for new employees, because expectations become visible.

• They care for product managers, because prioritization and tradeoffs get easier to explain.

• They care for designers and engineers, because patterns become easier to reuse.

• They care for leaders, because quality becomes less dependent on heroics.

• They care for the organization, because good decisions become repeatable.

That matters.

Especially in large, complex, regulated, or fast-moving environments where the work cannot rely only on individual memory, informal relationships, or whoever happens to be in the meeting that day.

The better question

The goal is not to eliminate meetings.

The goal is to stop using meetings as a substitute for missing structure.

Digital product teams need space to think together. They need collaboration. They need healthy debate. They need judgment.

But they also need enough shared standards to keep the work from becoming heavier than it has to be.

• When every decision is bespoke, teams get tired.

• When every project starts from scratch, quality drifts.

• When every question needs a meeting, momentum disappears.

• When people spend all their time aligning, they have less energy left for the work that moves the product forward.

So maybe the question is not:

Do we need another meeting?

Maybe the better question is:

What decision keeps coming up because we have not created a standard for it yet?

That is where the real work probably is.