When the “stupid” idea was the right one
Take a Denver construction firm of about 30 people with field crews — the kind of shop we work with regularly. A firm like that can nearly kill its best process improvement of the year because the person who proposes it is a 24-year-old field tech with no IT background. The idea: scrap the project-management software the office spent a five-figure budget rolling out and replace it with a shared spreadsheet and a group text. On paper, that’s a downgrade.
In cases like this, the “downgrade” can cut daily admin time across the crew by a couple of hours and stop the office from chasing field updates at 9 PM — while the expensive software stays installed and nobody opens it.
That’s the innovation paradox: a bad idea and a breakthrough idea look identical the moment someone says them out loud. For an SMB owner, the useful question isn’t which one is this? — you usually can’t know yet. It’s how do I find out cheaply enough that being wrong doesn’t hurt? This post is the framework we use to answer that, plus the Denver examples behind it.
Why good ideas look bad at first
Three forces make smart, experienced leaders dismiss the ideas that end up mattering most:
- Pattern recognition works against you. Your brain prefers the familiar. Anything genuinely new trips the same alarm that kept your ancestors alive. Useful in 10,000 BC; expensive when a field tech suggests deleting your software.
- Deep expertise narrows the lens. Twenty years in an industry teaches you how things should work — which is exactly what makes it hard to see how they could work differently. The field tech had no idea what the software was “supposed” to do, so he proposed what would actually work.
- Asking customers and staff doesn’t settle it. People can’t ask for what they can’t picture. Surveys produce incremental tweaks, not category shifts, and last year’s data tells you nothing about a process that doesn’t exist yet.
None of this means ignore your experience, your team, or your customers. It means unfamiliar ideas need a different kind of test than familiar ones — a test built to surface evidence fast, not to win an argument in a meeting.
What we’d actually do: a 4-week test, not a 4-year strategy
Most innovation advice is written for companies with a research-and-development (R&D) budget, a dedicated team, and years to run experiments. For a 30-person business, the practical version fits inside a single month and costs less than a software trial. The logic is the same as a lean build-measure-learn loop — Eric Ries’ Lean Startup methodology describes the principle; below is the SMB-sized version with concrete steps.
Week 1 — cost the idea at its smallest provable scale
Forget the full rollout. Ask one question: what is the cheapest version that proves or disproves the core assumption? A spreadsheet beats a software trial. A manual workaround beats an integration build. A two-person pilot beats a department-wide one.
- Write the core assumption as a sentence you can be wrong about. Not “field reporting could be better,” but “field crews will log job updates same-day if it takes under 30 seconds.” That sentence is the thing you’re testing.
- Set a hard budget ceiling for the test itself — often a few hundred dollars and a slice of one person’s week. If proving the idea costs more than that, you’ve scoped the test too big.
Denver example: a 25-seat accounting firm wondered whether AI-assisted document intake would cut data-entry hours at tax season. The full version is a workflow platform and a six-figure conversation. The week-1 version: route 50 real client documents through one off-the-shelf tool and have one staffer time the before-and-after.
Week 2 — pick one team and one number
Run the small version with people who will tell you the truth, measured against a single metric that matters to the business.
- Choose one number with a unit. Hours saved per week, errors caught per 100 invoices, days to month-end close, calls deflected per day. One. If you track five things, you’ll argue about all five in week 4.
- Include at least one skeptic — ideally the person who’ll have to support the idea after rollout. A pilot staffed only by believers always “works.”
Denver example: a multi-location retailer testing a new point-of-sale-to-accounting reconciliation tied success to one number: minutes per store to close out the day. Two stores ran it, including the manager who hated the idea.
Week 3 — watch what happens, not what people say
Self-reports lie, especially when someone is invested in the outcome. Look at what the system records on its own.
- Pull the machine-generated data: timestamps, log counts, error rates, the actual close time the software stamps — not the meeting recap of how it went.
- Note the workarounds. If the field crew is logging updates but doing it in a side text thread, the tool isn’t winning; the habit around it is. That distinction changes what you scale.
Week 4 — decide: scale, kill, or iterate
One decision, made on the data, with no fourth option.
- Scale if the number moved enough to justify the full cost.
- Kill if it didn’t — cleanly, and thank the person who proposed it so the next idea still gets proposed.
- Iterate only with a specific change and a new one-month clock. “Let’s keep watching” is not iterating.
This is the same loop we run when a client is weighing a move from QuickBooks to a full Enterprise Resource Planning (ERP) system, a cloud-provider switch, or a new ticketing tool. Most ideas die in week 2 — cheaply, before they ever become a line item. The few that survive have earned the full investment.
Watch-outs
Three places this framework breaks in practice:
- Picking a fuzzy metric. “User satisfaction” is not a metric; “average time from field update to invoice” is. If you can’t write it as a number with a unit, week 4 turns into a vibes contest.
- Stacking the pilot with believers. A team that wants the idea to win will make it win regardless of merit. The skeptic on the pilot is a feature, not friction.
- Skipping the kill decision. “Let’s run it another month” is how zombie pilots are born — half-running for years, quietly burning out whoever maintains them. Scale, kill, or iterate with a defined change. Nothing else.
Next step
If there’s an idea sitting in a notebook that you can’t tell is brilliant or terrible, that’s the conversation we like to have. See how we approach [[IT strategy]], and we’ll help you scope a 4-week test that costs less than a software trial — and tells you the answer before the budget does.