The core idea was simple: you have to respect how Excel users already think.

When Excel users reach for Python, they are not looking to become Python developers overnight. They are looking to extend an existing mental model. They want something that fits naturally into their current stack, workflows, and instincts.

Unfortunately, a lot of Python in Excel training today misses that point. Much of it is essentially Python 101 with an Excel veneer. The training never really grapples with Python in Excel’s unique role inside the analytics stack.

That’s why I was excited to come across Python in Excel: Unlocking Powerful Data Analysis and Automation Solutions by Liam Bastick and Kathryn Newitt over at SumProduct.

There are many Python in Excel resources on the market, but this one stood out to me for how clearly it centers Excel users and their existing workflows.

Python in Excel as a natural progression, not a detour

What this book does exceptionally well is treat Python in Excel as a continuation of Excel’s analytics story rather than a bolt-on. The authors frame Python in Excel as a natural evolution of familiar tools from formulas and PivotTables to Power Query to Analyze Data and beyond.

Python doesn’t exist in a vacuum here. It is presented as another layer in Excel’s BI and analytics capabilities, not a replacement for what users already know.

Crucially, the book walks through how Python in Excel fits into real-world Excel workflows such as importing data from Power Query, working explicitly with tabular data (where Excel users actually live), and using Copilot effectively alongside Python.

That grounding makes a huge difference.

Constraints explained (and why they’re helpful)

Another strength is how clearly the book explains Python’s origin as an open-source ecosystem, and what that implies for packages, dependencies, and tooling.

Just as important, it explains why Python inside Excel comes with constraints, and why those constraints can actually be a feature. By limiting scope and environment complexity, Python in Excel becomes more approachable, safer, and easier to operationalize for everyday analysts. That framing helps users understand not just how Python in Excel works, but why it works the way it does.

Practical first, powerful later

What also works so well here is the sequencing. The book starts where Excel users actually live: structured tables, practical data manipulation, and quick analytical wins. That gives readers early confidence and a clear mental model for working with data, rather than throwing advanced concepts at them too soon.

By covering summaries, visualization, and common gotchas early, it helps readers avoid frustration and build good habits. Only after that foundation is in place do ideas like UDFs and control flow make sense. At that point, they feel like natural extensions of familiar workflows, not abstract hurdles. The book gets that progression right, which keeps it approachable without watering it down.

What I especially appreciated is how closely this aligns with how I try to teach Python in Excel myself: start with tabular thinking, real Excel workflows, and fast wins, then layer in power once the mental model is in place.

Final thoughts

This is a thoughtful, well-structured, and genuinely Excel-native approach to Python in Excel. It respects Excel users. It respects their workflows. And it shows Python in Excel not as a foreign language, but as a powerful extension of tools they already trust.

Bravo to Liam and Kathryn. I’ll absolutely be recommending this book to readers who want to understand Python in Excel the right way.

The post How to learn Python in Excel the right way (book review) first appeared on Stringfest Analytics.

As I discuss in the post, much of this training moved too quickly, failed to connect new ideas to how Excel users already think, and often framed spreadsheets and programming as an either or decision rather than complementary tools.

Five years later, Python now runs directly inside Excel. The tooling has changed, but the same instructional mistakes are resurfacing, sometimes with even greater consequences.

A problem that predates Python in Excel

Excel users are not starting from scratch. They already work with data every day: they group, filter, join, reshape, and analyze information in ways that map closely to what Python does well.

What they lack is not analytical reasoning, but familiarity with a different execution model and a different vocabulary for expressing ideas they already understand.

When instruction ignores this and treats Python as a completely new way of thinking, learners are pushed toward memorization rather than transfer. That is why so much “Python for Excel users” content could just as easily be labeled a generic introduction to Python. There is often nothing in it that meaningfully reflects the spreadsheet mental model.

Conceptual bridges that should be made explicit

Good instruction makes these mappings visible rather than implicit:

When learners see these connections, Python feels less like a foreign language and more like a different way of expressing familiar ideas.

In fact, this idea of helping learners understand Python by anchoring it to what Excel users already know was a major driving force behind Advancing into Analytics, which came out that same year.

A lot has changed since then. Python is now in Excel, and I probably would not spend as much time (if any) on R today. Even so, I still think the core choice was the right one. I focused on statistical analysis of tabular data, not control flow or user-defined functions right out of the gate.

Python in Excel is neither Python nor Excel

Python in Excel is not simply Python, and it is not Excel with a new syntax layered on top. It occupies a middle ground that comes with specific constraints.

Python in Excel is:

• vectorized by default
• tabular and grid-oriented
• optimized for analysis rather than application development

