The Product Works. The Organization Has Other Ideas.

Somewhere in a technology company, a demonstration is going beautifully. The system responds. The interface behaves. The engineers have solved a difficult problem. There may even be applause, depending on how long everyone has been waiting for it to work.

Somewhere else, a customer is still unhappy.

These two events are entirely compatible. They are also a useful starting point for my conversation with Cisco’s Tom Richards.

Tom’s career runs through pure mathematics, AI research, a startup, product management and go-to-market work. It would be easy to turn that into a story about moving from one technical challenge to a larger one. What interested me was something else: the gradual discovery that the human and organizational parts of the problem are often where the real difficulty lives.

The technology still matters. Clearly. But it has to enter a world that already exists, populated by people who have not spent the last eighteen months thinking about your architecture.

The appeal of a right answer

Tom loved mathematics. Part of the appeal was the distinction between a right answer and a wrong one. In a world full of ambiguity, that is an attractive arrangement.

He pursued pure mathematics through undergraduate and master’s study. Then he encountered a question that was less mathematically tidy: did he want to continue along an increasingly specialized path?

Tom enjoyed people. He liked meeting them, talking to them and learning from them. The prospect of a shrinking community able to engage with increasingly specialized work mattered to him.

That did not mean abandoning technical depth. He went on to programming, research and a PhD. But it helps explain why the people around the problem became such an important part of his work.

A career can look beautifully coherent when described backward. At the time, it often consists of something interesting appearing within reach and a decision to try it. Tom is quite open about that. I find it more persuasive than the biographies in which every accidental turn was apparently part of a plan formed at thirteen.

AI before it became everyone’s department

Tom’s account of AI research in the 1990s is enjoyable partly because it predates the assumption that every discussion of AI must end with a prediction about the next six months.

His work involved constraint programming and optimization. The challenge was to describe a complicated problem and navigate a vast set of possible solutions without treating every possibility as equally worth exploring.

There were practical industry problems behind the work, including scheduling. There were also colleagues working on forms of recognition whose future importance was not necessarily obvious to him at the time.

That admission matters. People who have worked inside a field do not automatically know which adjacent developments will become transformative. Being close to innovation does not come with a reliable map of its future.

We should be cautious about treating today’s confidence as proof that anyone has acquired one.

The more durable lesson from this period is about contact with the problem. Tom describes industry-funded projects, fast model development and regular feedback from the organizations involved. The research was technical, but the work had an external point of reference.

The magnificent solution nobody can implement

The startup chapter gets us to the uncomfortable bit.

A technically strong team can build something genuinely capable and discover that customers cannot easily put it to work. Tom describes solutions whose implications crossed departmental boundaries inside potential customer organizations.

This is where an elegant model encounters the less elegant distribution of authority.

One department owns a process. Another controls a budget. A third would have to change how its staff work. The benefit may appear somewhere else entirely. The person most enthusiastic about the technology may have no way to make any of those people agree.

A supplier can call this resistance to innovation. Sometimes it is simply an accurate reading of what the customer can accomplish within the organization they actually have.

This is not an argument for abandoning ambitious ideas. It is an argument for understanding the work required to make them usable. If the implementation needs cooperation across several functions, that cooperation belongs in the solution rather than in the optimistic footnote.

Tom describes finding a much better fit when Cisco had a need that aligned with an approach his team could apply. He also credits luck. Business storytelling could benefit from more of that word.

The successful outcome does not erase the earlier difficulty. It makes the difficulty worth studying.

Your departments are not the customer’s journey

Tom now talks about the connection between product, sales, partners, pricing, licensing and adoption. These are separate disciplines for good reasons. They become a problem when separation turns into a collection of unrelated plans.

The product team can be proud of its differentiation. Sales can have a clear account strategy. Partners can understand their delivery model. Each piece may make sense in its own meeting.

Then the customer tries to buy, deploy and use the thing.

That is the moment the combined design is tested. Customers experience the joins whether or not the supplier has assigned anyone to look at them.

It is a familiar problem in large organizations: local competence produces an awkward overall result. Everyone has done their part. The outcome remains disappointing. The next meeting may therefore contain an impressive number of people who are technically correct.

Tom’s emphasis on joined-up thinking is useful because it makes innovation larger than the feature list. A technology’s commercial and organizational surroundings influence whether its capabilities reach anyone who needs them.

That may sound obvious. It is certainly not consistently practiced.

The angry customer has information

One of my favorite parts of the conversation is Tom describing his interest in speaking with customers who were angry or upset.

There is a defensive version of that conversation: explain the product again, establish that it works and return the problem to the customer. There is also a curious version: if the product works, what else is preventing the outcome?

Consider the meeting room. It has good equipment. It supports the intended calls. Yet people do not use it.

Perhaps they think it is reserved for senior executives. Perhaps someone books it speculatively and never turns up. Perhaps the room’s history tells people it is for a special purpose even though that is no longer true.

The engineering team can improve performance without touching any of those obstacles. The customer might receive a better technical experience in a room they still cannot book or do not feel entitled to enter.

That is a fairly expensive way to preserve the original problem.

The implication is not that engineers must solve office politics. It is that deciding what problem needs solving requires enough contact with the real environment to distinguish technical limitations from organizational ones.

Fewer layers, better contact

Tom talks about removing indirection between people building a system and people using it. Large organizations have many good reasons to insert intermediaries. Over time, those intermediaries can also become the only route through which information travels.

A customer explains something. It is summarized, categorized, prioritized and converted into the vocabulary of an internal process. By the time it reaches a builder, important context may have vanished.

Direct contact can help. But Tom is not proposing an endless parade of every possible customer request through engineering.

Selection is the difficult part. Three major customers may offer useful insight while representing three unusual corners of the market. Their size does not automatically make their preferences universal.

The leadership task is to create contact that improves judgment: customers and users whose needs illuminate where the business should go. This requires a view of the wider market, an understanding of the team’s direction and enough humility to keep testing both.

Experience becomes valuable as a way to connect things, rather than a requirement to personally master every new technical detail.

The credibility you hesitate to leave

Near the end, Tom describes learning to like change. That learning was not instantaneous.

Moving into a new area means leaving some accumulated trust and familiarity behind. In an established role, people know what you can do. You have credit in the bank. Starting somewhere else can feel like voluntarily giving up an advantage you spent years building.

There is a sensible concern in that feeling. There can also be a trap.

The most familiar place is not necessarily the place where you will learn most or contribute best next. Organizational change can open opportunities that would never emerge from an orderly personal development plan.

Tom’s response has become more curious over time. He talks about people, environments and the conditions that allow a team’s abilities to come out. That brings us back to the gap between a successful demonstration and a successful outcome.

Useful innovation requires technical capability. It also requires someone to ask where that capability is going, who must use it and what might stop them. The answer is often inconvenient. It is usually more interesting than another slide explaining that the product works.

The full conversation with Tom Richards is on Before It Was Obvious. What has your organization learned from a technically successful product that people struggled to adopt?