A utility company ran a program that reduced monthly bills for specific households, and enrollment was low. It partnered with a community organization, our client, to find out why people weren't enrolling in cost-saving benefits designed for them.
The research team assigned to the work had community partners collecting data directly from customers: interviews, conversations, the usual groundwork of finding out what people were experiencing. What was missing was a way to test the process itself before asking anyone else about it. Civil filled that gap. We had the community partners go through the enrollment process themselves first, exactly as an applicant would.
They ran straight into everything a household applying for the benefit would have faced:
- Contradictory qualification requirements.
- Language and technical jargon that created real confusion.
- Geographic rules tied to zip code and household size, unclear on whether renters qualified the same way owners did.
- Enrollment materials available only in English, in neighborhoods that were mostly Latino and African diaspora.
Both the utility and the community organization already assumed the process was probably harder than it needed to be, and that low enrollment was likely about more than awareness. The research team's plan to interview customers directly was the right methodology, built to collect the qualitative and quantitative data that would make the case for change. Testing the process first, through the community partners' own experience, added something the interviews alone couldn't: a shared, collective wisdom about how to talk with customers and evaluate the program's outcomes, built before a single formal interview began.
There are three kinds of knowledge available in a moment like this: what one person notices firsthand, what the institution has already learned and carried forward, and what the community being served already knows. Most organizations lean on whichever one is most efficient to gather, usually the institution's own records, and treat that as the whole picture.
What you notice yourself: individual knowledge
The community organization already knew, in the abstract, that the enrollment process was cumbersome. That's a different kind of knowing than what happened once the ambassadors sat down and tried to enroll themselves. Going through it firsthand surfaced the specific moments of confusion, the exact language that didn't make sense, in a way a general sense of "this is cumbersome" never could.
Service designers have a name for this, journey mapping: tracing a process from the user's point of view instead of the org chart's. It works for a simple, human reason. The people who design a process almost never experience it the way the people going through it do. They already know where it leads, what to bring, who to call if something goes sideways.
A program officer can review a thousand grant applications and develop real expertise doing it, a sharp eye for a weak logic model, a fast read on whether a budget is realistic. That's not the same thing as knowing what it's like to be the applicant. Sitting down to fill out that same application under a real deadline, with real funding on the line and none of the insider knowledge of what the reviewer is looking for, surfaces something the years of reviewing never could.
That's the distinction worth holding onto: a role gives someone real skills, the technical ability to do the job, and real competency, the judgment built from doing it many times. Neither is the same as the individual knowledge this practice is after, the specific, felt experience of what a system is like from the other side.
This gap looks different depending on which seat someone holds. Five of these need nothing more than a willingness to be curious:
- Programs. Apply to your own program as a participant would, with only the public-facing information available.
- Communications. Try to find a plain answer to a basic public question using only what's on your own website or social channels.
- Operations. Route a routine request, a facilities issue, an IT ticket, a vendor payment, exactly as a new staff member would, with no insider shortcuts.
- People and culture. Go through onboarding, a performance review cycle, or an exit process as a new or departing employee experiences it.
- Risk and resilience. Report a concern or a near-miss through the official channel and see how far it travels.
The rest take real standing to arrange, which is exactly why a senior leader is often the only person positioned to try them, and exactly why it's worth doing:
- Revenue and development. Go through the donor or funder cultivation process as a first-time prospect would, from the initial email to the ask.
- Finance. Read and reconcile a single program's budget the way its program manager without a finance background has to, working only from the reports and codes they are handed.
- Governance. Sit through a full board cycle as a new board member would, from the packet landing in an inbox to the vote, with none of the context a tenured member carries.
Notice where confusion sets in, where the waiting happens without explanation, where you'd want to give up if this weren't your job.
That discomfort is real, and it's worth unpacking rather than just noting. Some of what you hit is habit wearing the costume of necessity, with nobody left who remembers why it started. Telling that apart from something with real weight behind it is its own skill. The sorting starts with your own seat: the specific thing you notice is knowledge the organization doesn't have until you surface it.
What the institution already carries: organizational knowledge
Individual experience alone can mislead as easily as it can clarify. One person's confusion might be a genuine design flaw, or it might be something the organization already tried to fix once and couldn't, for reasons worth knowing before anyone proposes fixing it again. That's the second source: the record of what's already been decided, attempted, and learned, sitting in institutional memory whether or not anyone thinks to consult it.
That record deserves its own scrutiny before anyone treats it as settled. "We already tried that" is one of the most common answers institutional memory offers, and it's worth asking what tried meant:
- Designed, never tested. The idea only ever existed in a strategy document or a slide deck. Nobody ever ran it against real conditions.
- Piloted, never built. It ran once, as a small test, under conditions that may not even hold anymore. It was never installed into how the organization operates day to day, so it was quietly shelved before it had a real chance to prove itself either way.
- Built, never sustained. It was fully running for years and worked. Then the person who championed it left, and it lapsed with them. That's a failure of succession, not a failure of the idea itself.
Each of those is a different kind of already tried. Treating them as the same thing is how an institution ends up permanently ruling out ideas that were never given a fair chance.
The same scrutiny applies to whether a rule is even real:
- Unbacked policy. It exists on paper, but the decision rights, money, or staffing needed to make it operate as intended were never put behind it. It's a commitment in name, with nothing structural holding it up.
- Inherited constraint. It traces back to a board decision made years ago, a funder's compliance requirement, or a regulator's standard nobody currently in the room had any hand in writing.
Both can look identical from the outside, a barrier nobody seems able to move. The difference only shows up when someone checks: whose authority was behind it, what resources ever moved to support it, and whether it was fully built and sustained, or quietly stalled somewhere along the way.
What the community already knows: relational knowledge
The third source is easy to treat as confirmation of the first two rather than a distinct source in its own right: the knowledge already held by the people the system is meant to serve, independent of anything staff notice or any record the institution keeps.
This is why the ambassadors didn't stop at enrolling themselves. That firsthand experience gave them something they wouldn't have had otherwise: the actual words and frustrations to listen for once they went out and started talking with the community members they were there to understand. Their own confusion became a kind of fluency, a way of recognizing what people were describing instead of needing it explained from scratch.
Community knowledge deserves the same precision as the other two sources:
- Authority, not raw material. Community members had almost certainly known about these barriers for years, the way anyone who has to live inside a system knows more about how it functions than the people who designed it from outside ever will. That knowledge doesn't need to be gathered so an institution can decide what to do with it. It's already a form of authority, earned through years of direct contact with a system that someone else built and never had to use themselves. Treating it as raw material, something to extract, summarize into a report, and then set aside, gets the relationship backward.
- A longer view than the institution keeps. A program cycle gets measured in quarters or grant terms. The people living with a system's consequences are often watching it play out over years, sometimes across a generation, and they see costs and patterns a shorter cycle was never built to notice. An organization that only plans as far ahead as its next funding period will miss what the people who have to live with a decision long after the program ends already know.
- The weight of carrying it inward. Raising what community members have said is not neutral information-sharing. It can mean telling colleagues, or a director, that people have been harmed by a process the institution built and has defended for years. That's a heavier thing to say out loud than a data point on a slide, and it deserves to be carried with that weight, not filed away as routine feedback.
An organization that skips this step, no matter how thorough its internal testing, is still only working with a fraction of what it could know.
Cultivating new wisdom, one day at a time
Here's the good news: every organization already holds all three kinds of knowledge. The key is bringing all three to the table at the same time, which most organizations never do.
The distance between how a system was designed and how it's experienced isn't a mystery waiting on an outside expert. It's already knowable, by the people already inside it.
Closing that distance means stewarding what's already there, what you notice yourself, what the institution remembers, what the community has always known, into one honest picture, then asking what deserves to hold, what needs repair, what needs to be redesigned, and what needs to be disrupted because it's protecting the wrong thing.
Pick one system. Go through it as the user has to. Ask what the institution already remembers about it. Ask the people it's meant to serve what they've already noticed. Bring all three into the next room where the decision gets made, and ask, out loud, which of those four it deserves.
None of that guarantees a warm reception. A finding like this can land on a decision someone already signed their name to, and meet defensiveness before curiosity. McKinsey, of all places, built a formal rule for this: a duty to dissent, obligating its most junior employee to challenge the most senior person in the room if and when something isn't working that would affect the bottom line.
Philanthropy and nonprofits carry a duty to improve, not as an eventual aspiration, but as an obligation that comes with holding resources and power on behalf of people who don't get to opt out of the systems built for them. Treat improvement as a one-time correction, and the same hard conversation repeats every few years. Treat it as a standing duty, and a single difficult conversation becomes an ordinary habit instead of a recurring crisis.
That's the whole practice of thinking differently: not a talent some people are born with, but a discipline of using what's already sitting in the room. It gets more satisfying the more it's practiced, and it starts small, one system, one honest look, one good question asked out loud. That's closer than it looks, and entirely within reach.