These characteristics should shape how it is taught. Treating Python in Excel like a notebook environment or a general scripting language creates confusion. Treating it like advanced Excel does the same. It needs to be approached as its own analytical surface.

After all, the audience here is not pure programmers. It is data analysts, and that is a fundamentally different user base. The pandas and Anaconda communities understood this early on, which is why they made deliberate choices around defaults, APIs, and workflows that prioritize data work over software engineering concerns.

Python in Excel takes that same philosophy a step further by meeting analysts exactly where they already work. It removes environment setup, lowers the cognitive overhead, and keeps the focus on manipulating, analyzing, and visualizing tabular data rather than learning programming for its own sake.

Why starting with abstraction often backfires

A common temptation is to introduce compact or idiomatic Python constructs early, often in the name of efficiency or best practice.

List comprehensions are a good example. They are powerful once a learner understands how data flows through a transformation. For many Excel users encountering Python for the first time, they remove visibility into intermediate steps and make debugging harder than it needs to be.

In practice, this leads to predictable questions:

• When would I actually use this?
• How do I inspect what happened at each step?
• How do I explain this to someone else on my team?

These are not signs of resistance. They are signs that abstraction has arrived before understanding.

What actually creates early traction for Excel users

Python in Excel tends to click when it delivers immediate value on problems Excel users already recognize.

Some examples of early wins that consistently resonate include:

• running a missing value analysis across an entire table to surface patterns that would take many formulas to uncover
• generating pair plots to explore relationships between variables in ways that are cumbersome or brittle to build with Excel charts
• reshaping messy, multi-header data into clean analytical tables with readable transformations
• performing exploratory analysis that complements PivotTables instead of replacing them

These use cases matter because they answer the most important early question: why would I use this instead of staying entirely in Excel?

If you want a quick, approachable, and affordable introduction to more than a dozen of these quick-win use cases, check out the course I put together with that exact focus:

Once that question is answered, learners are far more open to learning deeper ideas later.

Sequencing matters more than completeness

Many courses try to be comprehensive too early. They aim for coverage rather than durability. In my experience, Python in Excel instruction works best when it follows a deliberate sequence:

The first stage, Foundation, is about establishing trust in the tool. Excel users need to see quickly that Python in Excel helps them do things they already care about, only faster or more cleanly.

Tasks like scanning an entire dataset for missing values, summarizing distributions across many columns at once, or generating pair plots to explore relationships give learners immediate feedback that Python is worth the effort. These wins are visible, concrete, and easy to reason about. At this stage, the goal is not sophistication but confidence and relevance.

Once learners are comfortable producing useful results, the focus naturally shifts to Integration. Here, the emphasis is on understanding how results are produced, not just that they appear. Excel users are used to seeing intermediate states. They expect to be able to inspect, trace, and explain their work.

This stage reinforces those instincts by slowing things down and making data flow explicit. Learners see how transformations build on one another, how intermediate results can be examined, and how small changes affect outcomes. The payoff is work that is debuggable and explainable, which matters far more in a business setting than compact code.

Only after those foundations are in place does it make sense to move into Expansion. This is where control flow, abstraction, and reuse enter the picture. At this point, learners have enough context to understand why loops, conditional logic, or reusable functions exist and when they are actually helpful. These ideas stop feeling abstract because they are clearly tied to real analytical problems the learner has already solved. Generalization becomes a natural next step rather than a confusing leap.

When taught in this order, Python in Excel feels like a natural extension of existing skills instead of a foreign language that has to be memorized all at once.

Why this matters for organizations

When training is poorly sequenced, the symptoms show up quickly. Adoption slows because analysts are unsure when to use the new tool. Early solutions look impressive but are fragile, difficult to explain, and hard for others to maintain. As a result, teams find themselves retraining the same concepts repeatedly without ever reaching a point where the capability compounds.

Well-designed instruction produces a very different outcome. Teams reach useful results sooner because early wins are tied to real business problems. Analysts are able to explain not just what they built, but why it works, which reduces risk and improves trust in the output. Over time, Python in Excel becomes part of a durable analytical workflow rather than a short-lived experiment that quietly fades after the initial rollout..

How I work

This perspective comes from years of teaching Excel users inside real organizations. My focus is on judgment, sequencing, and practical wins that make new tools usable rather than intimidating.

If you are responsible for upskilling analysts and want Python, AI, and Excel to work together in a way that actually sticks, you can learn more about my approach here:

Python in Excel is extraordinarily powerful, but only when it is taught as the distinct analytical tool it actually is.

The post How to teach Python in Excel so it sticks first appeared on Stringfest Analytics.