Gryphin Logo
Gryphin.dev
Back to blogCase Study

Gryphin.dev Board That Saved Our Product Launch

We were 3 weeks from launch and nothing was on track. Here's how we pulled it together.

SK
Sarah Kim
Senior Product Manager
Nov 1, 2024
6 min read

Three weeks before our biggest product launch of the year, I sat in a status meeting where every team reported they were "on track." Then the CEO asked when we could demo the complete feature, and the room went silent.

Turns out "on track" meant different things to different people. Engineering was on track with their tasks. Design was on track with theirs. Marketing had a launch plan. But no one had stitched it together. No one could actually say what "done" looked like or when we'd get there.

This is the story of the three weeks that followed.

Day 1: The Reckoning

After that meeting, I pulled the leads from eng, design, marketing, and customer success into a room. "We need to know exactly where we are. Not 'on track.' Exactly where."

We spent four hours mapping every task left to do. Not epics. Not themes. Tasks. Specific, completable chunks of work.

127

items remaining

Then we estimated each one. Not story points. Time. "This will take 4 hours." "This needs 2 days." Estimates are always wrong, but at least they're specific enough to be wrong in useful ways.

The math was ugly. Even with optimistic estimates, we had about 5 weeks of work and 3 weeks of time.

Day 2: The Board

We created a dedicated launch board in Gryphin. Not our normal project board—a separate board just for this launch, with its own columns:

Blocked Ready In Progress Review Done

Everything that needed to happen before launch went on this board. No exceptions. If it wasn't on the board, it wasn't part of the launch.

We also added WIP limits. No more than 15 items in progress at once. This forced people to finish things instead of starting new things.

Week 1: Cut and Prioritize

First decision: what could we cut? We had 5 weeks of work and 3 weeks of time. Something had to give.

We went through every card and asked: "If we ship without this, does the launch fail?" Not "would this be nice to have." Fail. Hard requirement vs. soft requirement.

40

Nice-to-haves cut

20

Post-launch items

67

Must-do items

Still tight, but possible.

We reordered everything by dependency. What unblocked what. Some things had to happen first or everything downstream would stall. Those went to the top.

Week 2: The Grind

Every morning at 9am, we had a 15-minute sync. Not status updates—blockers and handoffs. "I'll finish X by noon, then Y is unblocked for someone else." "I need design input on Z before I can proceed."

The board became the single source of truth. When someone asked "how are we doing," we pointed at the board.

Two things saved us

Visible blockers: Every blocked item had a note: what's blocking it and who needs to unblock it. If you were tagged as a blocker, you knew it. Social pressure is real.

Real-time presence: We could see when people were looking at the board, what they were looking at. This meant we could coordinate without meetings. "I see you're looking at the payments card—I just pushed updates, should be unblocked now."

Week 3: The Sprint

Going into the final week, we had 23 items left. Still a lot, but the critical path was clear.

We added a "shipping today" swimlane—a horizontal section at the top for items that absolutely had to close that day. Maximum 3 items per day. This created focus amid the chaos.

The final three days were intense. People were tired. But something interesting happened: the visible progress was motivating. Every card that moved to Done felt like a win. The Done column grew. The remaining work shrank.

Launch day: we shipped.

Not everything we originally planned, but everything that mattered.

What I Learned

"On track" means nothing.

Individual teams can be on track while the whole project is heading for a cliff. Integrated visibility is the only way to actually know status.

Cutting scope is a feature, not a failure.

We launched with 60% of the original scope. Nobody noticed or cared. The 40% we cut? We shipped most of it the following month.

WIP limits force completion.

When you can't start new things, you have to finish old things. The "I'll just start one more thing" instinct is strong, and it's usually wrong.

Visual progress matters psychologically.

Watching cards move through columns, watching the Done column grow—it's motivating in a way that task lists aren't.


Would I Do It Again?

Hopefully I won't need to—the crisis mode shouldn't become the norm. But the techniques from that launch have influenced how I run projects now:

  • Dedicated boards for major initiatives
  • WIP limits by default, not just in emergencies
  • Regular scope review (what can we cut?)
  • Dependency mapping before things get urgent

The launch saved itself not because we worked harder (though we did), but because we got clear. One board. Everything visible. No hiding. No ambiguity. Clarity, it turns out, is a prerequisite for execution.

#product-launch#project-management#crisis#kanban#case-study
Share this article
SK
Written by
Sarah Kim
Senior Product Manager

Sarah has shipped products at companies ranging from 10 to 10,000 people. She's seen launches go spectacularly wrong and occasionally go right.

Ready to work smarter?

Join 5 million+ teams using Gryphin to get more done.