What a Grassroots Football Club Learned About Scope Expansion in Refinement Sessions

A grassroots football club app should have reached the market in three to four months. It never launched. After twelve to fourteen months of development, the budget had nearly doubled and the app store page remained empty. The client had been warned this would happen. The warnings were documented, discussed, and ignored.

The refinement sessions kept expanding the product, which is the complete opposite of what they should do.

We worked on this project from the beginning. The brief was genuinely interesting, a platform to manage finances, games, schedules, and players across multiple sports. The founders were passionate, well-funded, and deeply familiar with the problem they were trying to solve. On paper, those are good signs.

What derailed the project was not a technical failure or a bad idea. The product scope grew continuously, the founders added features in every session rather than removing them, and the iterative process we recommended was rejected at every stage. By the time development stopped, the product had consumed its entire budget without producing anything a user could download. This is what scope creep actually costs, not a lesson from a textbook, but a product that still does not exist.

The Project That Should Have Launched in Four Months

When the sports club app came to us, the proposition was clear enough. A single platform where grassroots clubs could track player availability, manage match schedules, handle basic finances, and organise across different sports. The market existed, the founders understood it, and there was funding to build something real.

Our recommendation from the start was to launch with a single sport, on a single platform, with a minimal feature set. Test the market, learn from actual users, and grow from there. This is standard practice for a reason, Agile Soft Labs, 2026 reports that founders routinely underestimate MVP development time by two to three times, and that figure holds even before scope begins to drift. Starting narrow keeps that drift manageable.

The client pushed back entirely. They did not want to launch with a single sport. They did not want to launch on a single platform first. They did not want an MVP at all. They wanted everything ready before anything went live. That position set the conditions for everything that followed, because it meant there was no natural checkpoint, no moment where real user behaviour could redirect the product before the budget ran out.

Why the Client Rejected an MVP from the Start

The rejection of an iterative approach was not casual. The founders had a clear picture in their heads of what the finished product should be, and launching anything less felt like settling. They were not wrong that their vision was coherent, the problem was that coherence in a founder's head does not translate directly into a product users will actually adopt.

We also worked with a pre-launch founder in the football industry who arrived with a colour-coded spreadsheet mapping out competitor products, with the aim of merging several of them into one. They were visibly excited. When we started asking questions about prospective users, why someone would choose an all-in-one product over specialised apps, and whether consolidation risked weakening individual features, the founder deflated. The spreadsheet had answered the wrong question. It had mapped what existed, not what users would choose.

Our job in both cases was to be honest about what would make the product succeed, not to validate the founder's enthusiasm. That honesty is uncomfortable, but it is the only thing that protects the budget and the product. Building on founder conviction alone, without user evidence, produces what we call a vanity product, shaped by preference rather than by the market.

How Refinement Sessions Became Expansion Sessions

Refinement sessions are supposed to reduce a product. The team reviews features in detail, cuts what is not essential, tightens what remains, and moves closer to something shippable. That is the function they serve in an iterative process. On the sports club app project, they did the opposite.

Every session intended to narrow the scope ended with a larger product than the one we had walked in with. Stakeholders used the sessions to introduce requirements that had never previously been mentioned, each one presented as self-evident. "Of course it needs to do this. Of course it needs to do that." The framing made every addition feel like a correction of an oversight rather than a choice to expand scope. As Simon put it: "We ended up with a bigger product at the end, which is the complete opposite of what you should have."

Each refinement session left us with a bigger product, adding requirements that had never been mentioned before.

The pattern is worth understanding because it does not feel like scope creep while it is happening. Each individual addition seems reasonable. The problem is cumulative, ten reasonable additions produce an unreasonable product. Without a formal change-control process that requires each new requirement to displace something already on the list, refinement sessions become open-ended expansion sessions, and the product keeps growing.

Agree at the start of every refinement session that the total scope cannot increase. Any new requirement must replace something already scoped, not sit alongside it. This single rule changes the dynamic of every session that follows.

The 'Of Course It Needs To' Problem

The phrase "of course it needs to" is worth paying close attention to, because it closes down negotiation before it has started. When a stakeholder says a feature is obvious, they are asserting that no argument should be needed. That is a difficult position to push back against without the conversation becoming adversarial.

On the sports club app, both founders used this framing consistently. Each new requirement was positioned as something implied by the original brief rather than something being added to it. The effect was that the product grew while the conversation stayed focused on individual features, and nobody was holding the whole picture. We were examining branches while the tree kept growing roots.

The underlying issue is that founders who are close to a problem domain genuinely do see certain features as obvious. They use the product mentally every day, they know the workflows, and they know what breaks. But that closeness also makes it hard to distinguish between "the product needs this to work" and "I personally would want this." Those are different claims. The first is a product decision. The second is a preference, and preferences are the entry point for scope creep.

When a stakeholder describes a feature as obvious or implied, ask them to specify which user need it addresses and what happens if it is not in the first release. If they cannot answer both questions, the feature belongs on a future roadmap, not the current build.

When the Founders Are the Product's Biggest Risk

Two co-founders ran the sports club app project, both of them deeply embedded in the environment the app was designed for. They already lived and worked in grassroots football. They knew the problem intimately. And that intimacy was, paradoxically, the biggest structural risk on the project.

Both founders pushed independently and consistently to add features, each convinced their additions were already implied by the brief. Neither was trying to sabotage the project, they were trying to build the product they had imagined, which is a different kind of problem. When both decision-makers are pulling in the same direction and that direction is always "more", there is no internal counterweight. The external voice, us, was the only check on expansion, and without a formal process to enforce it, that check had no teeth.

