Shipping! The Heartbeat of Effective game and app Development

I hold the conviction that frequent releases, maintained at a consistent pace while accumulating insights, are pivotal to success. This is a core tenet of Scrappy: Rethinking the blueprint of Games and Apps Creation.

However, just because you.ve heard of lean methodologies, or the importance of fast and frequent releases that you have to ship hastily or without direction

There are foundational principles to ensure the quality of every build you release.

Your learnings are as good as your hypotheses

Within the confines of the same studio, where teams had access to identical resources and adhered to similar processes, I've consistently noticed a stark difference in outcomes. Some teams soared, consistently pushing boundaries and achieving their goals, while others seemed perpetually stuck, struggling to make significant progress over the years.

Interestingly, this disparity wasn't necessarily rooted in talent or experience. On paper, some of the teams that faced challenges appeared more talented. They seemed to have a more solid foundation and, ostensibly, possessed all the elements required for success.

So, what set the successful teams apart? It was their deliberate and purposeful approach to every prototype, release, or update they worked on.

Each release wasn't just a new version; it was a mission with a clear objective, anchored in a well-defined hypothesis. They didn't haphazardly introduce features based on their appeal or simply because a top-ranking game boasted them. Instead, every release was treated as a mini research expedition, a journey to understand their players more deeply and to refine their game accordingly. This methodical approach ensured that with each iteration, they were not just moving but moving closer to their ultimate goal.

This strategy isn't some modern-day revelation. It's deeply rooted in the time-tested scientific method, which emphasizes the importance of identifying a clear problem, formulating a hypothesis around it, and then rigorously testing that hypothesis. For those interested in a deeper dive into this methodology, there's an insightful article in the Harvard Business Review that sheds light on its nuances and applications.

Ship only builds that you believe in

While it might seem like common sense, the reality is that under the weight of various pressures, we often find ourselves releasing content that doesn't meet our own standards.

There are numerous reasons we might feel compelled to do so: perhaps we made a commitment to deliver a particular feature, or we've already invested significant time and resources into it, making it seem wasteful to abandon. Sometimes, we might rationalize that the content is 'good enough' or 'not that bad.' However, these justifications don't hold water when it comes to delivering quality.

When we release something we're not entirely satisfied with and then face underwhelming results, it's easy to fall into a trap of defensiveness. We might say, 'Of course the results weren't great; we didn't have enough time to perfect the feature.' This mindset often leads us into a cycle of reworking and tweaking, extending the iteration time far beyond what's efficient.

Before finalizing any build, update, or deliverable, it's crucial to take a step back. Test it, discuss it, and critically evaluate it. Does it align with our vision? Does it genuinely add value? Is it the best representation of our efforts?

If the answer to any of these questions is 'no,' then it's essential to have the courage to either refine it further or let it go. As challenging and frustrating  as it might be, if a feature or update doesn't resonate with our core beliefs about quality, it's better to sideline it. If we feel it's close but missing some crucial elements, then it's worth investing the time to get it right.

Releasing content we're not fully behind doesn't just compromise the present; it jeopardizes future endeavors. It's a principle we must always remember: Nothing good comes from releases we don’t believe in.

Not too many features

Have you ever been gripped by that persistent, nagging feeling? The one that whispers, "If we don't cram our game with every conceivable feature, we're going to be left in the dust." It's as though there's an invisible, ever-growing checklist hovering over us: integrate all the social platforms, incorporate the latest events, implement every new monetization strategy, and ensure a character list that seems to stretch on for miles. The underlying belief seems to be that the path to success is to outspend the competition rather than outthink them.

But here's the revelation: This is nothing more than a myth. A daunting, pervasive, and utterly misleading myth.

Now, if your strategy is to comfortably remain in the shadows, perpetually playing catch-up and following the industry leaders, then perhaps this approach works for you. 

However, for those looking to make a genuine impact, consider this: Players form their impressions about a game or app in those initial, fleeting moments. It's not about the exhaustive list of features or the intricate details hidden in the late levesl. No, it's about the immediate vibe, the unique itch it scratches, and the distinct problem it addresses. Players are captivated early on, often way before they encounter the depth of content you've created.

The guiding principle here? Embrace the power of simplicity. Focus intently on that core experience, the very essence of what you're offering. And before you're tempted to add yet another feature, ensure – with data-driven confidence – that it genuinely enhances the experience.

While it's alluring to throw in every bell and whistle, achieving mastery in a singular, defining aspect of your game is where the true magic lies.

So, challenge yourself. Dive deep into the heart of your game. What sets it apart? What's its unique allure? Identify it, refine it, and let it shine brilliantly, setting your game apart from the rest.

