Scope Creep Isn't an Effort Problem. The Stalled Migration Shipped When Someone Could Say 'Later.'

When I joined Tallo, the project to move its job pages out of WordPress and into the product was already underway, and it was stuck. Every conversation surfaced one more thing the new page should do before launch, and the finish line kept sliding to make room for it. The team was working hard. The work just wasn't converging.

The new job pages went live on March 3, 2026. The engineers who shipped them were the same engineers who'd been stuck, and they'd been capable the whole time. What changed was that somebody finally had the standing to say "not in version one," and to keep saying it until the date arrived.

That's what scope creep looks like from the inside, and it's why the usual fixes for a slipping project – push harder, add people, write a better plan – so rarely touch it.

The migration was Tallo's decision, and it was the right one

The migration wasn't my idea. Tallo, a career platform owned by Stride, had decided to move its job pages into the product before I got there. Consultants have a habit of arriving after the hard decisions are made and taking credit for them, and this one belonged to Tallo.

The reasoning was sound. Tallo's career starters – 18-to-20-year-olds who aren't in college and are looking for their first real job – mostly found Tallo through Google and landed on a job page. But those pages lived in WordPress, separate from the actual product. A visitor arrived, read a job description they could have found on Indeed, and left, and almost none of them came back. For most career starters, that single static page was Tallo. If the job page is where the people are, the job page is where the product needs to be.

So the strategy was settled. The project just couldn't finish.

Scope creep is common enough that it can't be a talent problem

Every stakeholder conversation added one requirement to v1, and each one sounded reasonable on its own. That's the trap. Nobody proposes a bad idea in a scope meeting. They propose a good idea at the wrong time, and with nobody positioned to say "good idea, later," it goes into the launch.

If this only happened to weak teams, you'd fix it by hiring a stronger one. It doesn't. In PMI's 2018 Pulse of the Profession, 52% of projects completed in the prior year experienced scope creep or uncontrolled changes to scope, up from 43% five years earlier. Even the organizations PMI classed as champions saw it on about a third of their projects, according to the full report, against 69% for underperformers.

Software looks about the same. Harness surveyed more than 650 engineering leaders for its 2025 engineering report, and 54% said they'd seen average scope creep above 20% across their last 12 sprint cycles. One in four said more than 70% of their requirements didn't have clearly defined acceptance criteria, and when nobody has written down what done looks like, it's very easy for done to keep moving.

Numbers like that describe a structural problem, and the structure I see most often isn't about effort or talent. It's about authority. Somebody has to hold the right to say "not in version one" – or at least feel like they hold it – and on a lot of projects, nobody does. Everyone can add. Nobody can subtract.

What got it over the line

I'm a product strategist, and Tallo didn't bring me in to run a migration. But the fastest way to create value was to get this project shipped, so alongside designing features, I stepped in as the project manager. The fix was unglamorous.

We cut the launch to what the page needed on day one. Not what it would eventually need, and not what would make it impressive, but what it needed to replace the WordPress page and work.

Everything we cut got a home. It went onto the roadmap, where it could be sequenced on its merits instead of jammed into v1. This is the part teams skip, and it's the part that makes cutting possible. People will let go of a requirement they care about if they can see where it went. They won't let it go into a void.

We set a cutover date and held it. Holding it is the part that matters, because a date you don't hold is just a wish with a calendar entry. A held date also gives every new "before launch" idea a ready answer, which is that it goes on the roadmap with everything else.

Someone owned the word "later." That was me, for this project, but it doesn't need to be a consultant. It needs to be one named person whom everyone recognizes as allowed to say it, and who'll keep saying it when the request comes from someone senior.

None of those four is a new idea. What made them work was having all four at once. A smaller launch with no home for the cuts turns into a fight about every cut, a date with no owner moves the first time someone important asks for one more thing, and an owner with no date has nothing to point to.

Owning the page made the features possible

A migration by itself is plumbing. Moving the same job description onto a different stack gives nobody a reason to care. The point of owning the page in the product was that the team could build things WordPress never could.

The first was a Job Scorecard that rated each job on pay growth and job security, with a plain-language read of each score and a link explaining exactly how it was calculated. It has since grown into the Career Scorecard, with job recommendations built on the same data sitting right on the page. None of that would have had anywhere to live if the migration were still stuck in its scope conversation – and that's the real cost of a stalled project: everything queued up behind it stalls too.

What happened after cutover

We compared the old WordPress pages with the rebuilt product pages over the 90 days after cutover, and every number we cared about moved the right way. Traffic grew substantially. Apply clicks grew faster than traffic, so the apply rate went up, too. And clicks into the rest of Tallo – the thing the old pages almost never produced – grew faster still.

I don't credit any single feature for that. The rebuild changed design, speed, page structure, and features all at once, and more traffic brings its own dynamics, which is why we watched rates and not just raw clicks. The lift belongs to the project. What I can say is that a bigger share of a bigger audience chose to act, and the job page stopped being a dead end and started being a way into Tallo. The full write-up is in the case study.

If your project keeps slipping

When a project stalls, the instinct is to look at the people doing the work. Are they fast enough, senior enough, focused enough? Sometimes that's the right question. Most of the time I've found it isn't, and the team that's stuck is the same team that will ship once the decision-making around it gets fixed.

So before adding effort, I'd ask four questions. What does this need on day one, and only day one? Where does everything else go, and can the people who asked for it see that it's there? What's the date, and who's defending it? And who's allowed to say "later"?

If the problem is too many projects at once rather than one that won't finish, that's a different kind of math. But for the single project that keeps slipping, the last question is usually the one that matters. If you can't name the person who's allowed to say "later," that's probably why the date keeps moving.