Bad concepts are expensive. Not in obvious ways, but in sneaky, insidious ways. They kill momentum, waste time, and rack up massive, yet invisible, opportunity costs.
The great ASX blockchain debacle
Many projects gloss over the concept stage with fluffy, untested vision statements.
For example, in 2017, the ASX aimed to replace its existing CHESS system with a blockchain-based system. That project was canceled in 2023 after spending approximately AUD $250 million because the concept was inherently ill-conceived —blockchain would have made trades slower⁽¹⁾.
Why did they do this you ask? I’m assuming the internal monologues looked something like this:
- Executives: “Blockchain! Blockchain! Blockchain!”
- Vendor (while popping Dom): “$250 million dollarydoos, baby!”
- Solution Architect subcontractor: “None of this makes sense —but blockchain —so hot right now.”
- Project manager: “I have no idea what we’re doing, and at this point I’m too afraid to ask!”
Projects can run (for a surprisingly long time) like this without anyone noticing.
Concept design is a lost art in software
In software, we’re addicted to flexibility. “We’ll figure it out later” feels agile and usually stems from a real need to flex, but it can also be a crutch for lazy thinking.
We get away with it because trial-and-error is normalised in how we build software. Some of that is good, but “We won’t have all the answers up front” too often becomes “We won’t have any of the answers up front.”
Teams end up solving for concept, architecture, and build all at once—like drawing blueprints and laying bricks simultaneously, before the foundation is set —all in the name of showing progress. This is how a $250M money pit is born.
AI will lay this blindspot bare
As AI delivers code in minutes instead of months, the SDLC’s intense focus on “getting to dev” will dissipate. Expect a rebalancing with more attention swinging back to the concept stage.
Why?
- Consideration compression - Agile let us noodle on concept for months across sprints. Instant code means that crucial reflection time is gone.
- Customer bandwidth - Just because you can now add 100 features per week doesn’t mean you should. Customers can only absorb so much.
- Shrinking attention spans - Rapid product churn demands concentrated marketing firepower. Less second chances; MVPs and pivots become less viable.
- Race to average - Building with AI has a tendency to turn off your critical thinking and produce the median of existing concepts.
Hyper-accelerated output creates a paradox of abundance: opening up the taps delivers faster than ever before, but also makes it easier to drown.
Who does concept well?
Architecture, Advertising and Industrial Design.
Why? They pitch a lot. For them, a weak concept is a lost client.
Secondly, they face endless design and implementation choices (brick vs. cement vs. …), they literally need a strong concept to progress efficiently.
Concept design is standard practice in these fields for this reason. It reduces the decision space. It’s a proxy for making a thousand detailed design choices without having to explicitly define each. This slices through noise and streamlines decisions.
What strong concepts feel like
Strong concepts are answers to questions before they’re asked.
Not an exact answer, but you’ll know what wrong looks like. You’ll know which areas to deep dive and which to skimp. You will feel momentum.
For instance, designing a school vs a hospital: each concept immediately narrow decisions about room layouts, materials, lighting etc.
— Carpet in a hospital ward? Obviously not.
In software, a strong concept will narrow decisions about defaults, permissions, navigation, technology choices, architecture, mechanics, marketing, usability, look & feel etc.
— Consider building an "offline-first" travel guide app. That concept immediately prioritises local storage, downloadable maps, and resilient caching. Constant cloud syncing or streaming video? Obviously not.
If your concept can’t do this, it’s weak.
How to make strong concepts
I’ll write a longer article on this, but the concise version is:
- Activities: Deeply understand/empathise with the space, sketch ideas to poke holes or test with customers, question the implications of decisions.
- Outputs: Articulate understanding (personas, day-in-the-life), problem definition + unambiguous outcomes. Respond by placing a bet with rationalised and prioritised principles then communicate the concept to others.
More grind on activities = easier outputs.
The only metric is clarity. No fuzz, generics, hedging or platitudes. Be bold. Be deeply illustrative.
For example, “our app needs to be easy to use” is useless. “Users will learn our app over a month, spending only a few minutes a day.” That’s a principle with teeth. Designers and developers can make good trade-offs to hit that.
Concept as competitive advantage
As AI makes building software trivial, it also makes launching the wrong software project terrifyingly easy. Many will be tempted to launch the first thing they think of.
Shipping garbage at warp-speed might become more of a problem than shipping too late.
In that world, a strong concept development practice will provide a real edge by grappling with what matters early, transforming the core question from can we, to should we?
Footnotes:
