The Prototype on Someone's Computer
I ran a product that let business owners manage and respond to reviews from customers about their offerings. The data was rich, and I wanted to bring more insight to our customers through sentiment analysis. The problem: we had no budget for it, no data science team availability, and the third-party solutions were expensive.
So we started digging around, and we found a prototype sitting on a developer's computer. It was a sentiment analysis tool he'd built as a side project. We resurrected it, tested it against our structured review content, and discovered it worked perfectly. That prototype became a featured product at our annual customer event.
We found that prototype because we had no other choice. With budget and a data science team, we would have spent months evaluating vendors or building something from scratch, and nobody would have gone looking through a developer's side projects.
Six months and ten times the cost
I've seen this pattern more than once. Teams with unlimited options produce mediocre results because they never have to dig for the simple answer. When everything is possible, it gets very hard to choose what matters most, and nobody feels much urgency.
If we'd had budget for that sentiment analysis project, I know what would have happened: weeks of vendor evaluations, a shortlist, pilot programs, procurement negotiations, integration planning. We would have gotten a decent result eventually. It would have taken six months and cost ten times more than resurrecting a prototype that was already built for our exact data structure. With no money, the question changed from "which vendor should we buy?" to "what do we already have?" and that one led us straight to the answer.
Adding constraints on purpose
I'm not suggesting random limitations. Start with the boundaries you already have and treat them as something to work with. Where there aren't any, you can add a few deliberately.
Look for where your team spends weeks evaluating options and hardly any time testing them. That's a sign they need a tighter constraint. Time-boxing works well here. Set a 30-day sprint in place of an open-ended exploration period. Limit a feature set to three critical user needs and see what your team builds when they can't add a fourth. The pressure that sent us digging through a developer's side projects can be created on purpose.
When my team saw that our zero-budget project ended up featured at our annual customer event, it changed how they talked about limitations. They complained about them less and started treating them as a place to begin. We started asking "what would we do if we had half the time?" and meant it as a way to find the core of an idea.
What was on that computer
That sentiment analysis prototype had been sitting on a developer's computer for months. It was already built for our data, and it already worked. If we'd had the budget to look elsewhere, I'm fairly sure it would still be sitting there.
I suspect most teams have something like it: a side project or a spike somebody abandoned. What would you find if you had to ship next quarter with no new money?