The app is dead. Please open your messaging app for details.
Photon held an app funeral and raised $4.5 million.1 Its product connects agents to interfaces including iMessage and WhatsApp.2 The obituary has excellent distribution.
There is a serious product idea here. People already have places where they read messages. Asking them to install another tool, remember another login, and develop another habit adds work before the new product has done any. Putting a service where its customer already spends time can spare the customer that ceremony.
But declaring a new era is more enjoyable than explaining a distribution improvement. You can announce an API. Or you can arrange flowers.
The deceased controls the guest list
Consider an imaginary startup that handles appointment changes through a messaging service. A customer types a request. The agent checks availability and proposes a time. Nobody learns a dashboard. Good.
The startup has still inherited several practical questions. Who owns the account? What happens if the messaging provider changes its rules? Can the customer tell which business they are speaking to? Where does a mistaken appointment get corrected? A familiar interface can reduce friction without making those questions disappear.
For a founder, the dependency deserves a place beside the convenience. Reaching customers through an existing platform is a distribution choice. It is also a choice about which parts of the customer relationship somebody else can change. An interface can be comfortable for the user and strategically uncomfortable for the company using it.
Our imaginary investor proposes describing this arrangement as owning the relationship. The engineer asks whether that ownership includes the channel. The investor suggests a less literal understanding of ownership.
We have moved the buttons into a sentence
A conversational service needs to decide what a request means. Buttons once made some choices explicit. A message can combine three requests, contradict an earlier instruction, or leave out the detail required to act.
A good implementation can ask a useful follow-up, display a confirmation, and make the result inspectable. A poor one can produce a friendly paragraph while doing the wrong thing. The conversation is an interface; it still needs a product behind it.
Some tasks benefit from dialogue. Others benefit from seeing options side by side, inspecting a record, or changing one field without negotiating with a personality. There is no reason every useful interaction must become a chat because chat has attracted the current round of funding.
The customer might welcome fewer apps. They might also welcome fewer unsolicited conversations with services that have discovered permission to be personable.
After the service
The useful question is whether the new arrangement completes the job with less effort and leaves the customer able to understand what happened. We can measure that without first agreeing on a date for the death of software.
Our fictional appointment business has a sensible next experiment: compare completed changes, errors, and customer effort against the old process. Its investor prefers a more ambitious experiment involving a larger venue and a second wreath.
The app has survived previous declarations of its death. This time, at least, someone has built a service worth examining. The service can make its case without a death certificate.
The reception remains in an app. Please mute the group when you leave.