The Experience: Subjective Software & Adjacencies

The Experience: Subjective Software & Adjacencies
Barossa Valley, South Australia

Back when I presented an overview of stakeholder value I broke it down into a funnel starting with an overall business strategy and ending at the realised digital product. In reality there is not just one realised product thanks to device and network variances.

Nevertheless, when a user is running software, they are seeing one Realised Product. They are participants in a feedback loop with the digital factory that many people may refer to in everyday language as a session. It is not possible to simulate the Perceived Experience that the user has across one or more sessions, as it is not only informed by the software but also of the user's mental model as well as various expectations they had formed ahead of time. These expectations could be informed by concerns attributable to any of design, the factory, the project, intellectual property, business, market, society and many other things. Together these expectations shape the Imagined Experience.

Enter adjacencies.

Marketing enables software projects to shape the Imagined Experience that a user anticipates toward a downstream Perceived Experience that a user has when they engage with the Realised Product. Support is also an adjacency, but one that has a more complicated relationship with digital products.

When a user faces a perceived issue (and at scale, they will) the best case scenario ends with the discovery that they can achieve what they wanted to achieve with a slight course correction. In this scenario, support plays a similar role to marketing in aligning a Perceived Experience of the future with the Imagined Experience.

The second scenario is that the perceived issue represents a legitimate problem and the time to remediate is low. An example of this is a content-related issue on a software platform where instantaneous updates to the affected content can be applied. The Realised Product is adjusted to align with the Imagined Experience rather than the other way around in the previous scenario.

The third scenario is where the trouble begins and the risk of churn really starts to ramp up, which is when a perceived issue represents a legitimate problem and the issue cannot be remedied quickly.

This class of perceived issue maps to a broad spectrum of possible remedies with different timelines: content changes that are tied to a particular version may be less than a day to a week, new features may be weeks to months. Changes that require a substantially altered digital factory may be months to years. There are many paths to scenarios where it may not be possible to resolve the Perceived Issue at all. Some relate to the supply chain or to gatekeepers. Others arise from expectations that cannot be met without breaking other promises. There was an example of this way back in sources of truth where there is a trade-off between delivering up-to-date content and granting users access to content in a timely manner.

Delivering a great Perceived Experience means successfully meeting your users where they are. All of the specification of the product, the implementation of the factory, proactive communication (marketing) and reactive communication (support) play a role in this. In a perfect world, the user's Imagined Experience perfectly matches their Perceived Experience and the Realised Product perfectly matches the Idealised Product. In the real world we have a field on either side of a screen.

We can now introduce Subjective Software.

There are certain kinds of software that are very highly commoditised, such as the storefront, the spreadsheet editor, the chatbot, the email client. These kinds of software exhibit minimal differentiation. For this class of software the field of imagined experiences is relatively small.

There are other kinds of software where the problem space may be commoditised, but the solutions are moderately or significantly differentiated in their form. For this kind of software, the field of imagined experiences is relatively large - I call this Subjective Software.

Part of marketing is building confidence that you can solve your users problems and in the presence of competitors you should also establish that your offering is uniquely positioned to do so. Another part of marketing is maximising the performance of campaigns. This creates a tension where marketing is incentivised to increase the field of imagined experiences, perhaps well beyond what could be considered reasonable. This dynamic is more common in entertainment products than other kinds of software, one example I can think of readily is the "Hunt the Truth" campaign for Halo 5, which teased a highly dramatic story that was quite different in direction from the Realised Product that fans later received.

Many digital games can safely be considered Subjective Software, and one line of criticism from professional writers for some specific products in the market is that this classification is in moderate or serious doubt. The Legend of Zelda: Breath of the Wild is notable for clearly influencing a number of games that were criticised for being "the same" in a more than superficial sense.

For other kinds of software projects I believe the degree to which they may be considered Subjective Software is dictated by the potential for user preference to emerge. When you offer a large set of functionality, people are going to have different ideas about what should be prioritised and what doesn't matter at all. When you offer a small set of functionality, you run the risk of having limited to no appeal, or not being economically viable. There's an art to building platforms that are both sustainable and reliably fill a need in a large number of peoples' lives, and many companies struggle to do it.

Until next time.