When the product changes, the organization has to learn
New technology can change what a product makes possible long before an organization changes how it works. The harder task is redesigning the decisions, responsibilities, and habits around that possibility.
Sample essay — generated content for testing this publication's article template.
A new capability is easy to describe as a feature. It can make a task faster, remove a step, or bring a previously difficult activity within reach. A product team can demonstrate the difference in an afternoon. The surrounding organization may take much longer to understand what that difference asks of it.
Consider a service that helps a customer make a complicated decision. Today, the customer might gather information, speak to a specialist, compare options, and return later. A new tool could bring those activities into one conversation. The interface becomes simpler. Behind that interface, questions about responsibility become more complicated.
Who stands behind the recommendation? When should the customer reach a person? What information can the system use? Which team sees a mistake, and which team has the authority to correct it? These questions belong to the product just as much as the conversation on the screen.
A capability is only the beginning
The useful unit of change is the relationship between a capability and the work that surrounds it. A faster answer has limited value if the customer still has to repeat the same information elsewhere. An automated decision creates new work if nobody knows how to challenge it.
This is why the first question in a product discussion should often be about the journey rather than the tool. What can someone now accomplish? The answer reveals which activities can disappear, which need to change, and which become more important.
The organization needs a way to learn from those changes. A launch is an opening move in that learning process, rather than evidence that the surrounding system has already adapted.1
Look for the decision that has moved
A useful starting point is to follow a single decision. Before the change, who made it? What did they need to know? Who could question it? After the change, ask those same questions again.
The decision may have moved from an employee to a customer, from one team to another, or from an explicit meeting into the behavior of a system. Its consequences remain. The work of making those consequences visible has often moved as well.
The useful unit of change is the relationship between a capability and the work that surrounds it.
This pull quotation repeats the essay’s central argument. It introduces no external attribution: the point is to keep the capability and its organizational setting in the same frame.
Redesign the bargain around the product
Products make implicit promises. A customer gives time, information, attention, or money in exchange for something useful. Employees and partners make commitments that allow the product to keep that promise.
When technology changes the experience, those commitments can become misaligned. A customer may expect an immediate resolution while the organization still routes exceptions through a weekly meeting. A team may be held accountable for a decision it can no longer inspect.
The response is a set of practical design questions:
- Responsibility: Who owns the outcome, including the exceptions?
- Authority: Can that person change the behavior that produces the outcome?
- Visibility: What evidence will tell them that something needs attention?
- Learning: How does one corrected exception improve the next customer’s experience?
These questions connect a strategy to ordinary work. They also help distinguish an attractive demonstration from a service that people can depend on.
| Product change | Organizational question | Evidence to look for |
|---|---|---|
| A faster recommendation | Who can challenge the answer? | A clear review path |
| Fewer customer steps | Where does the removed work go? | An updated service journey |
| More automated decisions | Who owns unusual cases? | Named exception responsibility |
| A more personal experience | What information is appropriate? | Understandable data choices |
This table is a thinking aid, not a measurement framework or a claim about a particular organization. Its purpose is to keep the conversation concrete.
Make learning part of the operating model
A product that can change quickly needs a clear way to decide what should change. That does not require turning every observation into a new process. It requires a small number of dependable paths from experience to action.
One simple description is:
Observe an outcome
→ Identify the decision behind it
→ Give an owner the authority to respond
→ Test the change
→ Observe againEach arrow represents a handoff that can become slow or ambiguous. Making the product better may mean improving one of those handoffs rather than adding another feature.
The same applies to the customer. A human fallback should have a defined job: handling a situation that needs judgment, restoring context, or explaining an outcome. A person who receives an exception without the information or authority to resolve it is another delay, however reassuring the interface sounds.2
Strategy becomes visible in the connections
The most consequential changes may happen between teams, responsibilities, and moments in a customer journey. Those connections are less visible than a new screen, but they shape whether the screen can keep its promise.
A product strategy should therefore describe both a new possibility and the conditions that make it dependable. The capability creates an opening. The organization learns how to turn that opening into something people can use.
Return to the writing index.