AI can make businesses more efficient. The real question is how much human involvement is necessary to understand the problem, build trust, coach people, and help them actually succeed.
Then you design the business model around that value.
Many teams know Geoffrey Moore's adoption curve as a go-to-market framework.
Fewer apply it to what happens inside their own company.
The same curve governs internal adoption.
When you roll out a design system, a new process, or an AI workflow, you have innovators who try it immediately and early adopters who see where it's going.
Then you hit the chasm.
The early majority are pragmatists.
They don't adopt because it's exciting, but because someone they trust already uses it.
This is where most internal rollouts die.
A platform team ships a component library, the enthusiasts use it, and 60% of the organization keeps building the way they always have.
Nobody objects. They just don't cross.
Getting the early majority across takes the same work you'd do for external customers.
Onboarding, office hours, feedback loops, and evidence that adoption makes their job easier, not harder.
You have to treat your internal system like a product, because the people you're asking to adopt it behave exactly like a market.
High-performing teams are built on trust, accountability, and the confidence that everyone will show up for each other when it matters.
When people can give direct feedback, hold each other accountable, and address problems openly, they create a culture where everyone can bring their best and improve together.
If execution keeps getting cheaper, what's actually scarce?
The answer is decision quality.
For most of my career, the constraint was throughput. Could you design it, build it, and ship it fast enough to matter?
That bottleneck has been loosening for years, and the teams I watch now aren't limited by how much they can produce.
Instead, they’re limited by knowing what deserves to be produced.
Which means the skills that add up are different than they used to be.
Understanding the customer deeply. Framing the problem correctly. Knowing what to leave out.
Shipping more has stopped being the differentiator.
Choosing better is the whole game now.
The tools your internal team uses should closely resemble the tools your customers use.
But many companies treat those as separate products with separate standards for some reason.
Customer-facing gets the design attention. Internal gets whatever ships.
Then a support rep is trying to help someone through a workflow they've never actually seen, using an interface that behaves differently from the one the customer is looking at.
Work with any distributor or brokerage, and you see the cost of that difference immediately.
But when both sides share the same patterns, your team can reason about a customer's experience without translating.
Onboarding gets faster. Support gets more accurate.
You made the decision once, and both audiences benefited.
The best outcome of a software discovery process is sometimes learning you shouldn't build anything.
That's a difficult thing for a product firm to admit sometimes.
But plenty of problems that arrive framed as software problems turn out to be process problems, staffing problems, or something an existing tool already handles adequately.
Building custom software is expensive to create and more expensive to maintain - even in the AI era. Every feature becomes something someone owns forever.
The question worth asking early is whether the difference between what exists and what you need actually justifies that.
Sometimes it clearly does, and that's when the work is worth doing.
Sometimes the honest answer saves a client a year and a budget.
We used to spend weeks synthesizing user research on a FigJam board.
Dozens of customer interviews, and the work of finding patterns across them was almost entirely manual. Sometimes hours, sometimes weeks, depending on the volume.
That specific task has collapsed to literally just hours.
Sifting large amounts of qualitative data and surfacing patterns is genuinely one of the things these tools are good at.
But the human work still remains.
Our attention moved to whether the right patterns got pulled out, which ones actually matter, and what they mean for the product.
That's the shape of a use case that works.
One specific point of pain, clearly defined, with people still owning the judgment.
Success also means being present for the people waiting at home, alongside the conferences and the time on the road.
The goal is to be intentional about travel and make the most of it, spend fewer days away, and make more room for family and the moments that matter.
FOMU beats FOMO.
Fear of missing out is about losses that happen when you do nothing.
Fear of messing up is about losses that happen when you do something.
The second one is the better place to operate from.
FOMO is borrowed. It's a reaction to what everyone else appears to be doing, and it drives teams to adopt tools and ship features because a competitor did, not because a customer needed it.
FOMU means you're already in motion. You've made a real decision, and perhaps it didn’t work out.
But now you have the information necessary, thanks to that failure, to pivot and try again.
This time, with a higher likelihood of success.
Action produces information. Information you can’t find anywhere else.
Because your circumstances are unique to you. No LLM or internet forum can answer for you.
So acknowledge your fears and take action anyway.
Nobody else will do it for you.
The grass always looks greener when you're looking at someone else's business from the outside, but every business model comes with its own challenges.
As AI makes it easier to automate more of the customer journey, the bigger question is whether we're simplifying for efficiency... or removing the human element that makes the relationship valuable.
Startup advice assumes information is the bottleneck.
It isn't anymore.
Every framework and case study a founder could want is findable in an afternoon.
What isn't findable is the specific person who already solved the exact problem in front of you, in a similar market, at a similar stage.
I've helped run the startup community in Wisconsin for years, and I see this over and over again.
Founders show up wanting to talk on stage.
What actually makes the event worthwhile is the conversations they have with people after the fact.
That's what the community is for.
There are things you can’t possibly learn without the help of others. Just the way it is.
Systems thinking and design systems go hand in hand… but there’s a lot more to the story.
A design system is bigger than a component library.
But the useful part is that nobody has to debate that button again.
The same principle applies to far more than UI.
One clear ICP means one sales deck, one go-to-market plan, and one set of places to show up.
One reliable customer feedback loop means the team isn't reinventing how it learns all the time.
These are all small decisions, and small decisions get discounted because they look small in isolation.
But when the decision becomes a standard, it compounds through every person and every workflow that follows.
That's what I mean by "one decision that makes a thousand."
The best systems remove work people never needed to be doing in the first place.