The determinants of consumers’ online shopping cart abandonment

Despite placing items in virtual shopping carts, online shoppers frequently abandon them —an issue that perplexes online retailers and has yet to be explained by scholars. Here, we identify key drivers to online cart abandonment and suggest cognitive and behavioral reasons for this non-buyer behavior. We show that the factors influencing consumer online search, consideration, and evaluation play a larger role in cart abandonment than factors at the purchase decision stage. In particular, many customers use online carts for entertainment or as a shopping research and organizational tool, which may induce them to buy at a later session or via another channel. Our framework extends theories of online buyer and non-buyer behavior while revealing new inhibitors to buying in the Internet era. The findings offer scholars a broad explanation of consumer motivations for cart abandonment. For retailers, the authors provide suggestions to improve purchase conversion rates and multi-channel management.

https://link.springer.com/article/10.1007/s11747-009-0141-5

The Effectiveness of Triggered Email Marketing in Addressing Browse Abandonments

Triggered emails are personalized messages that are automatically sent as a response to specific actions or states of customers. Typical examples of this type of campaign include cross-selling recommendations, cart abandonment reminders, and re-engagement emails. Despite the widespread growth of these strategies, there has been no formal evaluation of their effectiveness. This paper investigates the impact of one type of triggered email campaign by using an experimental approach. We identify customers who had recently browsed the website of a multichannel retailer but had abandoned the process before making a purchase. Approximately half of the sample was randomly selected to receive automated emails with different configurations, while the other half receive no message at all. Comparison of the sales of these two groups indicates that browse abandonment emails have increase revenues in the online channel and in the triggered category. In terms of the design of the campaign, we found that the implementation of triggered emails plays an important role in their effectiveness. In this regard our result indicates that retargeting based on longer navigation histories is associated with larger conversions and that recommendations of wider assortments are associated with larger revenues.

https://journals.sagepub.com/doi/abs/10.1016/j.intmar.2021.02.002

Weeknotes 504

I did:

Lining up

I was on leave all this week so only did a bit of lining things up for next week, including:

  • SEO analysis and advice for a product we might want to market in the future and so need to design for that now.
  • Discovery plan for “come back and finish what you started” emails (AKA abandon cart emails). We’re starting with a single use case but I’m hopeful we can develop it into a reusable service for any internal team.
  • Wrote a ‘product thinking’ exercise for a PM I’m coaching.
  • Reviewed some work a PM did on a shared backlog for assessing opportunities.
  • Tying up lose ends ready for next quarter’s budgeting.

I read/watched:

Autonomy vs alignment

Maarten says alignment is more important than autonomy. I disagree. I think autonomy is far more important than alignment.

Alignment, by which we mean everyone in an organisation trying to achieve the same goal, is a unitarist aim, and unitarism is pretty well recognised as anywhere between bad and false. An organisation is stronger if people are simultaneously trying to achieve different goals because no single thing is so overwhelmingly important that other things don’t stand a chance.

Autonomy is really important for modern organisations to respond to changing circumstances at pace and at scale. There are lost of academics and researchers that have reached this conclusion and autonomous teams have a century of history behind them.

Autonomy, as a management idea, goes back to Mary Parker Follet in the 1920’s where she proposed ‘the law of the situation’, which said those with the most knowledge should lead. This challenged the traditional hierarchical notion of leadership as people in authority telling those who aren’t what to do, and started to put decision-making power in the hands of those doing the work. The 1930’s saw the human relations movement which shifted the understanding of management as being not just about the work but also about the people. In the 1950’s, Trist and Bamforth studied autonomous teams in coal mines and developed the socio-technical systems theory. They stated that the innovative way teams were working provided an increase in productivity and provided the first real template for autonomous teams which still stands today.

Autonomy isn’t easy. In fact, Malone (1997) claimed the balancing of top-down control with bottom-up empowerment is a central issue for organisations in the twenty-first century, and Parker et al (2015) said that “organisations remain adverse to self-organised teams, and it is suspected that not willing to let go of direct control by senior management is the root cause.” But, it is really important. The benefits include “lessening the need for supervision, providing more flexibility and agility, improving employees’ work satisfaction and loyalty, reducing costs and boosting quality” (Sanne, 2021), and Patanakul, Chen and Lynn (2012) showed that autonomous teams outperform traditional project teams in circumstances involving novel technology and radical innovation.

