In most projects, software is built in one of two ways. Either someone decides, to the best of their knowledge, what the customer needs and builds it. Or, in the rarer and more data-driven cases, you follow metrics: conversion rates, click paths, time on task. Both have their place. And both miss the point surprisingly often.
The first way mistakes your own idea of the customer for the customer. The second measures what happens, but rarely why. There is a third way that an entire industry has perfected over decades and that classic software development almost never uses: the playtest.
What a playtest really is
In game development, a playtest is not a questionnaire and not a focus group. You put a real player in front of a real version of the game and watch. You do not ask whether the tutorial was clear. You observe whether the player gets stuck at point X, whether they find the exit, whether they laugh where intended or give up in frustration at the wrong place.
The reason for this discipline is an uncomfortable truth: people are remarkably bad at saying what they want, but their behavior reveals it reliably. A player who says in an interview that the level felt fair may have died fourteen times at the same spot in the recorded playtest. Observation always beats the statement.
That is exactly the core of the Playtest Strategy when you carry it into software: observe instead of ask. Do not ask the customer which feature they want; watch where they get stuck in their daily work, which steps they route around, where they reach for a sticky note or a spreadsheet next to the system, even though the system is precisely the thing that should be handling it.
This sets the strategy apart from things that sound superficially similar. A survey collects opinions. An A/B test measures outcomes without explaining the cause. A classic usability test checks a finished interface against predefined tasks. The playtest, by contrast, is the ongoing, patient observation of real behavior in real situations - and it is not a phase but a posture.
Valve as proof
The most convincing example is Valve. The studio's games do not work because the cleverest designers in the world sit there inventing the perfect mechanic in quiet isolation. They work because Valve orients itself radically and almost exclusively around direct player feedback. Through iteration, observed playtests, and continuous adjustment, the product is made better step by step.
The in-house know-how is one half. The other, decisive half is the willingness to subject your own assumptions to what you actually see. Counter-Strike, Dota, and Team Fortress were not designed and then released. They were released and then observed, adjusted, and rebalanced over years.
And here a second effect appears that is often overlooked. Valve enjoys enormous trust and goodwill among players - not despite this posture, but because of it. People who sense that their actual behavior is being responded to feel taken seriously. So the Playtest Strategy pays off not only in the product but also in reputation. A company that visibly responds to its customers builds a lead that no marketing budget can buy.
The six building blocks of the Playtest Strategy
The strategy breaks down into six building blocks. Each translates a principle from game development into the world of business software, and together they describe how a Product Owner aligns a product with real behavior instead of guesses.
1. Set up the playtest
A good playtest needs three things: a real task, a real user, and a realistic situation. Not "take a look at this and tell me what you think," but "do your next real task the way you always do, I'm just watching." The closer the situation is to actual daily work, the more honest the behavior. The artificial lab setting produces artificial behavior.
2. Observe, don't ask
This is the heart of it. While the user works, you watch for the places where reality diverges from your assumption. Where does friction appear? Where does the flow stall? Where does someone hesitate, scroll back, open a second window, search for something that should be obvious? These moments are gold. They show not what the user wishes for, but where the product gets in the way of their task. The crucial discipline is to stay silent: any premature explanation from the Product Owner destroys the signal.
3. Separate signal from noise
Observation gives you raw material, not finished answers. Not every irritation is a design flaw, and not every stated wish is relevant. This is where the Product Owner's real work lies: reading the pattern out of many observations. If five out of six users stall at the same place, that is a signal. If one demands a particular feature, that is a hypothesis about an underlying problem, not the solution itself. The art is to look behind the wish and find the real need.
4. Iterate in rhythm
Playtesting only works in short loops. A big release after twelve months is one single, enormous playtest with maximum risk and minimal chance to learn. Instead: observe, adjust, present again, observe again. In this role the Product Owner becomes a Game Director - someone who does not design every detail personally, but holds the course, interprets observations, and decides which adjustment to test next. The rhythm itself is the tool.
5. When metrics, when observation
Observation and metrics are not opponents; they complement each other. Metrics tell you that something is happening, and they scale: they show where in the process many users drop off. Observation tells you why it happens and provides the explanation a number can never give. The smart order is usually this: the metric shows where to look. The playtest shows what is really going on there. Measure only, and you optimize while flying blind. Observe only, and you lose the overview.
6. The playtest never ends
The most important block, and at the same time the easiest to forget. A release is not a finish line but a save point - the moment from which you can observe under real conditions. Software is not a finished project but an ongoing playtest. This is exactly what Valve demonstrates: the games keep being observed and adjusted for years after launch. This posture has a direct parallel to the idea of treating processes like products: you need someone permanently responsible for whether the product works - not just on release day, but for the long run.
Why now
There was a time when software was so generic that observation barely paid off. A standard product for everyone, take it or leave it. That time is over. Software is increasingly niche, usability-driven, and customer-specific. Today it can be tailored precisely to one concrete workflow, one industry, one individual team.
That is exactly what raises the value of real observation. The more specific the product, the less generic best practices help, and the more it matters how exactly this customer works in their reality. Where a generic design used to be enough, today the fit in the details decides everything. And that fit is not found in a requirements workshop, but by watching.
How I work
For me, the Playtest Strategy is not a technique to pull out when needed, but the basic posture with which I approach software as a Product Owner. Requirements are hypotheses. Releases are save points. And the most honest source of truth is not the meeting, but the user at work.
The side effect is the one Valve reaps too: a company that visibly responds to its customers builds not only better software but also trust. Customers notice when they are taken seriously, and that binds them more strongly than any single feature. Better products and a better reputation are, in the end, the same movement seen from two sides.