Nobody Stopped Me. That Was the Problem.

Part 2 of 2, continued from "You Might Have Enough Ideas to Destroy Your Own Organization"

AI, Innovation, and Faith — donbarger.com

I once built a website nobody asked for.

In my defense, it was a genuinely good idea. A modern-day journal for orality, the field of ministry that focuses on reaching people who learn and communicate primarily through spoken word rather than text. Mostly practitioner-focused. Quasi-academic. A place where missiologists and field workers could share ideas, push the conversation forward, document what was actually working.

The niche was real, the need was real, and I was genuinely excited about it.

Here’s what else was real: the niche was also very small. Keeping fresh content coming was an enormous lift. The HTML involved in building something engaging enough to keep people coming back was, at that moment in my technical development, a bridge too far. And the question nobody asked me, not even me, was the one that would have saved us all a lot of time.

Who is actually going to read a journal about orality?

Not the concept. Not “is there an audience for this space?” The specific, uncomfortable, slightly humbling version: have you talked to three of those people? Do they feel this problem viscerally enough to come back next month? Is the lift of building and maintaining this justified by the size and engagement of the audience you’re actually building for?

Nobody stopped me and said: have you run this through a value proposition canvas?

Nobody stopped me and said: before you build the thing, validate the thing.

I built it anyway. It didn’t work. And the lesson I should have learned from that experience, the one that took me embarrassingly long to fully internalize, is that building is the easy part.

Adoption is the hard part. And adoption requires its own discipline entirely.

---

Building Is the Easy Part

Here’s what nobody tells you when you’re a person who is good at building things: the skill of building is not the same skill as the skill of adoption. They are different arts. They require different instincts, different questions, and in many cases, different people.

Builders ask: can we make this work?

Adoption asks: will people actually change their behavior to use this?

That second question is harder. Much harder. Because behavior change is expensive. It costs people something: time, habit, cognitive load, the friction of learning something new. And people will only pay that cost if the value on the other side is clear, felt, and greater than the cost of staying where they are.

Most builders, and I include myself prominently in this category, are deeply optimistic about this calculus. We built the thing, so we believe in the thing, so we assume the value is obvious. It is not obvious. It is almost never obvious. The value has to be demonstrated, communicated, and often experienced before someone will pay the adoption cost.

The orality journal seemed obvious to me. I was wrong about what was obvious.

---

The Value Proposition Canvas Nobody Used

There’s a tool called the Value Proposition Canvas. It’s not complicated. On one side, you map what your product does: the gains it creates, the pains it relieves, the jobs it helps people accomplish. On the other side, you map your customer: their actual gains, their actual pains, the actual jobs they’re trying to get done.

The goal is fit. Does what you’re offering actually match what they need?

The reason most builders skip this is not because they don’t know it exists. It’s because doing it honestly requires sitting with the possibility that the answer is no. Or not yet. Or not for this audience. Or not at this scale. And that’s uncomfortable when you’ve already fallen in love with the solution.

If someone had walked me through that canvas before I built the orality journal, here’s what we would have found: the gains I was creating were real, but they were gains for a very small, very distributed audience with no existing habit of consuming written practitioner content. The pains I was relieving were genuine, but people were coping with those pains in other ways: conferences, email lists, word of mouth. And the job to be done, staying current on orality practice, was being done well enough that switching to a new platform required a motivation that didn’t exist at sufficient scale.

None of that means the idea was bad. It means the idea needed more validation before it became a build.

I built first. I validated never. The site didn’t work.

---

Adoption Needs Its Own People

Here’s the other thing Part 1 didn’t have room for: even when the idea is right, even when the validation is solid, adoption still requires dedicated human attention.

Not leftover attention. Not “we’ll handle adoption after we ship.” Dedicated, intentional, ongoing attention from people whose actual job is to help other people change their behavior.

In the missions world, we call this MAWL: Model, Assist, Watch, Leave. You don’t just hand someone a new tool and disappear. You model how it works. You assist them through the awkward early stages. You watch them use it and correct in real time. And then, only then, you step back and let them own it.

That’s adoption. That’s behavior change. And it is a full-time job that most organizations assign to nobody.

Most organizations ship something, announce it, and then wonder why the numbers are low six months later. The answer is almost always the same: nobody was assigned to close the gap between “we launched this” and “people actually use this.” Those are not the same event. There is a chasm between them. And crossing that chasm requires people who understand that their job is not to build but to help others receive.

The orality journal needed a content editor, a community manager, and probably a dedicated champion in the orality space who would recruit contributors and readers personally. I had none of those things. I had a website and an idea and optimism. It wasn’t enough.

---

The Two Questions You Should Ask Before You Ship

If Part 1 was about sequencing ideas before you build them, Part 2 is about what happens after. Two questions, not five, not a framework, just two, that would have saved me significant time and energy over the years.

Question One:
Have we validated that people feel this problem enough to change their behavior?

Not “do people have this problem.” Not “is this problem real.” Do they feel it strongly enough that they will pay the switching cost to use your solution. That is a different, harder, more specific question. And if you can’t find five people who say yes with conviction, you’re not ready to build.

Question Two:
Who is specifically responsible for adoption, and what does their job look like for the next ninety days?

Not generally responsible. Not “the whole team.” Specifically. By name. With a job description that includes clear behaviors: who they’re talking to, what resistance they’re addressing, how they’re measuring success. If you can’t answer this before you ship, adoption will be an afterthought. And adoption as an afterthought is the same as no adoption at all.

---

Here’s What I Know Now

Good ideas need more than good execution. They need the right moment, the right audience, the right validation, and the right people focused on the right job after launch.

The orality journal wasn’t a bad idea. It was a premature idea, launched without validation, into a niche too small to sustain the lift required, with no adoption plan and no community manager and a founder who was already working on approximately 52 other things.

Nobody stopped me.

That was the problem.

So let me be your Wilkie for a minute: before you build the next thing, run the value proposition canvas. Talk to five people who have the problem. Assign someone to adoption before you launch. And ask yourself, honestly, whether the audience is large enough and motivated enough to justify the lift.

Your ideas deserve better than a website nobody visits.

Build accordingly.

---

If this landed, share it with someone who just said “we should build a thing.” They probably need both parts.