So, if you’re a leader and you have to choose between alignment and autonomy, do the right thing, choose autonomy.

Size matters

Got a bit obsessed with the idea of things rolling-up into bigger things so watched lots of ‘the size of things’ videos to get my head around the underlying logic. It’s one of those things where once you notice it, you can’t stop noticing it. Addresses – house numbers roll up to a street, which rolls up to a town, and so on. Tomatoes – punnets roll up to shelves, which roll up to aisles, sections (fruit and veg), supermarkets. Same pattern, so many applications. I still don’t understand why. But when you recognise that its such an intuitive and pervasive way of organising things, it makes sense that we’d think about product metrics in the same way.

I thought:

Organisational feedback mechanisms

I’m sad to say that because of the poor state of NHS mental health services in my area, I’ve had numerous contacts with the Patient Advice and Liaison Service. They have never given advice and aren’t very good at liaising, but if you have a complaint they are your only option. They will send your complaint to a manager who will, eventually, provide an explanation. Not an apology or acceptance of mistakes or promise to change, just an explanation. Follow the process and carry on as before. But if an organisation doesn’t give it’s complaints department the teeth to demand improvement, then what else could we expect.

How organisations accept feedback from people they have let down says a lot about their commitment for improvement. If the answer is, ‘computer says no’, or ‘policy says no’, or ‘manager says no’, or even ‘national framework says no’, then it’s clear there is no commitment to improve. There is only an even stronger commitment to maintain. Keep the things the same, just the way we like them, because they work for us, and we don’t want to lose our sense of self-importance and power.

Customer complaints are more than just a current quality signal, they are feedback from the environment about emerging needs an organisation should be trying to meet. They show the direction of evolution to be future-relevant.

Types of product strategy

Kind of changing my mind about marginal gains as a product strategy. Maybe in well-established organisations and markets with narrow margins, marginal gains is the right approach. Maybe all those little improvements add up to something big.

The Pareto principle is another concept that’s interesting for product strategy. If the problem space has lots of variability and we think the optimal solution is in standardising the majority of simple use cases and handling the complicated ones by exception, then power law distribution guides that thinking pretty well.

Others might be Hick’s law, which states the time it takes for a person to make a decision as a function of the number of possible choices. Tells you how to make your product strategy about helping users make better choices.

What’s the difference between a topology, an ontology and a taxonomy

Taxonomy

How things are classified

A taxonomy is a structured classification system, usually hierarchical.

  • Focus: Grouping and labelling
  • Structure: Parent–child hierarchies
  • Answers: “What type of thing is this?” and “Where does it sit?”

Example

  • Education → Undergraduate → Level 4 → Module
  • Product → Feature → Sub‑feature

In practice, taxonomies are used for navigation, tagging, filtering, and findability, and are explicitly described in enterprise metadata and taxonomy management work.

Think: A well‑organised folder tree or controlled vocabulary.

Ontology

What things are, and how they relate

An ontology defines:

  • Concepts
  • Properties
  • Relationships
  • Rules or constraints

It goes beyond hierarchy to express meaning and semantics.

  • Focus: Meaning and relationships
  • Structure: Network/graph
  • Answers: “What is this?”, “How does it relate to other things?”, “What can be inferred?”

Example

  • A Module is part of a Qualification
  • A Student enrols in a Module
  • An Assessment is submitted by a Student

Ontologies are widely discussed in research paradigms and in modern data/AI systems because they support reasoning and inference, not just classification.

Think: A shared conceptual model of a domain.

Topology

How things are arranged or connected

A topology describes the shape or structure of connections, without focusing on meaning or categories.

  • Focus: Arrangement and connectivity
  • Structure: Patterns of links
  • Answers: “How are things connected or organised in space or structure?”

Examples

  • Network topologies (hub‑and‑spoke, mesh)
  • Team topologies (stream‑aligned teams, enabling teams)
  • System architectures

