Your digital team needs to act like a startup

A digital team does not become startup-like because it has a new workspace, job titles, or delivery process. The useful difference is authority.

In one enterprise program I worked on, a digital team got a new leader, workspace, and way of working. Steering committees kept the material product decisions. The setup changed, but the team still could not choose what to build or stop work that was not helping customers.

They copied the startup setup and kept the old approval model.

Copy the decision loop

A corporate team cannot copy a founder's personal risk or a startup's funding model. It can copy a smaller decision loop: fund a defined problem, review evidence at agreed points, and stop or expand the work based on what changed for customers.

Small teams often change direction faster because fewer approvals sit between evidence and a release. Count the approvals in your own flow. Keep the ones that change risk, compliance, or customer value. Remove the ones that only repeat an earlier decision.

Give the team a clear boundary inside which it can act while remaining accountable to the organization.

Three kinds of authority

Decide what to build

Give the team a customer problem and an outcome, not a feature list.

The team should own the evidence, propose the trade-offs, and choose the next product change. Risk, legal, operations, and technology still need explicit decision rights where their accountability applies. The test is whether everyone knows who decides.

If every feature returns to a steering committee for approval, the team is still an order taker. Calling it Product does not change that.

Say no

Every stakeholder request can be important. They still cannot all be first.

A team needs the authority to reject a request that does not support the agreed outcome. “Not now” should come with the trade-off: which customer result would move later, what evidence supports the request, and when the team will review it again.

Without that authority, the roadmap becomes a list of promises rather than a product decision.

Be wrong within a boundary

Authority to be wrong does not mean ignoring security, regulation, budgets, or production risk. It means the team can test a reversible assumption, inspect the result, and stop when the evidence is weak.

Agree on the limits before the test. Name which actions need escalation, how much money or customer exposure is allowed, what will be measured, and when the decision returns for review.

If a reasonable test fails and the organization punishes the team for running it, the next team will avoid learning. It will ask for more approval and build what stakeholders already requested.

Measure outcomes and delivery

Enterprise teams often measure delivery more closely than outcomes. Dates, scope, incidents, and budgets matter, but they do not show whether the product helped a customer.

Keep delivery controls where risk requires them. Also give the product team a customer outcome it owns and enough authority to change the plan when evidence changes.

Ask two sets of questions:

• Did we stay within the agreed safety, budget, and operational limits?
• Did customer behavior or the business result move in the intended direction?

A team that improves the outcome while changing the original feature plan may be doing its job well. A team that ships every promised feature without changing the outcome is not finished.

Change the incentives around the team

In my experience, this model usually stops at middle management because the incentives still reward predictable delivery and low incident counts.

That response is rational. A manager asked to support experiments while being judged only on deadlines and incidents will reduce uncertainty. Change those measures before asking for more product risk.

Funding matters too. Give the team enough time and budget to test the problem, then use an agreed evidence review to stop, adjust, or expand the work. An annual budget with a fixed feature list leaves little room to follow what the team learns.

What it looks like when authority moves

In another program I worked on, the team could ship within agreed boundaries without returning to a steering committee for every release. It released a small first version, removed a feature that was not working, and used customer behavior to choose the next change.

Engagement improved. The useful lesson was the decision loop, not a comparison with another company. The team had enough authority to act on evidence and enough accountability to explain what happened.

The people were capable in both programs. The difference was what the organization allowed them to decide.

Run a one-quarter test

Are you willing to let a team make a product decision you disagree with?

Pick one product area for the next quarter. Name the decisions the team can make without approval, the risks that still need escalation, and the customer outcome it owns.

Review the evidence at the agreed point. If every material decision still returns to the steering committee, the authority has not moved.