Concise vs Comprehensive

We analysts are, as a type, deep thinkers who probably do Sudoku puzzles or play Chess in our spare time.  Tell me I'm wrong, I won't be offended.  We logically work from start to finish and we document our steps along the way.  As my Maths teacher used to say, "You have to show your working [or your method]".  We carry this way of thinking into our work as data analysts, website analysts and A/B testing analysts.  "We made this change on our site; this led to these changes in user behavior (comprehensive list), and the overall impact was this.  This breaks down as this, this and this, with these metrics being affected by this change in customer purchases."  I call it good storytelling.

This can take some time, and a number of slides, to explain, and some of our stakeholders really appreciate this level of detail as they generate ideas for follow-ups.  Long-term strategic thinkers (like us) will discuss our findings and then design the next test that should win.  Iteration is your friend.

However, our business and marketing friends - let's call them high-velocity stakeholders - want to know the answers to some much more immediate questions:  "Do we deploy it?" and "How much revenue is it likely to generate?"  Some stakeholders actively want to understand the nuances of the data, but others - usually the senior and more executive levels - have less interest in the finer details, and often don't have time to review all the slides.  

Consequently, we feel the tension between being concise and being comprehensive.  If we don't show the full details (and all our calculations), then we worry that our data will be taken out of context.  True?  (Or to quote my son, "Am I right?")

At the end of the day, what matters to us needs to adapt to what matters to the team or individuals who make the deploy/no-deploy decision.  Our role is to advise, and to make sure that the data has been accurately communicated to the decision makers. It doesn't have to be all the data, just the headlines and the summary - which could be reduced all the way down to a single sentence. "Implement this," or "Do not implement."  If we're faced with the follow-up questions of "Why not?"  (you'll notice that we're never asked why a new feature won, but only why it lost) then that's the time to go to the wider range of metrics.  Have them ready.

It's a lot like a newspaper.  You may remember newspapers from the late 20th century and early 21st century - we had them before the internet ;-)

Headline:  Deploy Recipe C

Subheadline:  New feature shows confident 1.2% conversion lift 

Opening paragraph:  Analysis shows that 'Find out more' wording on new gizmo attracts 2.1% higher engagement rates and this carries through the lower funnel.  Beating out the existing  'Click for details', the new feature reduced exits, bounces and time on page, and experts recommend putting this into production immediately.  Analysis, page 7.

Page 7 then has those wonderful pie charts, bar charts, trendlines and heatmaps that we love, along with additional commentary; segmentation between traffic sources; funnel metrics and everything else.  Are they essential to the story?  No.  Are they beneficial in understanding more about our customers?  Absolutely.  Let's not forget that numbers help us make intelligent guesses about what our visitors are thinking, but if all your audience want is the number with the dollar sign, then understanding customer behavior is secondary to the point of unimportant.

It's no criticism of our work that our high-velocity stakeholders only want the headline and the recommendation.  It's more a reflection on current culture - Social Media Attention Span Statistics show us that we live in a generation where users watch a TikTok video for 11 seconds before scrolling; and average online attention span is now less than that of a goldfish (if you've read this far, I guess that's a credit to both of us!).

Additionally, high-velocity stakeholders are often under pressure to hit targets that are further and further away.  The sense of urgency from executive-level meetings filters down to lower level meetings, where the need for action can overtake the need for a calm, measured approach to data analysis.  Lower-level execs and directors are looking for something - anything - to help them achieve their targets for the month/quarter/year, and any glimmer of uplift is going to be seized upon.  Equally, losers get short shrift too, because 'why are we even analysing something that lost?'.  The answer to that is 'so that we can learn and get it right next time', but that takes time against a looming deadline. 

So how do we encourage our high-velocity stakeholders to pay attention to our full analysis?