This is a specific risk profile. A product team where one stakeholder pushes to add and another pushes to cut produces natural friction that limits scope drift. A product team where both stakeholders push to add, and the agency is the only voice for restraint, needs a much more formal structure, written change requests, sign-off processes, and documented consequences for scope additions, or the restraint will not hold.

The Vanity Product Pattern Across Multiple Projects

The sports club app was not the only project where this pattern appeared. We identified the same dynamic on a fitness and wellness app, where the founder's personal conviction about the product consistently overrode data coming from research, focus groups, and surveys. In both cases, the product became shaped by the founder's preferences rather than by evidence of what users needed.

The warning signs are consistent across both projects. An excessive drive to perfect the product before launch. Rolling back sign-offs to request further changes. Prolonged decision-making that delays each build phase. These are all indicators that the product is being held to a personal standard rather than a market standard, and that the founder is building for themselves rather than for users.

We flagged this trajectory early on both projects. On the grassroots football product, we advised against overcomplicating the build and adding features beyond what the core use case required. The advice was noted and not acted on. The product became so complex that development had to stop, and we ceased working with the client. More than a year later, the product still has no marketable release, only a series of "coming soon" announcements, each pushing the date further out.

Both projects exhausted their budgets in the design and build phases without reaching a fully live product. The Standish Group CHAOS Report puts the rate of software project cancellation before completion at 31.1%. Both of these projects became part of that statistic.

What Ignoring Early Warnings Actually Costs

On the sports club app project, we warned the client early that the budget would spiral and that they risked exhausting their funding before anything launched. Those warnings were not vague, we told them specifically what the trajectory looked like if the scope continued to expand. The warnings were acknowledged and the scope kept expanding anyway.

The final accounting was straightforward and painful. What should have reached market in three to four months never launched after twelve to fourteen months of development. The budget nearly doubled. The app store page stayed empty. Every one of those outcomes was forecast and advised against.

The cost of ignoring warnings is not just financial. A product that does not launch cannot acquire users, test its assumptions, generate revenue, or attract further investment. The twelve to fourteen months spent building was twelve to fourteen months not spent learning. The founders now know a great deal about the product they wanted to build, and nothing about whether the market would have wanted it.

We saw a parallel cost structure on a dating app project focused on verified profiles. The client chose to skip discovery for the messaging component, focusing only on onboarding. The generic messaging feature that resulted contradicted the core product premise, it allowed automated and fake messages, undermining all the verification work in onboarding. That section had to be rewritten at a cost of approximately £15,000 in additional budget and two months of extra work. Skipping a step did not save time. It multiplied it.

The Structural Conditions That Let Scope Creep Win

Scope creep does not win because teams are careless. It wins when the structural conditions favour addition over restraint. On the sports club app, several conditions aligned in a way that made expansion almost inevitable.

• Both decision-makers were emotionally and professionally close to the product and both pushed consistently to add features.
• The all-or-nothing launch stance meant there was no point at which real user data could redirect the product.
• Refinement sessions had no formal requirement to maintain scope, new items could be introduced without replacing existing ones.
• Warnings from the agency were advisory rather than binding, so the client could note them and continue regardless.
• No external checkpoint existed, no investor review, no beta user group, no milestone gate, that would have required the founders to defend the scope to someone other than themselves.

Any one of these conditions makes scope control harder. All five together make it almost impossible. The agency's voice for restraint has to compete against the founders' certainty, the refinement sessions' open-ended structure, and the absence of any mechanism that would make adding a feature cost something visible in the moment.

What a Controlled Scope Process Actually Looks Like

The lesson from the sports club app is not that ambitious products are wrong. The lesson is that ambition needs structure. A product that sets out to manage finances, games, schedules, and players across multiple sports requires a process that holds the scope while the product matures.

A controlled scope process has a few specific properties.

1. A defined MVP that covers one user need, on one platform, for one sport or category, with sign-off from all decision-makers before build begins.
2. A formal change-control process where any new requirement after sign-off requires a written request, an impact assessment on budget and timeline, and a decision about what gets displaced.
3. Refinement sessions that open with a scope review, not a feature review, the question is always "what are we cutting today" before "what are we adjusting."
4. A real user in the loop before the budget is spent, even if that means a limited beta, a prototype test, or a single focus group that can challenge the founders' assumptions.

Before refinement sessions begin, circulate the current scope document and ask each stakeholder to mark which three items they would cut if the budget were reduced by 20%. The exercise surfaces priorities quickly and reframes the session around trade-offs rather than additions.

The grassroots football app illustrates what this comparison looks like in practice.

Conclusion

The sports club app project ended with a full budget spent, nothing on the app store, and a product that still has not reached its market. That outcome was not inevitable. The timeline, the budget trajectory, and the risk of never launching were all forecast early and documented clearly. The structure of the project, two founders close to the product, no MVP, no formal change control, refinement sessions that expanded rather than reduced, made the outcome likely from the start.

Scope creep rarely announces itself. It arrives as a series of reasonable-sounding additions, each one framed as obvious, each one small enough to seem manageable. The damage is cumulative and the point of no return is passed quietly, usually somewhere in the middle of a refinement session where someone says "of course it needs to do this."

Working with the iterative process, and listening to professional advice about when to launch and what to cut, is not a constraint on ambition. A product that launches with a focused feature set and grows through real user feedback builds on evidence. A product that waits until everything is ready risks waiting indefinitely, which is exactly what happened here.

If your product is in development and your refinement sessions keep producing a longer feature list, the structure around those sessions needs to change before the budget does not. Let's talk about your product scope.

Frequently Asked Questions