In organisational and systems contexts, topology is used to visualise flows, dependencies, and interaction patterns, as seen in team and system design materials.

Think: A map of connections, not meanings.

Side‑by‑side summary

ConceptCore questionWhat it definesTypical use
TaxonomyWhat category?Labels & hierarchiesNavigation, tagging, search
OntologyWhat is it & how does it relate?Concepts & semanticsReasoning, data integration
TopologyHow is it arranged?Structural connectionsArchitecture, systems, teams

Shortcut

  • Taxonomy = classification
  • Ontology = meaning
  • Topology = structure

Or, in one sentence:

A taxonomy sorts things, an ontology explains them, and a topology shows how they’re connected.

Weeknotes 503

I did:

Hourglass

Hourglass was my metaphor of the week, meaning something along the lines of how we pay attention to the little bit in the middle but the big stuff happens either side of it. Make sense? No? That’s why I’m not a poet. I spent my doing this instead:

  • Ran three retros, over four and half hours, for 60 people. Now comes the analysis. I’ve also been live-chatting (it’s like live-streaming but with chat messages) to keep notes on the things I think about when doing a retro in the hope I might turn it into some kind of training.
  • Chatted about the difference between ‘right first time’ and ‘right over time’.
  • Had a great coaching session with a product manager. He had some interesting questions.
  • Got some clarity on the direction of one of our products and I’m really happy with it. Feels like the direction actually takes us towards our goals, which isn’t always the case.
  • Thought about using a ‘min spec’ type workshop to mind map all the aspects of a piece of work necessary for it to succeed, and using that to set the scope and plan of the work. I’m wondering if it might help teams see the bigger picture of product development and that it isn’t solely a technical thing.
  • Wrote an evaluation plan for a feature, including a/b testing it with users and ROI analysis. It might seem like boring stuff but I think it’s part of how you know you’re doing product work because you’re trying to find out if what you shipped is actually solving a user problem, just shipping it isn’t the measure of success.
  • Did some release planning. Checklistastic.
  • Met our new tester. Made me realise that I stopped having intro calls with people. I should start that up again.
  • Finally found a way to bring two of the products I’m working on together. Hope it works.

I read:

Product Management ‘Set Texts’

Tom Dolan’s Product Management ‘Set Texts’ is an excellent list of books product managers should read. Made me wonder how many of them have, and I wonder what the key lessons are from each book.

Economies of scope

Economies of scope is an important idea for product strategy thinking. It says that efficiencies come from variety, not volume. It’s important to remember because the economics of most digital products are based on the idea of software usage having near zero reproducibility costs (build something once and sell it to lots of people), but diversifying based on what you’ve already built gives you two things to sell.

Service Nirvana

Kate Tarling was on the Mind The Product podcast and talked about the challenge of assuming the status quo is neutral and risk-free, which makes it hard to accept change. It grabbed my attention because I don’t think I’d ever realised that point about org change. The other interesting thing Kate mentioned is that although a few companies do some aspects of service really well, there are no examples of organisations doing services well as a whole. I think that tells us something…

Messy docs

Say Yes to the mess!

Autonomous teams

I’m reading lots of stuff autonomous teams at the moment, but Jan Henrik Gundelsby‘s paper on enabling autonomous teams in large-scale agile through architectural principles stood out.

I thought:

Developing a stance

I was looking for patterns in my conversations with other product people and one that comes up a lot is the idea of developing a stance on things. Whether its backlogs or communication or evaluation, just having the knowledge and skills isn’t enough, product managers need to have a stance. Take backlogs for example, it isn’t enough to know how backlogs work, you also need to have a position on what job they do, what are the limitations, what scenarios do they fail, what challenges come up in using them effectively, etc., etc. All of this helps product managers develop their position on backlogs, which helps them shape their product practice intentionally.

Coherence

Product management is about coherence. It’s about bringing all the parts together in a way that makes sense as whole. Its the logical connection between parts of a whole avoiding contradictions and conflicts.

My little library

Found this old collection of 4580 links to things I read over three years ago. It’s like a history of things I was vaguely interested in enough to read about, like innovation in 2020, web3 and blockchain in 2021, and GenAI in 2023.