What Is Launching in the Next 30, 60, and 90 Days?

It sounds like a simple question:

What is launching in the next 30, 60, or 90 days?

In many organizations, the answer is surprisingly difficult to find.

One team has a development roadmap. Another has a marketing plan. Pricing is working from a spreadsheet. Operations has a checklist. Important decisions are being made in meetings, email threads, and side conversations.

Every team may be actively working.

But no one has a complete view of the launch.

I encountered this challenge while working with product-development and commercialization processes involving multiple functions.

A product could be marked as nearly complete by the development team while essential commercial work had not yet started.

Pricing might still be pending. Website requirements might be unclear. Catalog updates might not have an owner. Regulatory approval could be in progress. Marketing teams might not know whether the date was firm enough to begin execution.

Each function had its own version of progress.

The launch itself did not.

This is where organizations often respond by creating another tracker.

But a tracker is only useful when the underlying operating rules are clear.

Before building a dashboard, the organization must agree on questions such as:

  • What qualifies as a launch?

  • Which milestones determine readiness?

  • Who owns the overall launch date?

  • What dependencies can change that date?

  • What does red, yellow, or green actually mean?

  • Who has authority to resolve a blocker?

  • Which system contains the official status?

Without those decisions, a dashboard simply creates a cleaner view of inconsistent information.

The strongest launch systems connect three different kinds of progress.

Product readiness

Is the product built, reviewed, approved, and technically ready?

Commercial readiness

Are pricing, positioning, merchandising, sales enablement, communications, and distribution prepared?

Operational readiness

Can the organization support customers, maintain the product, report on performance, and manage issues after launch?

A launch is only as ready as the least prepared critical dependency.

That is why reporting should not focus exclusively on whether individual tasks are complete.

It should help leaders understand:

  • What is approaching

  • What is blocked

  • What has changed

  • Which decisions are overdue

  • Where the organization is depending on an assumption

  • What requires intervention now

A good 30-, 60-, and 90-day view does more than report dates.

It creates a planning horizon.

At 90 days, teams should be validating scope, ownership, and major dependencies.

At 60 days, commercial and operational work should be visibly underway.

At 30 days, unresolved issues should be explicit, owned, and actively managed.

The precise timing will vary by organization and product, but the principle remains the same:

Visibility must arrive early enough to change the outcome.

A launch report that explains why something failed after the date has passed is not an operating mechanism.

It is an autopsy.

The goal is not to create perfect certainty.

The goal is to surface uncertainty while there is still time to act.

Previous
Previous

Recovering Performance Starts With Diagnosing the System

Next
Next

A Good SOP Should Make the Work Easier