Thoughts
What happens when we can build faster than we can adopt?
A few months ago, I heard a product team explain why quarterly customer advisory board meetings were starting to feel too far apart. A customer could suggest something at one meeting, and the team could have a prototype ready in two weeks. They needed to hear from customers more often to decide what to build next.
That was the challenge I explored in AI and the silver bullet: when building software gets easier, deciding what to build matters even more.
A recent conversation with a product executive took the idea a step further. His company is embedding AI in its customer-facing products and using it internally to build faster. His team has gotten better at deciding what to build and delivering it quickly. He is now concerned about what happens once those features reach customers.
Suppose we deliver the right feature in record time. How quickly can the organization change the way it works to get value from it?
The right feature can still be hard to adopt
Take a feature that gives inventory planners a better replenishment recommendation. They may understand it and want to use it. But do they have the data and authority to act on it? What happens if it conflicts with an existing policy?
Imagine, unlikely as it may be, that this is the only change on the table. Even then, the company might need new technical capabilities, clearer decision criteria, or a different division of responsibilities.
I was formally introduced to Prosci’s approach to change management and worked within it in previous roles. One distinction from ADKAR has stayed with me: knowing how to do something and being able to do it in practice are different. Training a planner to read a recommendation won’t give them the authority to act on it.
What can we do before the feature arrives?
I’d start by bringing together the people who understand the technology and the people who run the operation.
- Make the implications visible. Put the current and proposed ways of working side by side. What would people do differently on Monday morning? Be clear about what we know, what we’re assuming, and what still needs a decision.
- Build literacy in both directions. Technical teams need to understand how the business works, including its exceptions. Business teams need to understand what the technology assumes and where people still need to exercise judgment. Use language both sides understand and make room for basic questions.
- Work through one real case together. Follow a recommendation through to the action someone would take. If a policy gets in the way, involve its owner. Agree on what result should improve, then check whether the new way of working delivers it.
IT executives are often expected to be the tip of the spear for innovation. Part of that responsibility is bringing the right people together while the feature is still being planned. We can help business leaders work through what will need to change, decide who will own those changes, and stay involved as they put them into practice.
Planning what to build and planning how the business will put it to work belong in the same conversation.
Originally published on LinkedIn.