Blog

What is a product, really? If you're a Scrum product owner who's supposed to be on the hook for maximizing value, you'd better be clear on what you actually own. This piece tackles a confusion that runs deep in product development: the conflation of product, platform, project, and service. Drawing on Bas Vodde's idea that "a product does not have scope" and Craig Larman's framing that a product is something an external customer recognizes and pays for, it offers definitions from the Kanplexity guide for product, platform, and service — and explains why the distinction matters. Why is your CRM not a product? When does a platform become a product? And why does it all come back to one core question: are you worrying about the short term or the long term?

There's a critical difference between opinions and evidence — and even smart people inside the building often confuse the two. Customers don't know what they want, so how do we figure out what they actually need? This piece explores when to trust internal expertise, when to just build something, and when to run experiments instead. Drawing on Jeff Gothelf and Joshua Seiden's prioritization canvas from Lean UX, it offers a simple two-dimensional way to think about value and the risk of harvesting that value — and a clear answer to the question every product team wrestles with: when is it time to experiment?

Scrum has been used in all kinds of domains, and the 2020 Scrum Guide made that reach even broader by removing most references to software. But "used widely" isn't the same as "works everywhere." There's one specific constraint that determines whether Scrum will actually serve you — or whether you'd be better off looking somewhere else entirely.

A mature product living on autopilot and a brand-new product searching for its first customer aren't just at different lifecycle stages — they live in entirely different complexity domains. Mapping Cynefin onto the product lifecycle reveals a pattern worth paying attention to: what works for one stage can be actively dangerous in another. And assuming you're in a simpler space than you actually are is one of the fastest routes into chaos.

Most product owners in the world are scribes or proxies, which means they don't have much real power. Pretending otherwise doesn't fix it — but there are two coping strategies that can help. One borrows a concept from Large-Scale Scrum, the other is a simple "speak now or forever hold your silence" meeting that can buy you real authority for a sprint at a time.

The phrase "product owner" hides a wide range of realities. Some are scribes — taking orders they know are wrong. Others are proxies, business representatives, sponsors, or the rare "CEO of the product" who can actually make decisions — and understanding which one you are is the starting point for doing the job well.

Agile outside software is absolutely possible — but it comes with a credibility problem most coaches underestimate. If you don't understand the business and technical domain the team actually works in, you'll push frameworks that don't fit, and the "resistance" you run into won't be imagined — there really is a wall, and you just haven't found it yet. Sometimes the right move is Scrum; sometimes it's Kanban, Kanplexity, or something you invent — and knowing the difference is the real skill.

A lot of what passes for Scrum today isn't really Scrum at all. It's Water Scrum Fall dressed up in agile language, with confused roles, broken definitions of "done," and Product Owners chosen for their availability rather than their authority. But alongside that decline, something more authentic is quietly growing — and it's worth paying attention to which version of Scrum you're actually part of.

What separates a scrum master from an agile leader? And while we're at it — what's the difference between a scrum master and an agile coach? (Answer: about $200 a day.) Beyond the punchline, there's a meaningful conversation to be had about the overlapping roles that shape agile organizations. This piece breaks down what scrum masters actually do, what leaders add to the mix, and why the best leaders often make excellent scrum masters — provided they leave their controlling-manager instincts at the door. From walking the gemba to cultivating environments where agility can grow, here's a practical look at where these roles meet, where they diverge, and why the overlap matters more than the distinction.