I've been putting this post off for a while. Fundamentally, because this is a problem about mindset and is sure to ruffle some feathers. However, if you bare through it, you'll see that the core idea of experimentation and learning is not too far from "Fail Fast". You might still disagree and think that we need to move forward, at all costs, but by reading this I might just plant a seed on how to think about the same problems you're facing in a more holistic, empathic, way.
Fail Fast is Failing Us
"Fail Fast, Break Things" is one of those terms we've heard in product leadership almost as an axiom. Almost as if what's inherently true about our state of being is that in order to progress forward, innovate, and create new products, we must break the mold of what is. And in that state of "creative destruction", we'll learn new things about how to serve our audience better, because what's holding them back are the products or processes or services they're using.
This ideal state of learning isn't born from a place of malice. It's the idea that if we can deliver something quickly, we can determine the value that was delivered through its impact. We get feedback faster; we're able to iterate faster; we'll (as in the product) will be more valuable to the user faster.
I don't think anyone in Product Management would disagree that this, in a nutshell, is the ideal state we want the game, software, product to be. We want to be able to get feedback from our audiences to make the experience better; to make it worth the player's or user's time; to feel that they found it valuable to them.
But the second half of that "axiom" is where trouble sets in and, unfortunately, where a lot of organizations fall into traps. I can hold space that part of what we're also doing, as Product Managers, is navigating into uncertainty to find novel experiences or solve complex problems by thinking outside of the box and breaking processes or conventions that we think are holding the genre or the sector back. The question becomes: at what cost to our players, to our teams, to our organizational reputation, and to the greater market are we breaking things and actually delivering value?
This is where the mentality of "Fail Fast, Break Things" starts to fail us. Under the, sometimes considerable, time crunch many organizations place on delivering something to users, we miss on what's most important: does it actually improve their experience?
What about the knock-on effects of a massive miss? What are the costs of "breaking" the team? Or of the reputational damage to the studio or company; of that social capital spent (that's really hard to gain back)? Or of the damage we cause, not on purpose, to the perception of the industry by the market?
It's About Intention
This isn't about engaging in "what about-isms". Our decisions, as Product Managers, have real consequences. They impact the financial state of the organization. They impact the morale of our teams. They impact the way players or users perceive the product and our motivations (just to name a few).
We can ship a bunch of widgets to our audience and say: "See? We improved the software by 20% with more widgets!" A (probably not insignificant part of) our audience might react with: "But now this is worse for me? How do you call this 'an improvement'? We needed Y for this to be better for us!" (Feel free to insert any number of recent examples, from Windows Recall to Concord - yes, I went there.)
That's a very contrived scenario, but, unfortunately, probably a lot more common than we'd (for sure, I'd) like to admit. We don't always have the time to do the deep dive into user experience or get all the feedback we want. We rarely will ever get to work with perfect data.
It's not about "Fail Fast, Break Things" is wrong at face value. It's that it fails to contemplate the implicit (externalized) costs of just going full bore with breaking stuff because "it's how we learn". I'm sure we can all talk about the externalized costs of that mindset. It should become more about how do we create an environment where we can experiment, learn, and become better without some (or at least, minimizing some) of the negative consequences?
Partially, it's about a cultural problem: we need to create the space (and guard rails), the alignment, and the sense of purpose so teams can go figure out the solution space for the problem that we've identified. We want that rapid experimentation, in a low-cost environment where we're not spending social capital unnecessarily, so we can deliver great experiences in our games or software.
The other part is about intentionality. As product leadership, we should be taking into account all the associated costs of our decisions, what they entail for both our internal teams and for our audience. That, even if we have a miss, we've set up a pathway to recover from that miss, gracefully.
Not a pathway where we only say: "we need to do better" (as is common to see, lately), but where we actually create and support a culture were that is true; where we are all aligned on serving our audiences to best of our capabilities. That we consider the costs we're asking our players or our users to assume (this is the basic small-"a" agile concept of considering if your customers can absorb a release that sometimes gets lost in the shuffle).
This isn't a new concept - others have talked about changing the intentionality behind "Fail Fast". It's about what we learn, as individuals, as a team, as an org, as a community behind a game, and the costs that we assume that is important. I, truly, believe that if we were to break away from this paradigm of "build and ship" to a more mindful space of what it even means to "build something of value", we, as creative builders in whatever field we choose, will elevate our audiences and our craft because of it.
Special thanks to Leti Gasca's TED Talk for first putting into words something that has been rolling around in my head for a better part of a decade. It's worth the watch.
/r
Member discussion: