Grant Cycles Are Killing Your Product Roadmap

Most nonprofit newsrooms are making their biggest technology decisions inside a 12-month window. That is not a planning horizon. That is a sprint with a grant officer watching the clock.

I work with small newsrooms and nonprofit publishers, and the pattern repeats constantly. A bilingual community outlet gets a content-focused grant. The team hires a reporter, publishes more, grows the audience. Then the grant ends. The CMS is still the same creaking install it was two years ago. The mobile experience still breaks on the devices their readers actually use. The newsletter signup still loses 30% of form completions to a buggy integration. None of that got fixed because none of it was in the grant budget, and there was never a quiet moment to make the case for it.

A recent piece on the state of news philanthropy from INN surfaces something the field is slowly starting to name: sustainability conversations have become harder to have even as the funding ecosystem has matured. Outlets are better at individual fundraising than they were a decade ago. Some are even opening up to public funding models. But the structural mismatch between how philanthropy flows and how platforms actually get built has not gone anywhere.

Here is what that mismatch looks like in practice, and what I think actually helps.

The grant cycle is not your product cycle

Grant cycles reward outputs: stories published, communities reached, engagement numbers. That logic makes sense from a funder's perspective. It is legible, it is auditable, it fits inside a reporting period.

Platform decisions do not work that way. A CMS migration takes three to six months and pays off over three to five years. An accessibility audit and remediation project has no obvious output metric but determines whether a significant portion of your audience can use your site at all. A redesign done right involves research, iteration, and editorial buy-in that cannot be rushed without producing something your team won't trust and your readers won't use.

When you try to compress those decisions into a grant cycle, one of two things happens. Either the project gets scoped down until it's cosmetic, or it gets deferred indefinitely because the timing never lines up with available funding. I have seen both. The deferred projects are the more dangerous ones, because they accumulate.

Separate your infrastructure thinking from your funding calendar

The first practical shift is treating your technology roadmap as a document that exists independent of your grant calendar. That sounds obvious. It is not common practice.

What this means concretely: keep a living list of platform needs, ranked by audience impact, with rough effort and cost estimates attached. Not a wish list. A prioritized document that you update quarterly and that informs every funding conversation you have. When a new grant opportunity appears, you can look at that list and ask honestly whether any of these needs can be attached to this proposal, or whether this grant will pull staff attention away from something critical.

The list also makes it easier to have conversations with program officers. Funders who are open to general operating support, and more of them are than they were five years ago, need to understand what that support actually covers. Showing up with a clear infrastructure backlog is more persuasive than a vague ask for capacity funding.

Build in a platform review at every grant transition

Grant transitions are chaotic. Someone is leaving, someone is onboarding, reporting deadlines are colliding with proposal deadlines. It is the worst possible moment to also think about your website.

That is exactly why it needs to be scheduled. I recommend treating every major grant transition as a trigger for a short platform review: one to two hours, the right people in the room, asking three questions. What is breaking or degrading? What do we keep patching instead of fixing? What will we need in the next 18 months that we do not have now?

The output is not a project plan. It is a shared understanding of what the platform debt looks like, documented somewhere accessible. That shared understanding is what lets an executive director make a credible case to a funder, or a board, or a major donor, that infrastructure is not overhead. It is the thing that makes the journalism reachable.

Stop treating technology as the thing you fund after everything else

The frame that technology is overhead is a funder problem, but it is also an internal culture problem at a lot of newsrooms. Editorial leaders who came up as reporters sometimes have a genuine blind spot here. The site is slow, yes, but we published 40 stories this month. The newsletter signup is broken, yes, but our open rates are decent.

The audience that never signed up because the form errored out is not in your open rate data. The reader who left because the page took eight seconds to load on a budget Android phone is not in your analytics in any visible way. Platform failures are mostly invisible in the metrics that grant reports reward, which is part of why they stay unfunded.

Making this argument inside your organization, before you make it to a funder, is worth the effort. The outlets I have seen do this well treat their website and their technical infrastructure as part of the editorial product, not a separate department's problem. That framing changes what gets prioritized, and eventually, what gets funded.

The grant cycle is not going away. But it does not have to be the thing that runs your roadmap.