The frog who asked for nothing
The frog who asked for nothing
But a man still built it anyways
Here is this week’s newsletter a couple of days earlier than planned, just to that I can cash in on a “cute” video everyone is sharing on social media.
The thing is, and I say this as a miserable Delivery Manager type, it is not cute. I’d go even further than that to say it is everything that is wrong about designing and delivering a project.
Let’s dissect the frog… video together.
To start with, a man – it’s always a man, amirite *snaps fingers in a Z shape*
Sorry, wrong angle for this newsletter. There’s this man who sees a frog entering, what I am assuming is mating season, while sat on his fence and minding its own business. The frog is basically getting a high vantage point to croak his way to happiness.
For reasons unknown, other than likes on TikTok, this man makes the frog a house. Where was the New Work Request? Who agreed the spend on this? Where is the Statement of Work or contract notice?
The house he built sat unused. Did he think about speaking to his frog, the end user? No, of course he didn’t. He saw a frog. Imagined a need and just went into solutionising (business jargon) for a problem that didn’t exist.
What comes next will scare all of the Delivery Managers out there.
He opened up the non-problem to a wider audience, and it became design by committee. So before the MVP (I hate that acronym with every ounce of my being) had been tested and was validated, the man started to create phases 2, 3 and 4 – all based on the designing by committee concept.
Phase 3 even allowed competitors into the market. Where the frog had no problem to start with, he now had the prospect of losing out to a mate because the competition was using the open sourced croak that this design had created. Things were spiralling out of control.
But it was to get worse. With the platform created, it had opened up the real possibility of an acquisition and merger (to the inside of a Possum’s stomach). So what did they do – they played god and released another version. The GitTub on the side of the frog house was now so bloated with other frogs, that the only option was to abandon the pro…
Nope, they built another version with even more features.
Remember. All this frog wanted to do was mate. Not be part of an endless release cycle of features they’d never asked for in the first place. As is often the way, the frog looked for an alternative. A backwards compatible option. It streamlined the unnecessary features and business processes, and merged their biological code with another user in a more direct fashion.
BECAUSE THAT’S ALL THEY WANTED TO DO IN THE FIRST PLACE!
“Why are you so miserable, Chris?”, people might ask.
This isn’t about misery. It’s about team members who think they know the answer to a user’s problem without actually interacting with the user.
They never to stop to ask why? They power on, gathering ideas and implementing changes without stopping to check if they were doing the right thing. It happens all of the time, usually with a Delivery Manager being told to create a plan for an infinity pool for a frog, or a new feature for a piece of software or application that no one really needs.
The DM will say no and th… Too late. The development team have just built it. The product owner has retrofitted the new feature to the roadmap and the Delivery Manager just sits there, surrounded by torn up plans and swearwords drifting away with the wind.
It is a good video, but the reality is that at no point did anyone just ask why a frog would need a house with an infinity pool and a croak enhancer, when all it wanted to do was get its rocks off until the next mating season.
So next time you are in a meeting and someone suggests a solution to a problem that doesn’t exist, think about the frog who had sex on a fence when someone, somewhere had spent time and effort to build a house that a different frog, not having sex, was relaxing in.
/end