1. Lead with headline.  Start with the conclusion.  BLUF:  Bottom Line Up Front.  Do all those things that we were taught not to do in maths and science classes; start with the QED.  If this was a film, it would be the dramatic ticking bomb about to explode - followed by the "24 hours earlier...".  Get their attention, and make sure that if they leave your presentation after five minutes that they at least got the result.  Do your best to hook them, but don't worry if you don't manage it.

2. Put less on each slide, especially less text.  Graphs and charts are good, text isn't.  I could spend a lot of time on visualisations, but not today - you can read my previous post about good data visualisation.

3.  Stick to the point.  Keep your sentences short, and call out only the headlines for each slide.

4. Ask a question at the end of each slide, and answer it on the next one.  Give your audience a hook to keep them interested.  "So why did conversion go up 1.2% across the site?"

5. Do not be afraid to jump around the sequence of slides.  You may be trying to tell a story and logically connect your slides (see point 3 directly above) but if your audience want to know how the paid search traffic performed, then jump immediately from slide 4 to slide 9.  Just do it.

6.  Remember what the audience priorities were last time you presented an analysis.  You might think that this is a checkout test, but if the stakeholders kept asking about marketing spend, return on investment (ROI) or keyword performance, then bring your marketing analysis to the front.  You are NOT going to change business priorities through the sequence of your slides, you're just going to test the attention span of your audience.

7. Sometimes, being high-velocity is a personality type.  Call it intuitive vs deliberative; call it judgement vs perception.  You aren't going to change it, so compromise and adapt.

Other posts I've written about online metrics and testing:

Web Analytics - Requirements Gathering
One KPI Too Many - why you need a critical few
Why too many cooks spoil the A/B testing roadmap

Battleships and A/B Testing

When you picture a strategic board game, the first thing that often comes to mind is the timeless pen‑and‑paper showdown known as Battleships.  Two players plot secret fleets on a hidden grid, then take turns calling out coordinates in hopes of sinking their opponent’s fleet. Oddly enough, the same logic that underpins this nostalgic pastime also powers the modern marketer’s most valuable tool: A/B testing.  But you knew I was going to say that in this blog, right? ;-)

There are some obvious and some obscure similarities between a round of Battleships and the iterative process of optimizing complex elements of a website, such as a navigation menu or a landing page, or a series of products on a category page. I've observed that it can take a blend of hypothesis, random probing (or sometimes just gut feel) and data‑driven refinement can turn a handful of menu items into a high‑performing traffic‑masterpiece.  You aren't going to hit the perfect combination first time, but you aren't going to have to work out all the combinations (some of them just don't make sense) to get to the optimum answer fairly quickly.

 

The Playing Field: The Grid and The Page Layout 

 

Both scenarios start with an unknown distribution. In Battleships you lack any clue where the opponent's fleet sits; on a fresh website (or on a site component that you've not tested before) you have limited insight into which menu label will attract the most clicks.  Or, you may have extensive data on engagement with your menu options, but you don't know what the most effective sequence might be.  

The first step in both games is to gather information, and the most straightforward way to do that is to make a series of probes. 

  

Random or “Best‑Guess” First Moves 

 