In my book, Scrappy,  I delve deeply into this concept, particularly in the chapters titled "Less is Enough" and "Constraints Will Save Your Life." It's a topic I'm incredibly passionate about.

One feature at the time 

Given the option of releasing a single feature every week or waiting a month to unveil four features simultaneously, I'd ardently advocate for the weekly release approach. This strategy not only accelerates your learning curve but also facilitates a more precise evaluation of each feature's impact.

Picture this: You roll out an update packed with four or five new features, and suddenly, your KPIs take a nosedive. How do you pinpoint which feature is the culprit?

I recall a particularly illustrative experience from my time working on a mobile game. We were brimming with excitement over an update that we believed was a game-changer. It introduced a slew of new heroes, endowed existing heroes with special abilities, revamped our onboarding, eliminated problematic levels, fine-tuned the game's difficulty, introduced a new game mode, and incorporated numerous adjustments to the game's economy. It was a veritable treasure trove of content. Yet, to our dismay, our KPIs plummeted post-release.

The subsequent weeks were a frantic scramble, as we grappled with the challenge of identifying the problematic feature. We set up a series of A/B tests, toggling features on and off, and meticulously analyzing the results.

The revelation, when it came, was nothing short of astonishing. The root of our woes was the game's icon. Yes, as improbable as it sounds, the mere change in the icon's background color from orange to blue had triggered the decline. One observant team member noted that post-update, he often struggled to locate the game on his device. It dawned on us that the sea of blue-hued apps - Facebook, Skype, Twitter, App Store, LinkedIn, Zoom, Trello, and so many others - might have rendered our game inconspicuous.

Though it seemed like a stretch, we were at our wit's end and decided to revert to the original orange icon. Miraculously, our retention rates bounced back to their previous levels.

This episode underscored the importance of incremental releases. By introducing changes step by step, you can swiftly identify and rectify issues, ensuring that your game remains on an upward trajectory

Ship when it’s done

Defining when a release is considered as done entails is paramount for us, and it encompasses several facets.

Firstly, the essence of a release is its quality. As previously emphasized in this article, a good release doesn't necessarily equate to a polished one. It can be straightforward, yet fully functional. For a deeper dive into this concept, I'd recommend the chapters "Polish is different from quality" and "80/20" in  Scrappy.

Secondly, a release should be devoid of any significant technical glitches or bugs. Consider this: even if you've developed the most groundbreaking app or an incredibly engaging game, if users encounter crashes, performance lags, or functionality issues, their experience will be marred. While striving for a completely bug-free product might be a lofty goal, it's essential to ensure that there aren't any major issues that could compromise the overall user experience. A crucial point to note here is that the responsibility of ensuring a clean release shouldn't solely rest on the shoulders of your QA team or department. The entire team should be actively involved in testing the deliverable to ensure its robustness.

Lastly, it's vital to be judicious about the volume of content or features being released at once. If a release feels too hefty or overwhelming, it's a signal for us to either break it down into smaller, more digestible releases or to employ A/B testing. This ensures that we can accurately gauge the impact of each individual component we introduce. By adhering to these principles, we ensure that each release is not just a new version but a refined experience for our users.

Embrace the results

It might seem like stating the obvious, but it's astonishing how many teams don't truly internalize and act upon the results they receive.

Often, when outcomes don't align with expectations, teams can become adept at crafting a narrative of excuses. Common refrains might include: "It's not polished enough," "We need more content," or "It'll work better once we roll out feature X in the next update." Such justifications can be endless.

However, if the primary takeaway from disappointing results is that the release is underperforming due to missing features, then the team isn't genuinely acknowledging the feedback. Instead of adding more layers to a problematic feature, the more strategic move is often to trim away the elements that aren't resonating and recalibrate the approach.

This underscores the importance of a pre-release review with the entire team. By critically assessing the product before it goes live, teams can preemptively address potential issues and eliminate post-release excuses. This proactive approach ensures that everyone is on the same page about what the release aims to achieve and what its potential pitfalls might be.

Post-release, the focus should shift from searching for excuses to understanding the underlying reasons for a feature's underperformance. The discussion should center on user motivation and behavior. Why didn't users engage with a particular feature? What aspects turned them off? Delving deep into these questions can provide invaluable insights. After all, understanding what users dislike can be just as enlightening as knowing what they love. This iterative process of introspection and adaptation is what truly drives growth and innovation.

The insights I offer here are shaped by my years in the field, making them inherently subjective and influenced by my experiences. My views may evolve over time, and I'm open to that change. I'd greatly appreciate your feedback, thoughts, and questions to further refine my understanding. Please don't hesitate to connect.