GoldieCow and the 3 EnginBears
What a fairy tale can teach you about scope, estimation, and shipping what actually matters
Once upon a time there were three Bears, who worked in the same company. One was a Wee-Little Bear, one was a Mid-Sized Bear, and another was a Big Bear. Each had their own styles of communicating. Each had their own means of judgement. Each had their own ways of building applications.
One week, after their release, the bears headed off to the woods to enjoy their paid time off. As they were away, a user named GoldieCow stumbled upon their released applications.
With a business reason to explore these applications, GoldieCow found herself genuinely entertained. A few clicks into Wee-Little Bear's app, and she'd already made up her mind.
GoldieCow moved on to Mid-Sized Bear's application next. A few clicks in, she decided:
And finally, GoldieCow pulled up Big Bear's application. GoldieCow barely got a look in before the earth-shattering brilliance sent her scrambling for cover. The thing was blinding.
Overjoyed about these applications, GoldieCow waited for the bears to come back.
Days later, the bears returned from the woods. GoldieCow had been waiting, and she came bearing a large-scope request for a new application. Without a second thought, she turned to Big Bear. Of course she did.
When she asked for an estimated delivery date, the Big Bear said:
Eyebrow still raised, GoldieCow moved on to Mid-Sized Bear. Surely he could offer a more palatable timeline. The Mid-Sized Bear cleared his throat and said:
GoldieCow let out a long sigh and lowered her eyebrow in defeat. As she conceded to the timeline, Wee-Little Bear, practically bouncing, promised:
As the Mid-Sized Bear and Big Bear stood there silently, GoldieCow’s eyes sparkled with joy. An earlier delivery date was like music to her ears.
The Big and Mid-Sized Bears, still motionless, were replaying the estimation process in their heads. There was so much scope, so how would Wee-Little Bear pull this off?
Armed with a can-do attitude and with zero regard for work-life balance, Wee-Little Bear worked nights and weekends. He typed with fierce, emphatic purpose, determined to deliver by Spring.
Day after day, hour after hour, the clock moved forward without mercy. "Just 5 more minutes," Wee-Little Bear assured himself, as another three hours slipped by. He muttered to himself: “I can’t wait to make GoldieCow proud! I can’t wait to impress my colleagues.” Through sheer will and misguided optimism, he continued to build relentlessly until Spring.
Spring had arrived and GoldieCow had returned to see the promised product. Feeling triumphant after the biggest project of his life, the Wee-Little Bear was eagerly waiting for GoldieCow’s praise.
The App that’s “just right”
For as long as products have existed, there has been a battle between the definition of what makes a product “just right”. A Product Manager’s definition may lean towards rich functionality with the best user experience. An Engineer’s definition may lean towards scalable solutions that are high quality and maintainable. Even if Product and Engineering manage to align on what is "just right", there can be disruptive opinions from the outside; from Business Leaders, Executive Stakeholders, even the Board of Directors.
From GoldieCow’s point of view, more features translate to better products:
GoldieCow may want more features to improve the user experience. Or maybe her manager wanted more bells and whistles. Or maybe, just maybe, GoldieCow wanted to wow her friends at a business dinner with that one extra thing.
Whatever the reason, if your company had infinite money and resources, sure, maybe this rainbow unicorn gold-plated product can be achieved.
But if your company or department has tight budgets, then you are destined to negotiate between scope, timeline and resources.
These 3 attributes usually act as levers during your negotiation.
Just like physics, you can't get something for nothing. Every change in one corner of the triangle requires a transformation in the others to maintain equilibrium.
As you increase scope, you either increase the timeline or resources.
Regarding scope and time, let’s see how the 3 EnginBears estimated their work:
I’m certain the math is mathing so far… Poor Wee-Little Bear had underestimated the work. Ambitious and eager to please, his energy was genuine, but misguided. Large scope brings more unknowns, more risks. Tighter delivery windows only compound that, and work rushed through nights and weekends has a way of showing it.
Mid-Sized Bear and Big Bear were once little themselves. Experience had taught them to see around corners, to anticipate the risks that Wee-Little Bear hadn’t yet learned to spot.
But experience cuts both ways. Like someone who has survived a painful heartbreak and vowed never to be hurt again, Big Bear’s past had built walls around his estimates. Well-intentioned walls, but walls nonetheless. And a product wrapped in too much protection has its own kind of problem: over-engineered, over-cautious, and gold-plated in all the wrong ways.
So if you find yourself chained to an aggressive timeline like Wee-Little Bear, something has to give; either decrease the scope or increase the resources, before things crash and burn.
And pushing the date is not always the answer. Chances are, not all of the scope carries equal weight. If the product is in a race to the market, some of the scope can be deadweight that is quietly slowing down the release.
Each debate leads to different lever calibrations. But while everyone is busy calibrating, one question keeps getting lost in the noise.
What scope drives the largest business impact?
Followed by:
Then what’s next?
When scope is very large, what comes with it is also a large wager on business impact. You truly won’t know the impact until you release it. So until then, this is what GoldieCow would envision:
GoldieCow wasn’t wrong to want everything. She just didn’t realize what she was betting. When dealing with large scope in a release, you are gambling with more time and resources.
Here is an illustration of the business impact had this scope been delivered in smaller, phased releases.
As you can see, not all scope is created equal. Had it been broken down and prioritized initially, this would translate to iterative releases, meaning smaller bets. With each individual feature incrementally adding business value (or not) to your product, the feedback loop is quicker and therefore quicker to course correct your product.
Shifting your mindset toward iterative business impact leads to more reasonable targets. More reasonable targets translate to more successful negotiations between scope, timeline and resources.
Final Thoughts
I believe Product and Engineering are destined to negotiate till the end of time. Their operating systems were designed to focus on solving different problems. However, if they can align on business impact, it makes the negotiation easier.
If you can apply this perspective, if you can negotiate well, then scope stops being a gamble and starts being a strategy. And your GoldieCow will keep coming back to the right bear.
And why do all of this? It’s because no one enjoys working nights and weekends just to hear:
