Every season, we hold tryouts for my travel softball team before finalizing the roster for the upcoming season. We watch how the girls field and hit, but that’s only part of it. We see how they take instructions, respond when something goes wrong, and work with the rest of the group. By the end of the tryout, we’ve learned enough to make a decision.
Some players earn a spot. Others don’t.
That doesn’t mean the tryout failed. We tell them where we need to see improvement and encourage them to come back next season. That’s the tryout working exactly as intended. What we don’t do is give a player a roster spot because one parent is convinced their kid is a good fit – every coach knows that parent.
Because once you make that commitment, you’re giving up something real: a roster spot, time, money, and opportunities for the rest of the team.
Most organizations aren’t always as disciplined with their ideas.
Look at almost any roadmap and you’ll find ideas that moved surprisingly far before anyone really tested whether they deserved to. This is especially difficult with disruptive ideas (the kind meant to test a new direction rather than extend something that already works) that often are put through the same funding process and asked to compete for the same people, budget, and sprint capacity as established roadmap work.
That usually creates one of two outcomes. The idea gets pushed aside because proven work is easier to justify, or someone believes in it enough that the organization commits real time, budget, and people to a full build before there’s enough evidence to know whether it should. One never gets a real tryout; the other gets handed a roster spot before tryouts even begin. Neither is a particularly good way to make a decision.
Clayton Christensen identified a version of this problem decades ago in his research on disruptive innovation. In established organizations, resource allocation tends to favor proposals that improve what already works over ideas that introduce more uncertainty. It’s not because leaders care less about new ideas. Proven work simply enters the competition with an advantage: it has a track record, a clearer business case, and outcomes that are easier to defend.
Christensen’s point wasn’t that companies need to want disruption more. It’s that disruptive ideas will continue to lose when they’re forced to compete directly against proven, lower-risk work for the same funding and capacity. Instead of asking the new idea to fight harder for a roster spot, give it a tryout of its own.
The fix isn’t more process. It starts by separating ideas based on what they’re actually intended to do: sustain and improve what already works, or test something genuinely different. From there, disruptive bets can be funded through a dedicated pool instead of being asked to win a popularity contest against a mature roadmap.
The ideas worth testing then follow two rules. First, carry two or three real approaches forward instead of committing to one too early. Second, give the team a fixed, short window to build enough of a working prototype to learn something real. If an idea needs a quarter just to prove itself, it’s no longer a rapid bet; it’s a full build wearing a prototype’s clothes.
The first rule is usually the harder one. We’re taught from an early age to look for the right answer, and most of us carry some version of that habit into our careers: pick a path, make the case, get everyone aligned, and start building. The scientific method asks something different of us. Form a hypothesis, test it, and be willing to find out that you were wrong.
Business understands that concept in theory, but organizations still tend to select a path early and then spend years defending it. The problem with committing early isn’t simply that you might make the wrong choice. It’s that you may make the choice before you have enough information to know.
There’s a well-established precedent for approaching this differently. Studying how Toyota developed cars, Ward, Liker, Cristiano, and Sobek described what they called set-based concurrent engineering (SBCE). Rather than selecting one design early and repeatedly iterating on it, engineers carried multiple alternatives forward and narrowed the set as evidence arrived.
Their 1995 paper captured the idea in a title that still feels counterintuitive: The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster. Toyota wasn’t delaying decisions for the sake of waiting. The organization was keeping options open until there was a reason to close them. The discipline is knowing which doors you can afford to leave open and closing each one at the last responsible moment.
I’ve seen firsthand what happens when that moment comes too early.
In 2014, one of my peers worked with a large logistics company on an initiative to consolidate the three devices a driver carried on their belt into a single device with a flexible architecture. It was a multi-year project, and one of the first decisions the architecture team wanted to make was which specific device the platform should consolidate to. Not the application architecture but the device itself.
They chose Windows Phone. Well before launch, Microsoft announced it was winding down the platform. By then, enough downstream decisions had been built around that original choice that the team had to continue developing against it while planning to support a device that no longer had a future.
The hypothesis should have started with the problem: How do we consolidate three devices into one? From there, the team could have carried two or three platform paths forward, designed a modular application architecture, and committed to a specific device at the last responsible moment. A flexible application architecture could have survived Microsoft's announcement. A device decision locked in during year one could not.
Nobody on that team made a bad call with the information they had in 2014. The mistake was making the call that early, with no mechanism to revisit it when the information changed. The organization had effectively handed one option the roster spot before it had finished the tryout.
There’s a practical reason teams tend to pick one path early: carrying a set used to be expensive. Three approaches could mean three times the design work, development effort, and cost just to find out which one was worth pursuing.
That math is changing. Simulation gives teams more ways to pressure-test a hypothesis against demand patterns, failure modes, cost curves, and other variables before committing budget to a full build. AI can accelerate the generation and testing of alternatives as well. Instead of narrowing the field primarily through debate and opinion, teams can increasingly use evidence to eliminate options before significant development begins.
The bets that survive enter the prototype window with a reason to be there, and that window should still be short. Protolabs’ 2026 Innovation in Manufacturing report points to how quickly these development cycles are changing, with respondents reporting meaningful reductions in development costs and time-to-market through AI-enabled manufacturing software and hardware. Work that once required significantly more time to explore can increasingly be tested much earlier in the process.
That makes a two-sprint prototype much more practical than it used to be, but speed isn’t the point by itself. Learning is. At the end of that window, there should be a demo and a decision, with the people who control the budget in the room. The idea moves forward because the evidence supports it, not simply because its champion believes strongly enough in it.
A “go” means the idea has earned the next level of investment. From there, it should hand off to the team that will own and scale it long-term — deliberately not the same team that built the tryout prototype. That handoff isn’t a formality. The people who are good at proving something can work in two sprints aren’t necessarily the same people who should operate it for the next five years, and asking one team to do both is how shortcuts made during experimentation quietly become production architecture.
A “no-go” matters just as much. What the team learned goes back into the pool of ideas, where it can be sized and re-ranked alongside everything else. Sometimes the idea comes back during another cycle with a different approach. Sometimes what comes back isn’t the idea at all, but a constraint nobody knew existed before testing it. Either way, the attempt wasn’t wasted. It simply didn’t make the roster this season.
There is, however, a third outcome, and it’s the one nobody puts on a slide. The prototype doesn’t clear the bar, but it has a strong champion, so instead of getting a no-go, it gets a little more runway. Then a little more. A year later, it’s still not in production, but it’s not dead either. It has a couple of engineers attached to it, some budget, and a standing meeting that nobody quite knows how to cancel.
Every organization I’ve worked with has at least one of these: a roster spot nobody will cut. A tryout only works if “no” is an available answer.
That’s also the mechanism the logistics project needed in 2014. The team didn’t need someone who could predict the future of Windows Phone. It needed a scheduled moment when the original decision would be reopened using whatever was true at that point, with someone who controlled the budget in the room and had the authority to make the call. Microsoft still would have changed course, but the team could have responded while its own decision was still reversible.
Most consulting firms show up once the decision has already been made. The requirements are established, the platform is selected, and the engagement becomes about building what has already been decided. That’s a perfectly reasonable model for work that has earned its spot on the roster. It’s the wrong model for figuring out which ideas deserve a roster spot in the first place.
Sometimes, that question is the work.
In 2014, there was no shortage of capable people on that logistics project. What nobody was engaged to do was ask whether the device decision needed to be made in year one at all.
That’s where TSG works with clients before the build begins: separating real bets from safer extensions of the roadmap, creating room to test those bets without forcing them to compete for the same sprint capacity, setting the window for experimentation, and bringing the people who control the investment into the decision when the results come back.
None of that is a build engagement. It’s what helps determine whether a build engagement is worth starting in the first place.
Before your next planning cycle, there are a few questions worth sitting with:
When I’m building a softball roster, the goal of a tryout isn’t to prove that every player belongs on the team. It’s to create a fair opportunity to see what they can do before committing one of a limited number of roster spots. Some players are ready now. Some need more development and come back stronger next season. And sometimes a player surprises you and earns a spot you might not have given them based on what you knew before the tryout.
Ideas deserve the same opportunity.
You don’t need to put every idea on the roster. You need a way to test the promising ones, learn quickly, and be willing to make the call when the tryout is over.
Because the question isn’t only “What should we build?”. It’s “What has earned a spot on the roster?”
Curious what a structured tryout could look like for your idea pipeline? Let’s talk.
For more insights from Tiffany, subscribe to the TSG newsletter and follow her on LinkedIn.