Disagree and Commit: Holding the Vision

The hardest part of holding a vision is that the pressure to abandon it almost never looks unreasonable. It shows up as a real customer need, a real lost deal, a real number sales can point at. Saying no to that is easy when you're wrong and genuinely hard when you're right.

I lived this with a chat feature. A competitor with chat raised its prices, which sent a wave of leads our way asking why we didn't have one. Sales felt it immediately. Chat was turning into a reason we lost deals, and the obvious fix was to build the same chat the competitor had, as fast as possible. The trouble was that the obvious fix quietly broke the thing we had decided to be. We had staked the product on being the productivity tool of choice for growing teams, and an open, requester-initiated chat firehose is one of the fastest ways there is to wreck a technician's productivity. The urgent need and the strategy were pulling in opposite directions.

So instead of arguing about whether to build chat, I went and worked out what people actually needed underneath the request. Talking to customers, two very different patterns showed up wearing the same word. Technician-initiated chat was genuinely productive, faster back and forth, less email, quicker resolution. Requester-initiated chat was the dangerous one, the open inbox that would bury technicians in real-time noise. A survey came back a near-perfect split, which told me the demand itself was ambiguous, not obvious.

That gave me a way to hold the vision and serve the need at the same time. I designed a hybrid. Technicians could start a chat straight to a user's machine through our agent, keeping the workflow in their control. Requesters got structured, device-based forms instead of an open chat, so they could report a problem in detail without spawning a real-time firehose. And all of it, chat, email, ticket comments, collapsed into one threaded view with the busywork automated. It served the real need without becoming the thing that would erode the product we were building.

Designing it was the easy half. The harder half was that sales wasn't sold, because it wasn't the exact chat the competitor had, and they were the ones in front of customers. Being right on a whiteboard means nothing if the people selling it don't believe it. So I did the unglamorous work. I built the data-driven objection handling, I took it to leadership, and I made a video the sales team could send to customers directly to explain why our approach was the better one. Meeting sales where they were, instead of handing them a position and asking them to translate it, was the actual unlock. The feature went on to be used by most of our customers within months, and by the vast majority of the larger teams we were built for.

That experience taught me how I want to disagree in general, and it matters most with founders. When I think a direction is wrong, I don't dig in verbally and I don't quietly comply. I write it down. A one-page counter-thesis with the customer evidence, then a real debate, then we agree on a small, time-boxed experiment with the kill criteria set in advance. If the experiment proves my concern, the roadmap changes. If it validates their call, I commit completely and I mean it. Disagree in writing, commit in execution. It turns a conflict into a question both sides actually want answered, instead of a contest of who is more sure.

Holding a vision was never about being stubborn. It's about being clear on the one thing you refuse to trade away, flexible about how you get there, and honest enough to put your own disagreement to a test that could prove you wrong.