A seasoned Battleship player knows that a completely random first shot is often a good baseline. It gives an unbiased sample of the board and avoids early bias toward a particular quadrant. Likewise, when devising an A/B test on a navigation menu, we have to start with a baseline version (Recipe A, the current state).  This is where we start, based on the original agreed sequence for the menu (or the one that was agreed or imposed most recently).   Your first test recipe - your first guess, or challenger - will be the best guess from existing UX guidelines, past experience, engagement data, clickstream analysis or competitor analysis. Please, please, let it have some form of data backing: it's not essential, but it will certainly help.  At this stage, it's perfectly fine (in fact, it's better) if you have multiple hypotheses on the go... everybody devises a recipe, and you select the best for testing.  The number of recipes you can test will depend on your traffic, but at this stage you want to maximize your options.

I mean, wouldn't Battleships be quicker (and more exciting) if you got to pick three or four co-ordinates per turn, instead of just one?

 

Does the the randomness matter? 

 

At this point, you're focusing more on exploration, and less on exploitation.  Random probes let you explore the unknown space before focusing on promising areas.  More importantly, you'll avoid premature convergence: if you jump straight to an “obvious” menu order, you may lock yourself into a sub‑optimal layout before you ever see the data.  One things that's very important at this stage is to test more than one new idea - in Battleships, this would be like shouting out four or five guesses each turn.  A scattershot approach in your testing will yield the fastest results - you're not necessarily aiming to find a winner immediately, this is about testing a range of different hypotheses.  Will colour be helpful? Which item should go first in the list?  Which should go in the middle?  

The First Hit: Discovering a “Ship” 

 

When a player announces “B5: hit!” they’ve uncovered part of a ship. This moment gives them very specific information: a ship occupies that cell and, by the rules, must extend either horizontally or vertically. 

 

In A/B testing, the equivalent is a statistically significant lift in a key metric, for example, a 6 % increase in overall click‑through rate (CTR) for the new menu order. That lift tells you three things: 

 

1. Presence – The altered ordering resonates with users. 

2. Direction – The change (e.g., moving “Pricing” closer to the left) is beneficial. 

3. Potential shape – The magnitude of uplift hints at how many “cells” (menu items) may still be optimized. 

 

Just as a Battleship player deduces the ship’s orientation after the first round of hits (if they're lucky, or clever), the marketer can infer which type of change matters most: position, wording, visual emphasis, or grouping. 

 

Targeted Follow‑ups: “Scanning” Around a Hit 

 

In the game, once you have a hit you start probing the adjacent squares (B4, B6, A5, C5) to determine the ship’s shape. Each subsequent coordinate is a targeted test rather than a blind guess.  You shift from random guessing to focused fire, and A/B testing follows the same pattern: 

 

Recipe B in the first test showed an initial improvement (e.g., swapping “Products” and “Solutions”). 

In the second test, you can start tweaking other items in the list.  Remember that the number of possible permutations is far more than you would expect (and with just a few items in your list, the total will exceed a 10x10 Battleships board) so you're not going to hit on the perfect winner immediately (unless you are spectacularly lucky).
 

These follow‑up experiments are nested or sequential, concentrating resources on the most promising hypotheses. The data you collect after each iteration narrows the “search space,” just as each new coordinate reduces the number of possible ship layouts, and continues to point you in the right direction.  This is where multiple recipes are important in each test - you'll need to triangulate your results, not just make one-off guesses.  Multiple recipes with one or two differences between them will help you understand what matters, what helps and what makes things worse!

 

 

Mapping the “Board”: Heatmaps, Click‑maps, and Probability Grids 

 

Advanced Battleship players may use a probability heat‑map that shows where ships are *most likely* to be hidden, based on prior hits and the rules of ship lengths.  This takes a simple game and makes it remarkably complicated, but if you're up for a challenge, it's worth a try.

 

Similarly, modern website analytics provide heatmaps and click‑maps that visualize where visitors tend to gravitate. Tools such as Hotjar, Crazy Egg, or built‑in Google Analytics “Behavior Flow” generate a probability surface over the navigation bar: 

 

When you overlay this visual data onto your A/B test results, you get a dual feedback loop: the statistical lift from the test and the qualitative ink‑blot from the heatmap. Together they guide you toward the next set of coordinates (menu tweaks) with a higher chance of “sinking” the under‑performing items. 

 

 

Defining Victory: From “Sinking a Ship” to “Winning the Funnel” 

 

In Battleships, you win by sinking all opponent ships. In navigation optimization, the win condition is more nuanced, and long-time readers will immediately think of my articles on KPIs - do you have enough KPIs; has everybody agreed on the KPIs, and do you have too many? 

 

Primary goal: Increase CTR for a strategic link (e.g., “Contact”). 

Secondary goals: Reduce bounce rate, shorten time‑to‑conversion, improve overall conversion. 

 

When a series of tests successively “sink” the low‑performing placements and elevate the high‑value ones, you achieve a balanced funnel: the menu now routes users efficiently, minimizing friction. 

 

 The Role of Iteration: The Game Never Truly Ends 

 

Even after every ship is sunk, seasoned players often start a new round, perhaps with a different grid size or ship configuration. Likewise, once a navigation menu reaches a satisfactory conversion rate, the digital landscape continues to shift: new products launch, branding evolves, and user expectations change.  Marketing introduce a new product; a new menu item is added as new features, products or services are promoted.

 

Continuous A/B testing becomes a maintenance routine, akin to a never‑ending Battleships campaign. Each new feature or redesign is a fresh fleet to place, and every subsequent test is another salvo.  Sometimes, it can feel like you're hitting moving targets, which certainly makes things more challenging, and you need to think about the principles you've learned, not just the specifics.

  

Takeaways 

 

* Uncertainty is a feature, not a flaw
Both Battleships and A/B testing thrive on systematically reducing unknowns. 

* Start simple, then target
A modest random or best‑guess change gives you a baseline, after which data‑driven refinements pay off. 

* Visual probability aids decision‑making
Heatmaps for navigation function the same way as ship‑probability grids in the classic game. 

* Iterative loops lead to mastery
Each successful test recipe brings you closer to an optimal menu, just as each hit brings you closer to sinking a ship. 

* Never stop playing
The digital environment evolves; continuous testing keeps you ahead, much like an endless series of Battleship rounds. 

 

Final Thought 

 

Next time you stare at a spreadsheet of A/B test results, imagine yourself peering over a Battleships board. Each data point is a coordinate, each statistically significant lift a “hit,” and each subsequent experiment a strategic scan for the rest of the vessel. By embracing the game‑like mindset of exploration, hypothesis, and disciplined iteration, you’ll transform a simple website feature into a high‑performing conduit, efficiently guiding visitors precisely where they want to go, and where you'd like them to go, too.

 

(Happy testing, and may your next “shot” be a clean hit!)

Similar posts I've written about online testing

Getting an online testing program off the ground
Building Momentum in Online testing
How many of your tests win?

Why Average Order Value Misleads in A/B Tests

 Why Average Order Value Is Lying to You in A/B Tests, And What to Do About It

 Working in ecommerce, Average Order Value is almost certainly one of the key metrics we use to evaluate A/B tests. When we’re deciding whether Recipe B outperforms Control, AOV offers a clean, definitive answer. One number. Higher is better. We sold more items per order, revenue went up, AOV went up.  After all, Average Order Value is defined as Total Revenue divided by Total Orders.  If AOV went up, then Revenue went up too.  Implement Recipe B.

However, we have a slight problem: AOV, taken in isolation, is potentially one of the most misleading KPIs you can use to call a test winner. It can ‘identify’ a clear winner when the reality is far more complicated. And it can show no meaningful difference between two recipes while something fundamentally important is happening beneath the surface. 

Why? AOV is a mean average. And mean averages, as any statistician will remind you (and as we all learned and then forgot from school), are dangerously susceptible to skew, a problem that becomes especially treacherous when you are making binary implement-or-abandon decisions based on test results.

The Problem with a Single Number

Let’s take a simple example. Imagine you are running an A/B test on your product detail page. After two weeks, you pull the results and compare order values across both recipes.

Control (Recipe A) recorded the following ten orders:

$15, $18, $22, $25, $30, $32, $35, $40, $45, $50

AOV for Recipe A: $31.20.

 

Recipe B recorded these ten orders:

$8, $10, $12, $14, $16, $80, $85, $90, $95, $100

AOV for Recipe B: $51.00.

Here's how it might look with 30 orders per recipe:

Scale up accordingly, and think about 100 orders, or 150.  The volumes become more ‘real’ but the underlying problem stays the same (yes, even larger sample sizes can suffer this kind of systemic skew).  On the surface, this looks decisive. Recipe B delivers a 63% uplift in AOV. If this is your headline metric, you are shipping Recipe B today and writing up a case study by Friday.  And we all love those case studies (although 63% uplift isn’t as good as the 197% conversion uplift that a promotional case study will tell you is possible with A/B testing!).

 But look at what  happened. Recipe B produced a polarized order distribution. Many of its customers spent considerably less than Recipe A's lowest order, while the other half spent considerably more. The mid-range products, which could represent the the core of your catalogue have seemingly disappeared from the basket entirely. The average went up, but the underlying customer behavior shifted in a way that deserves scrutiny, not celebration.

And let’s not forget to  look at what the test was trying to achieve.  Were you actively promoting your mid-range products?  Were you offering a promotion on the higher-price products?  Did your test just become a spectacular winner or a tragic loser?

Or did you make a design mistake?  Was Recipe B's design inadvertently confusing for some segments while upselling effectively to others? Did it suppress mid-tier product discovery? These are critical questions, and AOV alone will never surface them. It compresses a complex distribution into a single data point and, in doing so, strips away the nuance that should  inform your decision.

How Skew Distorts Test Results

There are several real-world scenarios where AOV can mislead your A/B test analysis.

A few high-value outliers inflate the winning recipe.

Perhaps Recipe B happened to capture three bulk-buying customers or a couple of corporate purchasers. Those handful of transactions dragged the average up, creating the appearance of a meaningful uplift. Meanwhile, the typical customer in Recipe B  spent less than their counterpart in Recipe A. You are about to ship an experience optimized for edge cases.  If you’re going to do that, then perhaps it’s time to consider targeting (or personalization – it seems to me sometimes that the correct term to use depends on who’s doing it and how targeted it is).

Both recipes perform similarly in the middle, but diverge at the extremes.

Recipe B might be driving more entry-level impulse purchases while simultaneously encouraging a small group of high-intent buyers to add more to their baskets. AOV looks higher, but the majority of your customers are spending less. The "improvement" is an illusion created by a handful of power users subsidizing the average.  Again, is it time to segment your visitors based on the products they’re viewing, and serve the winning recipe to the users who are making those entry-level purchases?  And let’s not forget the high-intent buyers.  They represent the kind of customers that AOV was created for – we assume AOV means ‘customer added more to their order’ and in this case, that’s exactly what’s happening.

In each of these cases, AOV gives you a number. It does not give you a reliable basis for an implementation decision.  We need to unlearn that assumption that AOV means ‘customer added more to their order’ and look more closely at the data.

The Case for Price Band Analysis in A/B Testing

This is where price band analysis becomes essential. Rather than calculating a single average and then comparing between Recipe A and Recipe B, price band analysis involves segmenting orders from each recipe into defined value brackets — for example, $0–$20, $20–$50, $50–$100, $100–$200, and $200-plus — and then comparing the volume and revenue contribution of each bracket across both experiences.

This approach gives you something AOV never can: distribution visibility.

When you evaluate your test through price bands, you can answer questions and decide whether a result is genuinely actionable:

- Is Recipe B's AOV uplift broad-based across all brackets, or is it being driven by a single band?

- Did Recipe B improve high-value orders at the expense of your mid-range core?  Or did you genuinely shift mid-range customers into the high-price band?

- Are you seeing a volume shift into lower bands that is being masked by a few large transactions?

- Does Recipe B's distribution align with the customer segments that your test was intended to target?

- Is the "winning" recipe creating a more fragile revenue profile by concentrating performance in fewer, larger orders?

These are the questions that separate a genuine optimization win from a statistical mirage. AOV alone cannot answer any of them.

Practical Implementation

For most experimentation teams, layering price band analysis into test evaluation is not technically difficult. It requires defining sensible brackets that reflect your catalogue's price architecture, and then building a view, which cold be in your testing platform's reporting, your BI tool or your spreadsheet, that breaks down order count, revenue, and share of total by band for each recipe.

The brackets themselves matter, because they should be meaningful to your business rather than arbitrary round numbers. Look at your product pricing structure and your historical order distribution to define bands that separate genuinely different purchase behaviours. A luxury fashion retailer and a toy retailer will need entirely different frameworks.

 Once established, review the bands alongside AOV. Don’t abandon AOV, because it still has a role as a quick directional signal during a test. But it should be the starting point for investigation, not the final number. When AOV is different between recipes, your first response should be to open the price band comparison and understand why it differs. Is Recipe B lifting performance across the board, or is the uplift concentrated in a single bracket? Is the change driven by many incremental improvements or by a handful of outlier transactions that may not replicate at scale?

This is especially important when you consider that we run our A/B tests for a limited period of time. The smaller your sample, the more susceptible AOV is to skew from a few extreme orders, so again, consider this when you ask the question ‘how long should I run my test for?’. Price band analysis acts as a critical sanity check, helping you distinguish between a robust, replicable improvement and a result that is being propped up by noise.

Making Better Test Implementation Decisions

There is a broader principle at play here, and it is one that experienced experimenters already know instinctively: any metric that compresses complexity into a single number should be treated with healthy skepticism when making shipping decisions.  AOV is not unique in this regard; conversion rate and revenue per visitor (or per visit) all suffer from similar issues. They are useful as signals, but dangerous as conclusions.

The best experimentation teams treat AOV as a tier-one indicator, which is worth monitoring for directional movement, but you need to build out your recommendation and rationale on the richer, more detailed data sitting underneath it. When you present test results to stakeholders, showing a price band comparison between recipes tells a far more compelling and trustworthy story than a single percentage uplift ever could.

Price band analysis is not a radical new technique. It is straightforward, practical, and surprisingly underused in A/B test evaluation, given how much it reveals. If AOV is currently your primary metric for judging test winners, consider what would happen if you supplemented it with a price band distribution comparison. The decisions it informs will be more confident, more nuanced, and ultimately more valuable to your business, because in experimentation the most dangerous result is not the one that is wrong. It's the one that looks right but leads you to implement an experience you don’t fully understand.

Other posts I've written about online metrics and testing:

Web Analytics - Requirements Gathering
One KPI Too Many - why you need a critical few
Why too many cooks spoil the A/B testing roadmap

How Valuable Are Your Meetings?

Work means meetings

Work means meetings.  It means meeting with any combination of your team-mates; your manager and colleagues from other departments (developers, designers, project managers, strategists, architects, builders... you name them, they want to talk to you). 

If I had a dollar (or a pound, or a Euro) for each time I've heard "Can I get 30 minutes of your time?" then I'd be a very wealthy man.  If I included times when I've been given a cold call or an unsolicited email from a supplier asking to get on my calendar, I'd be extremely wealthy!

Which brings me to the point:  how much do you and your leadership value your working time?

How good are your meetings?

Let's suppose I'm paid $60 per hour.  Nice, right?  But it will work for the numbers - I get paid $1 per minute to do my job.  To sell more stuff.  To design more stuff, or to develop more stuff.  My job description says sell/design/develop/build stuff, and I get paid $1 per minute to do that.

But if I get dragged away from my role to attend a meeting, then I have to hope that the meeting I'm attending will be worth the time I'm spending not doing my normal role (unless that meeting is actually part of the design/build/sell activity I normally do).

So I get pulled onto a call for all the managers in my department.  It's a 30-minute call.  Sadly, it's not actually relevant to my role, so the business is paying me to do something that's not part of my actual role.  In fact, it doesn't apply to about 20 of the 40 managers in the meeting, and they're all getting paid the same as me.

20 managers.  $1 per minute, per manager.  30 minutes?  Total cost: $600.

For a meeting that lasts 30 minutes.  Now imagine that it lasts an hour; now it's costing the business $1200.  It's an hour that could have been spent building/selling or whatever.  But why did it happen?  Because leadership determined that it was more important for you to hear what they said instead of doing what you normally do.

Now imagine it's an 'all hands on deck' meeting.  Or a 'strategic communications' presentation, and you invite 100 managers, and it lasts 30 minutes.  It needs to span the entire business strategy to be relevant to everybody; for each manager that it doesn't apply to, that's $30 at risk, and if it isn't relevant to any of them (or if it's a repeat of last month's meeting) then that's $3000 at risk.

So what do you do?

When you call a meeting with an individual, you're pulling them away from their normal role to meet with you.  You know the job you hired them to do?  You're now preventing them from doing it. 

Or perhaps you're arranging a meeting with your full team - of managers, who get paid $60 per hour - you need to make absolutely certain that the meeting you're hosting is going to be at least as valuable to them (and to the business) as their normal work.

And if it isn't?  In that case, there's definitely a strong argument for an asynchronous communication method.  Email... Teams chat... Video plus transcript... it's your choice, but it gives your team the choice of when to consume the content.

"But," you say, "The content is so important I need to be sure they've consumed it!"  

If you can say that for sure, then it's definitely time to hold a meeting.  However, as a gentle suggestion, please make sure that you're not confusing 'the content' with 'my opinion'.

But why aren't your attendees participating?  Are you just talking for 30 (or 60) minutes?  You've been hired to lead, support and manage - not to perform a 30-minute monologue to a tough audience of colleagues who are finding your material irrelevant and uninteresting.  If you have eight people on your team, and you pull them out of their work for an hour to attend your meeting, you have cost the business the equivalent of one full day of work.

Or imagine you call a meeting for 40 people, for an hour.  You've just taken the equivalent of one week's work out of the business, no matter how much that costs.

Consider this:  if your organization is so large that you invite 400 people, and they all turn up at 8:00 am sharp for your meeting, and you don't start until 8:05 am, then that's the equivalent of over four days of work that you've wasted.  

And if your content doesn't apply to a quarter of that audience, and your meeting lasts for an hour, then 100 hours of work got stuck in a meeting it didn't want to be in, when it could have been doing its job.

So, what should you do?

Make your agenda more inclusive. 

If you're inviting everybody, then make sure your message applies to all of them.  Talk to the builders, the designers, the developers, the sellers.  Talk to the team that sells over the phone.  Include the team that manages the stores.  

If you can't be more inclusive with your agenda, then be more selective with your audience. 

Do you typically invite all the managers in your department?  Look at the agenda, look at who you're inviting:  do they match?

If you have a guest speaker, ask them to fully introduce themselves; to explain what they do, and to explain why it's relevant to the audience.  Context over content, this time.

Think about it: the more people you invite to a meeting, the more you're costing the business and the harder you're going to have to work to be relevant to everybody.  It's worth the effort, but make sure you're actually putting the effort in.

Other topics I've posted on that may be of interest to you:

Project Management: A Trip To the Moon (when meetings go wrong)
Team-building exercises with Remote Workers

Arsenal's Disciplinary Record

Here's an interesting fact, brought to you by the wonders of social media:

Arsenal, Premier League Champions for 2025-26, had no red cards and no penalties awarded against them throughout the season.

And immediately, social media jumped on the bandwagon with the long-standing VARsenal - the claim that the Video Assistant Referees for the Premier League were in some way biased in favour of Arsenal, and hence any debatable or controversial decision would go in their favour.

So:  how unusual is it for a team to have no red cards, and to have no penalties against them in a season?

To answer this one, we're going to need some data, and fortunately the internet is full of it.  I've looked at football data before, and for some reason, gambling sites tend to keep the best records.  Here's the data on red cards first, taken from MyFootballFacts.com.

2025-26 Red Cards by Clubs			2025-26 Yellow Cards by Clubs
Club	No.		Club	No.
Chelsea	8		Tottenham Hotspur	98
Everton	4		Chelsea	90
Tottenham Hotspur	4		AFC  Bournemouth	88
Burnley	3		Brighton & Hove Albion	86
Manchester United	3		Sunderland	82
Newcastle United	3		Wolverhampton Wanderers	77
Sunderland	3		Fulham	75
West Ham United	3		Crystal Palace	74
Wolverhampton Wanderers	3		Everton	72
AFC Bournemouth	2		Brentford	69
Crystal Palace	2		West Ham United	68
Aston  Villa	1		Manchester City	67
Brentford	1		Burnley	64
Fulham	1		Newcastle United	63
Leeds United	1		Leeds United	62
Liverpool	1		Manchester United	62
Nottingham Forest	1		Nottingham Forest	60
Arsenal	0		Aston Villa	58
Brighton & Hove   Albion	0		Liverpool	57
Manchester City	0		Arsenal	51
Total  Red Cards	44		Total  Yellow Cards	1423

Summary of initial findings:

Red cards

It's not impossible for a team to complete the season with zero red cards:  Manchester City and Brighton also achieved this result.  It's rare, with only three out of the 20 teams having a clean sweep, but it's not unheard of.

Average per team is 2.2 red cards per season.  Standard deviation = 1.88
Arsenal are only just outside one standard deviation of the mean, so it's certainly not a statistical outlier - it's still possible.

Chelsea fans might have more of a case of bias against them, with 8 red cards against the average of 2.2, as they are just outside three standard deviations from the mean, making them a definite outlier.

Yellow Cards

Arsenal had the fewest yellow cards (or "bookings"), with 51 against a Premier League average of  71.15.  Spurs had 98, and Chelsea accumulated 90.  It seems that their performance in the Red Card Table is consistent with their overall behaviour.

Penalties Conceded

CLUB PKC

Brentford 8

Burnley 8

Crystal Palace 7

West Ham 7

Bournemouth 6

Brighton 6

Leeds 6

Nottm Forest 6

Newcastle 5

Wolves 5

Everton 4

Fulham 4

Liverpool 4

Man United 4

Sunderland 3

Tottenham 3

Aston Villa 2

Chelsea 2

Man City 2

Arsenal  0

Now this is a more interesting data point.  Arsenal were the only team in the Premier League not to concede a penalty kick in the season.  Whatever Chelsea were doing to get their cards, they were doing it outside the penalty area and hence only conceded two penalties throughout the season. 

The average was 4.6 penalties conceded per team for the season, so 0 is a noticeable outlier.  A follow-up question is - how many times did Arsenal's opponents have possession in their penalty area?  The metric which is measured here is how many times did an opposition player touch the ball in Arsenal's penalty area?  Arsenal had 1228 touches conceded in the season  (32 per game, and third lowest in the League), so it makes sense that they conceded fewer penalties.

Conclusion

So, Arsenal won the league by keeping their opponents out of their penalty area - leading to no penalties conceded - and by playing a careful game with few reckless challenges and no sendings off.  There's no statistical indication of bias or unfair treatment towards them by the referees; the average for the Premier League was 2.2 red cards in the season, and zero is well within an expected distribution (unlike Chelsea, who have a stronger case for harsh treatment, based only the numbers).  Protecting their penalty area enabled them to concede fewer penalties in the season, and they had no sendings off.

The follow-up question (for another time) is how often do teams win when they've had a man sent off, compared to keeping all 11 men on the pitch?  I'll look into it!

More posts on football data:

Port Vale 0 Arsenal 2 match report

English Premier League: Which Season Ticket is the Best Value?

Real Life testing and KPIs - Manchester United