So What Should We Do Now: How to Switch to “Execution Management”

When I worked as a development manager at a startup,

the thing I repeated the most was “making plans”.

Business schedules came first,

development plans were made to fit those schedules,

and from then on, it was a structure of struggling every day to reach the goals.

But at some point, something strange starts to happen.

The team stops building the product and

starts becoming optimized for making excuses to keep the plan.

1. “Documents explaining why the schedule was delayed”
2. “Post-mortem reports saying it couldn't be helped due to too many risks”
3. “Re-planning the plan to make up for it next week”

In the end, the result is similar.

The schedule was met, but a product no one wants comes out.

The Problem Is Not the ‘Plan’, But the ‘Absence of Intent’

Plans are necessary.

But plans cannot replace execution.

Problems that occur during execution

cannot all be predicted at the planning stage.

But the bigger problem lies elsewhere.

When you start running solely based on the schedule,

the team's interest shifts from “What should we build” to

**“By when must we finish”**.

From this moment, the development team and the business team

stop running towards the same goal and

start colliding with different orientations.

1. Business wants “what the customer needs”
2. Development wants “to meet the schedule”

Neither side is wrong.

It's just that the standards they look at have changed.

And in teams where only the schedule remains,

misunderstandings eventually pile up.

1. “The dev team has no business understanding”
2. “The business team just doesn't know development”

Actually, both are only partially true, but the core is this.

We only agreed on the schedule,

we never agreed on the intent.

The Development Team Cannot Make a Product That Satisfies the Market “Alone”

One thing must be made clear here.

It is difficult for the development team

to read the market, analyze customer needs,

and derive the “correct product” on their own.

And the moment you shift that responsibility to the dev team,

they choose one of two things.

1. Become a team that doesn't listen (Overturning product planning)
2. Become a team that just does what they are told without thinking (Only meeting the schedule)

Both fail.

What's important in a startup

is not “Let's make the dev team build a product that satisfies the market,”

but for the dev team to understand the business intent and

become a team that turns that intent into the best implementation.

Business takes responsibility for the market,

development takes responsibility for implementation,

but **a structure where the intent is aligned as one** is needed.

So What Should We Do: 5 Steps of Execution Management (Intent-Centric Version)

1) Treat Plans as ‘Hypotheses’, Not ‘Contracts’

Many teams run plans like final versions.

But a plan is a hypothesis.

1. A plan is an estimate that “if we do this, it will work”
2. Execution is the process of proving “actually doing it showed it was right/wrong”

The moment you operate a plan like a contract,

the team starts making distorted decisions to meet the plan.

✅ Practical Application

1. Separate **“Fixed Schedule” and “Variable Scope”** on the timeline
2. Keep the milestones, but leave the implementation scope adjustable

2) Set Goals Based on ‘Intent’, Not ‘Schedule’

Goals in schedule-centric organizations are usually like this.

1. Login feature complete
2. Dashboard 1st draft complete
3. Payment API integration complete

This is a task list, not a purpose.

Intent-centric goals look like this.

1. “Make sure signup conversion doesn't break”
2. “Make the user move immediately to the next action”
3. “Do not block the flow where payment occurs”

In other words, the goal becomes not the feature,

but implementing the flow the business wants.

✅ Practical Application

Change the sprint goal sentence like this

1. ❌ “Develop Feature A”
2. ✅ “Implement Business Intent A, and verify success criteria”

Here, the success criteria doesn't have to be the market,

but **the business intent criteria (conversion, flow, data, operational feasibility).**

3) Don't Find Risks in Meetings, Reveal Them Quickly in Execution

Execution management is ultimately a battle against risk.

The moment you look for risks in a meeting,

risk becomes an argument, and the schedule becomes a defense.

Risks are only seen when you get your hands dirty.

✅ Practical Application: The 48-Hour Rule

If there is a “vaguely difficult” task,

do the work to just verify the risk within 48 hours first.

1. API Integration → Try connecting just minimum call/auth
2. Performance Worries → Check bottlenecks with dummy data
3. Screen Ambiguity → Check reaction with prototype

Doing this becomes grounds for decision-making,

not an “excuse”.

4) Manage “Blocked Points and Decisions”, Not “% Progress”

The phrase most used by plan-centric teams:

“We are currently 70% done.”

The reason this phrase is dangerous is that

hell might exist in the remaining 30%.

Execution-centric management looks at it like this.

1. Where is the blocked point right now?
2. What decision is needed?
3. Who needs to decide and when?

✅ Practical Application: Daily 10-Minute Checklist

1. What is the one thing blocked today?
2. What decision is needed to break through it?
3. Who is the person to decide today?

Sharing just these three

drastically reduces misunderstandings between business and dev teams.

5) Keep the Schedule, But Do Not Keep It While “Damaging the Intent”

If you rush the schedule,

abandon the intent, and just fill in the features, the result is this.

An unwanted product fitted to the schedule

What's more fatal in a startup is

not a product coming out late,

but a product that came out fast but is different from the business intent.

✅ Practical Application: Priorities When the Schedule Collapses

1. Scope Adjustment (Maintain Intent)
2. Implementation Simplification (Maintain Intent)
3. Launch
4. Schedule Change

In other words, the schedule is adjustable,

but the intent must not be broken.

Conclusion: Not “Schedule”, But “Intent” Binds the Team Together

If we focus on the plan,

we can become a “team that keeps the schedule”.

But if we focus on execution,

we become a “team that implements business intent”.

And for business and dev teams to move as one team in a startup,

what is ultimately needed is this.

Not the schedule, but

Execution Management Aligned with Intent

If you run only with the schedule,

business and development create constant misunderstandings

while having different goals.

Conversely, if you share the intent,

even if the schedule shakes a little,

the confidence that you are looking at the same goal remains.

That is what keeps the team from collapsing.