[February 2026] 🤘 How we fixed a stuck project (+2 updates)

Hey it’s Mica,

Have you ever had a project that everyone agreed was worth trying? Multiple people had ideas for how to approach it. It came up in meetings. Everyone nodded along. And then nothing happened.

We had one of those. Months of agreement, zero movement. Then we gave it to one person. She scoped it down, set a one-week deadline, and shipped it.

If those steps sound familiar, they're the same tactics I shared in last month's newsletter. The playbook worked. But the project also taught us two things that weren't on the original list.

One is about what happens before a project starts. The other is about what happens after it's running.

Let's dive in. (product updates at the bottom as usual)

-Mica
Head of Operations

☝️ Put one name on it (that's it)

Every team has a version of this: an important project that lives in "good idea" limbo because multiple people are involved but nobody owns it.

For us, the project was figuring out how AI could help our customer support team. We'd been circling it for months. Then we gave it to Sampada (our product solutions expert). She scoped it to chat only, set a one-week deadline, and started with internal users.

It went live in a week.

One person with a narrow scope and the authority to make calls. That's all it took.

The ownership test. Before your next project kicks off, run through these:

• Can you name one person? If this stalls in two weeks, whose job is it to fix it? If you think of multiple people, or nobody, you don't have an owner yet.

• Do they have authority to match? An owner who needs permission for every decision isn't an owner. They're a coordinator with a title.

• Is the scope narrow enough to own? "Improve our onboarding" is a goal, not a project. "Get the first 10 customers through the new onboarding flow by March 15" is something one person can actually drive.

• Is there a built-in checkpoint? Ownership without a review date is just delegation and hope. Set a check-in from the start.

🔨 Learn while you build

The plan you start with is never the plan that finishes. The question is whether you're shaping it as you go or discovering what you missed after it's over.

Our AI chat project was built to reduce support response times. It did. But the work also exposed gaps in our documentation and revealed our support platform could do more than we'd realized. We went looking for one thing and came back with three.

Last month's advice was let it bake before you optimize. This is the other side: once you have signal, act on it. Don't lock in a plan and execute blindly. The best projects are shaped by what the work reveals, not just what's in the plan.

But don't chase everything you notice. Real signal shows up more than once, and the upside is concrete: time saved, a cost cut, a better result. Distraction is excitement without evidence.

Three habits for learning while you build:

• Ask one question at every check-in: "What surprised us today?" Not this week. Today. Weekly reflection is already a post-mortem. You're not asking the team to change direction. You're asking them to notice, and write it down while it's fresh.

• Follow the repeat. When the same unexpected thing comes up twice, stop and spend 15 minutes investigating before you move on. Most signals either confirm themselves quickly or dissolve on contact.

• One sentence before each iteration. "Based on what we learned, here's what changes." Write it down. Over time, this becomes your real project story. You'll see the decisions you forgot you made.