How One Video Game’s Approach to Development Can Apply to Your Custom Software Product

When most people think about video games, they probably think of the classics like Tetris and Mario, or big modern titles like Call of Duty, Minecraft, and the like. The gaming world is often taken by storm when smaller titles are released by independent developers, as is true with the release of the ghost-hunting game Phasmophobia by Kinetic Games. Why is a Solutions Engineer writing on a software development company’s business blog about a paranormal-themed, independent computer game release, you might wonder?

Because the developers behind Phasmophobia have done something quite brilliant in terms of their Product Management ideology while introducing their thought process using a very clever user outreach tactic.

How does a video game relate to custom software development?

Before we talk about what the Kinetic Games team has done in detail, however, let’s set the stage by talking about some of the challenges of owning a custom software product. First and foremost, we like to refer to any custom application effort as a “product” rather than a “project”. Projects have very a clearly defined beginning and end and tend to be rather temporary in nature (at least compared to your business!)

Thinking of your software applications as products promotes a better way to think about how to manage them. Products exist to create business value by serving a customer base. Even if your product is purely internal to your business in nature it still serves a customer - whether it is an accountant, a fulfillment warehouse worker, or an executive leader. Products tend to evolve and improve over time as customers or the market forces change the competitive landscape – so, too, should your software products change and evolve to meet the needs of their customers.

Of course, any given product must start somewhere, which is what we refer to as the Initial Release. Once that is out in the world, you need a plan and a process for how to continually evaluate and build upon the product, ensuring it is still providing the value your customers demand, leveraging advancements in technology, and staying secure against new threats. Looking at the first release of Phasmophobia, the Kinetic Games team did a great job of proving the concept of a Minimum Viable Product. They did not develop every conceivable feature or aspect of the game to its logical end but rather focused on releasing a compelling, successful game with the base experience and features needed. This allowed them to get the game into the hands of their target audience sooner and begin gathering feedback (more on that later). Meanwhile, they stepped into the fact that the product will always need to grow and change after launch, organizing the features and changes they had already thought of into the first backlog of work for continually improving the game.

The reality of the evolving nature of your software product poses a few obvious challenges. For example, how do you manage the process of continually developing software effectively? How do you gather and manage feedback from customers so that you know your product is responding to their needs? Questions like these could each justify their own blog post (or years of study and practice, for that matter), but heading back to the Kinetic Games team, we can see how they are doing a great job of tackling these challenges.

Using a public project management board to organize feature ideas and development

Kinetic Games team has set up a public Trello board to manage its feature organization and development pipeline. Their Trello board describes each new feature, change, or bug fix as a ticket. Tickets are organized in what is known as a Kanban system. Their system is as follows:

1. New ideas are put in the Backlog, where they are evaluated, debated, and prioritized according to the product team’s prerogatives. As ideas are chosen for development, they move to the right through the remaining stages of the board.
2. Selected ideas are moved into the To-Do phase, then In Progress when the team begins work on them.
3. Completed items are moved to the Next Beta Update bucket, and on to Done when they are part of the game’s stable release. Customers can opt-in to play the Beta version of the game to receive new updates sooner, and to provide feedback as new features or changes are interacted with “in the wild”.

There are several different ways for a product team to manage and track product requests, but this Kanban-based system is a good example of an intuitive and transparent way for a team to understand internally and communicate externally what the current and future priorities are for the product. Regardless of the framework your team uses (or may someday adopt), this is a publicly visible example that you can use to see what “good” looks like for one team.

From a customer outreach perspective, this tactic supplies an exceptional level of transparency for any industry, the video game industry aside. Fans of the game can see if their ideas are under consideration for the game’s development and track any ideas that they are interested in throughout the delivery process. Traditionally, gamers are limited to generic support email addresses or online forms that promise that the company appreciates their feedback – but then what? Maybe when the next release for the game comes out they could dig through the patch notes to see if there is anything they care about. Only the most hardcore and dedicated fans of a game have the time or interest to keep track of that kind of process.

The Kinetic team, on the other hand, has arguably created a more engaged and dedicated fan base by lifting the veil and showing openly how they are managing and growing their product. There are likely some drawbacks of being so open – for example, they allow user comments on the features, which is great to gauge customer sentiment but also could become negative or need to be moderated for offensive content. Regardless, the Kinetic team knows what its most important base is interested in and how that base is reacting to development choices, and without needing to spend time and money on traditional user outreach efforts or consulting fees. It’s a brilliant way for a small, up-and-coming team to crowdsource its product direction.

What you can learn from this example:

• The Initial Release does not need to include everything you wish the product to accomplish or your full vision for the product’s future – the sooner you get something effective and valuable into the target audience’s hands, the better.
• Transparency with your customers, to whatever extent feasible for your case, could help you improve your product faster and improve customer engagement by providing your customers with an explanation of your product roadmap and how it corresponds to their needs.
• Organizing customer feedback and prioritizing it with an established process helps to give you and those not on your development team a better idea of what’s upcoming in the development process.

How do you manage your software products? Have you figured out a clever way to gather and respond to customer feedback? Whether you are actively managing a product, or have a need for a new software product in the future, we would love to talk about how we can help you with your custom software needs. If you’re interested in learning more about our own approach to custom software development, check out this blog on our process!