What Is a Watermelon Project? How to Spot One Before the Write-Off
Green on the outside, red on the inside — and how to read a status report that's lying to you
Green, green, green, green, green, amber… bright flashing red.
By the time the status flips to red, it’s too late. The budget is spent, the deadline has already marched months to the right, and the ask to fix it is now enormous — far bigger than it would have been if anyone had told the truth eighteen months earlier. I’ve watched this exact sequence play out more times than I can count, and the most expensive version of it cost a company £30m in a single write-off.
That’s the watermelon project. And once you’ve learned to spot one, you see them everywhere.
A watermelon project is one reported as green — on track — on the surface, while the reality underneath is red. The status report says everything is fine; the project is actually failing. The name comes from the fruit: green skin, red flesh. Watermelon reporting hides delivery, commercial, or adoption risk behind a reassuring RAG (Red/Amber/Green) status, right up until the truth surfaces too late to fix cheaply.
This is a problem of visibility, and visibility is exactly what RoadmapOne exists to provide. A watermelon survives because two things stay hidden: the real allocation of capacity against named objectives, and the non-engineering work — marketing, sales readiness, customer onboarding — that determines whether the thing actually generates money. Make the roadmap complete (including marketing activities and commercial milestones) and make capacity allocation visible to the board, and the fruit has nowhere to hide. More on that below — first, why the watermelon grows in the first place.
TL;DR: As a CPTO you feel like you’re walking a tightrope. If the project isn’t going well, you’re carrying the can — so the temptation is to keep showing that you’re delivering. Like an addicted gambler chasing losses, you tell yourself the next thing will get you back to the status you’ve been reporting all along. It almost never does. From the other side of the table — where I now sit doing PE due diligence and NED work — the watermelon is usually obvious within an hour, if you know which questions to ask. The fastest route to the exit lounge is telling a board something that turns out not to be true.
What Is a Watermelon Project?
A watermelon project is one whose reported status (green) contradicts its actual health (red). The metaphor is exact: cut the fruit open and the reassuring green skin gives way to red flesh. The project looks fine in the board pack and falls apart the moment you press on it.
The mechanism almost always runs through RAG status — the Red/Amber/Green traffic-light convention used in nearly every project status report and governance pack. RAG is meant to be a fast, honest signal: green means on track, amber means at-risk, red means in trouble. The watermelon corrupts that signal. The headline RAG is green; the detail underneath — if anyone bothered to look — is amber and red across scope, budget, timeline, and crucially commercial outcome.
What makes watermelons so dangerous is that they’re rarely a deliberate lie. Almost nobody sits down and decides to deceive the board. The green is usually sincere — a mix of optimism, budget pressure, partial truth (the tech really is fine), and a genuine belief that the next sprint, the next hire, the next integration will close the gap. That sincerity is what lets a watermelon survive review after review. Everyone in the room half-knows, and nobody has the calibrated evidence — or the nerve — to call it.
Why Watermelon Reporting Happens
If you want to stop watermelons, you have to understand that they’re a structural failure, not a character one. Good, honest people produce watermelon reports under the right pressures. Here are the pressures.
The Budget-Commitment Trap
This is the big one. You committed to a budget. You stood in front of the board and said you’d deliver X for £Y by Q3. Now you’re behind — but asking for more resource means admitting the original commitment was wrong. So you don’t ask. You hold the line on budget, keep reporting green, and quietly hope the team makes it up.
The cruel arithmetic is that this makes everything worse. When you finally report red after a long run of green and amber — with the same budget you committed to — the eventual ask is far bigger than an early, honest “we’re at risk, here’s what it’ll take to fix it” would ever have been. You’ve converted a manageable course-correction into a crisis. The budget commitment that felt like discipline was actually the thing that detonated the project.
The Sunk-Cost Gambler
The longer a project runs, the harder honest reporting becomes — because admitting trouble now means admitting that the last six months were partly wasted. So you chase losses. Like the gambler convinced the next hand wins it all back, you keep the status green and bet on a recovery that the evidence doesn’t support. Every month of green you report raises the stakes of the eventual red. This is precisely the dynamic that makes killing zombie projects so hard — sunk cost is a story we tell ourselves, and watermelon reporting is how we keep telling it.
Tech Is Reported in Isolation
Here’s the failure mode I see most often, and it’s the most under-discussed: the project is genuinely green from a technology perspective and nobody has thought about anything beyond writing the code. No go-to-market. No sales readiness. No onboarding. No one has asked whether a real customer will actually pay for this.
The board doesn’t care whether the code compiles. The board cares about outcomes : are we going to make money from this? A project can be 100% green on engineering and 100% red on commercial reality at the same time — and if your status report only shows the engineering RAG, it’s a watermelon by construction.
I worked with a company running about six different “transform” projects — the high-ambition, new-horizon bets in their portfolio. Every single one was green on the technology. Every single one turned red the moment we started asking about customers: who’s lined up, who’s tested it, who has committed to buy. The engineering was never the problem. The joining-up of the organisation around the project was. That’s the CPO’s job — and it’s the job that watermelon reporting lets everyone skip.
The Tells: How to Spot a Watermelon
You can learn to read these. Across a lot of board packs and a lot of diligence, the same signatures recur.
The Sudden Red After a Run of Amber
The classic shape — green, green, amber, amber, amber, red — is itself the tell. Status that degrades smoothly through amber and then snaps to red is suspicious, because real projects rarely fail discontinuously. A sudden red usually means the amber was hiding red all along, and something external finally forced the admission. When I see a long amber plateau, I assume the truth is worse than amber and start digging.
The Permanent Amber
The inverse is just as diagnostic. Some teams are so risk-averse that everything is red or amber — a permanent fog of known unknowns they’re afraid of. This looks like honesty but it’s the same calibration failure wearing different clothes. Like the boy who cried wolf, if your projects are always amber then your RAG carries no information at all. A status system where nothing is ever confidently green is as broken as one where everything is. Good reporting requires the nerve to call a genuine green green — and that requires calibrated confidence , not blanket caution.
Green on Tech, Red on the Customer
When the engineering status is glowing but nobody can answer “which real customer is taking this, and when?”, you’re looking at a watermelon. The single fastest way to expose one is to walk the project past the edge of engineering and ask about the commercial outcome . The green tends to evaporate at exactly the org boundary the watermelon was built to hide.
My Board-Room Detection Playbook
When I walk into a portfolio company and read a pack full of greens, here’s the routine I actually run. None of it is hostile; all of it is hard to fake.
“Show Me”
PowerPoint decks are fine, but I want to see the actual software. Not a polished demo. Not a screen recording — those are pre-baked and prove nothing. I want to see something working, live, and I’m going to ask you to click some links that you maybe don’t want to click. I don’t care if it’s raw Postman calls against an API — if you can’t demonstrate the platform doing something real, in front of me, then “green” is a claim, not a fact.
This single move — “show me, and let me drive” — collapses more watermelons than any amount of report scrutiny. It’s the project-status equivalent of “no plan survives contact with the enemy.” You learn an enormous amount by making the green prove itself in real time. (Shipping something small and real is also the cure, not just the test — more on that with replatforming below.)
Show Me the Customers
I want to know there are real customers lined up, ready to take the product, and — critically — providing insights as the development process continues. Not a market-sizing slide. Named customers, in the loop, shaping the thing. A transform bet with no customer in the room is red no matter how green the burndown chart looks. This is the heart of continuous discovery and the reason validation belongs on the roadmap, not in a one-off business case at the start.
Show Me the Marketing and the Sales Forecast
Back to outcomes. Does the roadmap include the marketing team’s activities? Has the sales team put a quote — an actual revenue number — in next year’s forecast for this new product? If the answer is “that comes later,” the project is a watermelon: the engineering is being built toward a commercial outcome that nobody has committed to. Joining up marketing, sales, and engineering on a single plan is the CPO’s core job, and a proper business case makes those commitments explicit rather than assumed.
The Replatforming Watermelon
Big replatforming projects — especially large ERP replacements — are the most fertile ground for watermelons I know. They’re often run heavily waterfall, with the real integration risk back-loaded to the very end, which means every individual workstream can report green for a very long time while the project as a whole is doomed.
Many years ago I was an architect at a company running a massive ERP project. Hundreds of consultants milling around doing requirements gathering, writing documents, even writing some code. Each individual workstream reported green. And yet the deadline kept marching steadily to the right, month after month, while the headline stayed reassuringly bright. It took an external firm — brought in specifically to give management the news nobody internal would — to state the obvious: there was a literally zero percent chance the project would deliver in any realistic timeframe. The bright green project was killed with a £30m write-off.
The lesson I took from that, and have applied ever since, is to relentlessly look for ways to get something into production early. Chipping away at a problem beats the big bang every single time. You learn so much by shipping — about the integration you under-scoped, the requirement you misunderstood, the assumption that didn’t survive contact with reality. A project that ships a thin slice every few weeks cannot become a watermelon, because the green is continuously tested against working software. A project that integrates everything at the end can stay green right up to the write-off. This is the whole argument for incremental delivery over big-bang , and it’s why I’m so suspicious of plans whose first real proof point is eighteen months out.
Killing the Watermelon Without Creating an Amber Culture
Here’s the tension. Scrutinise too little and you breed watermelons. Scrutinise too brutally and you breed the opposite pathology — the permanent-amber, cover-your-back culture where nobody dares call anything green. Both destroy the information value of your reporting. So the goal isn’t more fear; it’s better calibration and genuine trust.
A few principles that hold both failure modes at bay:
- Ruthless transparency, rewarded. The CTO or CPO who says “this is at risk and here’s what it’ll take” early must be thanked, not punished. Especially with non-technical boards, the entire relationship runs on trust: the board can’t independently verify the technology, so it has to be able to take the CPO’s word as gold. Burn that once and you’re done. The fastest way to the exit lounge is telling the board something that turns out not to be true.
- Calibrate the RAG. Agree, explicitly, what green/amber/red mean — and review past calls. A team whose greens reliably come true has earned the right to be believed; a team that’s always amber needs help calibrating, not more caution.
- Report outcomes, not activity. “We wrote the code” is not green. “A named customer is using it and the sales forecast holds” is green. Tie status to outcomes and leading indicators , not output.
- Make asking for help cheap. The budget-commitment trap only bites because re-forecasting feels like failure. Treat an early, honest re-forecast as good governance, and you remove the incentive to keep the status green out of fear.
None of this requires more meetings. It requires a reporting system that surfaces the truth by default, rather than one you have to interrogate to crack open.
How RoadmapOne Stops Watermelons
Most of the watermelon’s hiding places are structural gaps in the roadmap itself — and that’s exactly what RoadmapOne is built to close.
Marketing and commercial work on the same roadmap. The green-on-tech / red-on-customer watermelon survives because the roadmap only shows engineering. RoadmapOne lets you put the marketing team’s activities directly on the roadmap as their own rows, and add commercial milestones — first customer live, sales-forecast sign-off, go-to-market launch — against each project. Once “real customers lined up” is a milestone on the plan rather than a vague future intention, a project can’t quietly report green while the commercial side is blank.
Capacity allocation the board can actually see. Because RoadmapOne shows how much capacity is allocated against each named objective, and the Run/Grow/Transform split across the portfolio, the board gets a quantitative view that doesn’t depend on a single optimistic RAG dot. THIS IS EXACTLY THE VISIBILITY BOARDS NEED to understand how engineering resource is actually being spent — and it’s very hard to watermelon an allocation chart.
Incremental delivery, made legible. Scenario and master roadmaps plus a grid view that shows real capacity rather than a comforting Gantt illusion push teams toward shipping thin slices and away from the back-loaded big-bang where watermelons thrive.
None of this is a substitute for the human discipline of “show me.” But it changes the default. A complete, visible, outcome-linked roadmap makes the honest status the easy one to report — and that, more than any amount of scrutiny, is how you stop growing watermelons.
Frequently Asked Questions
What is a watermelon project?
A watermelon project is one reported as green (on track) while its actual status is red (failing) — green on the outside, red on the inside, like the fruit. The reassuring headline RAG status hides delivery, budget, or commercial risk underneath. Watermelons usually aren’t deliberate lies; they grow from budget pressure, optimism, and roadmaps that only show the engineering workstream while ignoring whether a real customer will pay.
What is a watermelon KPI?
A watermelon KPI is a metric that reports green at the headline level while the underlying detail is red. The classic example is an aggregate or averaged metric — overall uptime, blended customer satisfaction, total delivery progress — that looks healthy because a few strong components mask several failing ones. As with watermelon projects, the fix is to disaggregate: look beneath the headline number at the components that compose it, because users do not experience averages .
What is the watermelon effect in ITIL?
In ITIL service management, the watermelon effect describes an SLA that is met on paper (green) while customers are actually unhappy (red). It happens when the metrics in the service-level agreement measure the provider’s internal activity — ticket-closure times, system availability — rather than the customer’s real experience or outcome. The service hits every contractual target and still fails the people using it. The cure is the same as for any watermelon: measure outcomes, not internal activity.
What does RAG status indicate?
RAG status is a Red/Amber/Green traffic-light system used in project and portfolio reporting. Green means on track, amber means at-risk or needs attention, and red means in serious trouble or off track. RAG is meant to be a fast, honest signal for governance and boards — but it only works if the colours are calibrated and earned. A project that reports green while failing underneath is a “watermelon”; a team where everything is permanently amber has the opposite calibration problem.
How do you spot a watermelon project?
Ask to see something real. Demand a live demo of working software — not a screen recording — and insist on driving it yourself. Ask which named customers are lined up and providing feedback as development continues. Check whether the roadmap includes marketing activities and whether sales have a revenue forecast for the product. Watch for the tell-tale shape of a long amber plateau snapping suddenly to red. The green almost always evaporates at the boundary between engineering and commercial reality.
Why are watermelon projects so dangerous?
Because they convert a manageable problem into an expensive crisis. Every month a failing project is reported green, the eventual correction gets bigger and the budget ask grows. By the time the status flips to red, the money is spent and the deadline has already slipped — so the cost to fix is far higher than an early, honest re-forecast would have been. In the worst cases (large waterfall ERP replatforms, for example) the result is a multi-million-pound write-off.
Conclusion
The watermelon is one of the most expensive failure modes in product and technology delivery, and almost none of it is caused by bad intentions. It grows from budget commitments that punish honesty, from sunk-cost reasoning that makes the next green report easier than the truth, and from roadmaps that show the engineering and hide everything that turns engineering into money.
The antidotes are simple to state and hard to live: ruthless, rewarded transparency; calibrated RAG status that means something; outcomes rather than activity; incremental delivery that forces the green to prove itself; and a complete roadmap that puts marketing, sales readiness, and named customers on the plan alongside the code. Do those things and the fruit can’t ripen unseen.
And if you only take one habit away, make it this one: show me. Ask to drive the software, ask who’s buying it, ask where the revenue forecast is. The watermelon never survives contact with a real customer and a working demo. Cut it open early — while it’s still cheap to fix — rather than discovering the red flesh at the £30m mark.