As Bill Sees It

Getting Through A Project When Everyone Has A Different Opinion

My team used to waste hours in meetings where nobody could agree on what the actual problem was. People would talk past each other, everyone was defending their own department's angle, and the decision never actually got made. One of my old managers started doing something pretty simple that eventually became what we just call As Bill Sees It around here. It's not a fancy framework or a proprietary methodology with a trademarked acronym. It's just a habit of writing out the core issue from the perspective of the person who has to deal with the consequences. That's basically it as a concept. But the way you actually apply it is where most people mess up. The first thing I did when we started using it was realize that people don't naturally do this. They write the problem statement the way they want the solution to look, which defeats the whole purpose. I had a client project once where we wrote up the situation exactly as the operations VP saw it, and it completely contradicted what the product team had been building toward for six months. The document was maybe three paragraphs long and took about twenty minutes to write. We spent two weeks going in a different direction than we would have otherwise.

Why As Bill Sees It Actually Works

The reason this approach cuts through the noise is that it forces a single point of view onto something that usually has ten competing ones. When you strip away all the stakeholder language and just describe what's happening from one person's angle, you expose the gaps and contradictions that everyone was quietly ignoring. It's not about finding the right answer. It's about finding the actual question before you waste budget on solving the wrong thing. I keep a library of these now and when I look back at the ones from three years ago, the pattern is pretty consistent. The ones that were written quickly and honestly, without corporate polish, turned out to be the most useful. The ones where someone tried to make it sound impressive were usually wrong. I learned to tell junior people on my team to write it like they're explaining the situation to a coworker at the coffee machine. If it sounds like a press release, rewrite it.

How To Actually Use It On A Real Project

Start by identifying who "Bill" is in your situation. That doesn't mean it has to be a guy named Bill. It means the person who will be living with the outcome the longest. In a software rollout, that's usually the support team lead, not the CTO. In a manufacturing change, it's the floor supervisor, not the strategy consultant. Pick the person who feels the pain most directly and has the least incentive to dress things up. Then get them to write or dictate a plain description of the current situation. Not what they want to happen. Just what's happening now. Keep it under five hundred words. I've seen people turn this into twenty-page documents and then claim they used the method. That's not how it works. The constraint is the point. When you can't fit your problem into five hundred words of plain language, you still don't understand it well enough to solve it. After that version exists, read it aloud to someone who wasn't involved in the original conversation. If they can't restate the core issue back to you in a sentence or two, the document isn't clear enough. I've caught this mistake so many times that I now do the read-aloud step before anything else. It takes thirty seconds and has saved us from misaligned projects more than once.

Once the description is solid, you move to the next step, which is figuring out what changes would actually affect that person's daily reality. This is where most teams skip ahead and start brainstorming solutions. Don't. Write out the specific symptoms the person is experiencing. Then map each symptom to a potential cause. You'll usually find that the cause you blamed initially isn't actually connected to what the person described. That mismatch is where the real insight is.

Where This Method Breaks Down

The honest limitation here is that As Bill Sees It doesn't work when the person you've chosen as the perspective holder doesn't actually understand the full scope of what's going on. I ran into this on a supply chain project last year where our designated Bill was a warehouse manager who knew exactly what was happening on the floor but had no visibility into the procurement delays upstream. His description was detailed and accurate for his corner of the operation, but it missed the actual root cause entirely. The workaround I use now is to have two or three people from different layers of the organization each write their own version. Then you compare them and look for the contradictions. Where they disagree is usually where the real problem lives. It takes a bit longer, maybe another hour of work, but it prevents you from optimizing for the wrong person's experience. The single-perspective approach is fast and often sufficient, but it has blind spots. Another scenario where this falls apart is when the stakes are genuinely high and the timeline is short. If you have forty-eight hours to make a decision and you spend three days writing perspective documents, you're not using the method correctly. In those cases, I just ask one or two key people the same question directly: what's actually happening from where you sit? That's a compressed version of the same thinking, and it's faster without being completely useless.

A Few Things Nobody Tells You About This

The first counter-intuitive thing is that the person describing the problem usually won't identify their own role in causing it. I've seen this happen repeatedly. People describe symptoms around them and never mention the decisions they made that created those symptoms. You have to ask about that separately, usually by looking at what changed recently in their area and connecting it to the problems they're describing. That's a follow-up conversation, not part of the initial As Bill Sees It write-up. The second thing is that written descriptions tend to look more confident than they should. When you put something on paper, it reads like a conclusion. But a good description from the affected person's view is usually full of uncertainty and "I think" and "it seems like." I tell people to leave that uncertainty in. A clean, confident-sounding problem statement is usually a sign that someone has already jumped to a solution in their head and is just dressing it up as analysis. There's also the issue of versions drifting over time. I had a project where we wrote the initial As Bill Sees It document in January and referenced it through March. By the time we got around to acting on it, the situation had changed enough that the original description was misleading. The document wasn't wrong when we wrote it. It was just stale. I now add a date stamp and a one-line note about what conditions the description depends on. If those conditions have shifted, you know to rewrite it rather than pretending it's still current.

The Practical Takeaway Around As Bill Sees It

If you want to try this on your next project, here's what I'd actually suggest doing. Pick one upcoming decision that's been stuck in committee for a while. Find the person most affected by it. Ask them to write three paragraphs about what's currently happening from their point of view. Read it out loud to someone else on the team. Look for the gap between what they described and what everyone assumed the problem was. That gap is usually worth more than whatever solution you were about to vote on anyway. It won't fix everything. Some problems genuinely require expensive analysis or external expertise. But for the routine decisions where teams tend to overthink and under-clarify, this is one of the cheapest tools I've found that actually moves the needle. I've been doing this for long enough to know that most of the time we spend going in circles is because we never actually agreed on what we were trying to solve in the first place. Getting that part right doesn't require a big process. It just requires someone willing to write a few honest paragraphs.