When a Co-Dev Wants To Be a Product Company

Lessons Learned From Co-Dev

One of the main qualities that drew me to the idea for Wolfjaw and then the Catena Tools project was the opportunity to work with a lot of different ideas and company cultures. Every game is unique in how it's made, and while there are similarities, every studio has their own distinct aspects.

A friend once told me that you truly don't know how to launch a game until you’ve done it. It's kind of funny to say that, as I have met quite a few folks who have never been part of a single launch that still land jobs at game studios, convinced they know it all. Being a co-dev allows us to work with the best in the business, learning lessons and seeing varying approaches to accomplishing the same tasks. This gives us a unique ability to be able to provide insight to our clients because we have been down the road they are thinking of going down many times before. Throughout Wolfjaw’s history we have been a part of not just a single game launch, but multiple on an annual basis.

I used to think I also knew everything there was to know. However, after going through multiple game iterations and launches, I can tell you there is still a lot I have to learn.

These lessons are what made us start thinking about building a product. There are a ton of great products in games, many of which we work with. There’s Unity and Unreal on the engine side or Catena Tools, Pragma, and Epic Online Services from the backend side of things, to name just a few. With so many disparate technologies, game studios find themselves engaging Wolfjaw’s services to be able to know how each works and how to tie it all together. In a sense, we are the translator mercenaries that come with tribal knowledge and the ability to make it work.

How Does It Impact Culture

The culture of a co-dev is one that is essentially “work for hire.” I prefer to call us mercenaries in the sense that we are specialists brought in to accomplish a specific task, but we are not making the larger business or technological decisions. This can be difficult for some to understand, as I have seen people struggle with why a client might make what they perceive as a “wrong decision.” The reality is that the decision is what the client wants, and our role is to ensure it is feasible and to get it done.

On the product side, though, things are totally different. Trying to use our co-dev strategies in the world of product development has been a challenge but also an experience that is allowing us to build differently.

There are two aspects I want to touch upon.

1. The impact a switch in business type has on the business itself.
2. Perhaps more importantly, the impact it has on the people who are working in both worlds.

First, let's talk about the business.

Impact On The Business

There are many nuances and lessons learned when you try something new. I am not a product person, and while in the past I have tried to be, it often led to failure and many lessons learned. Rather than repeating mistakes, I view each failure as an opportunity to see what went wrong and how it can be improved.

The first lesson I learned was how hard it is to build a platform. It is a daunting task and honestly a road I am not sure I ever want to go down again. I am wired in a way that means I want to build a business. But when it comes to platforms, often outside money is required. Instead of building out a runway with a sound business concept that gives you a sense of what is working, you are merely trying to build something that can achieve business viability before the investment runs out.

As someone who worked in the investment space a long time ago, I will say I think the way VC startups are built is flawed. Too much of the industry has the idea that actually building a business is of less interest than the idea of building hype before the cash runs out and the business can be sold. Margins are ignored, and revenue at any cost to show “value” becomes a fool's errand that many times means the product is sold for less than it cost to make.

So why after saying all of that would I say, “Hey, let's try that product thing again”?

Well, the first thing we did was look at it and say, “How can we build something that can be of value and sold for a profit by utilizing what we know and the network we have?” All businesses are marketplaces, meaning there is a buyer and a seller. But a platform requires a third aspect, which means you are building the marketplace itself and making assumptions on what the buyer and seller want the most to ensure commerce takes place.

So now we are going to go down the product route, despite me just saying it's a tough road to go down. I am lucky to have some of the best engineers in the industry when it comes to backends, and while I may be biased, I think our resume speaks for itself. One of our titles would be impressive to brag about, but when all assembled in a group, it is even better. But we are service engineers and business folks. There are many lessons we are learning and have already learned in this journey to build Catena that I think are important to mention.

Biz Dev Pipelines

When you sell work for hire, you are more or less working to build relationships with clients you will work with for a long period of time. Sales is not what we do here. It is business and relationship development. We strive to be honest, under-promising and over-delivering. We maintain a strong working relationship with our clients, so we know what they want and when they want it.

When building out a sales pipeline for a product, however, the client is not directly seen or known. We don't have direct contact with them on any cadence that will allow us to know what they want and when. Instead, we have to listen as much as possible and make educated guesses about product direction.

This has required a lot of retraining of our brains and developing a new understanding of how we market to these customers. They are no longer clients. In fact, they are merely a company that will utilize our product and hopefully gain a ton of value from it, which will, in turn, allow us to make money.

Roadmapping and Timelines

This is a more recent item that has been on my mind. When we are working on a game, the deadlines and timelines are set. We simply have to ensure they are realistic and then do the work. When we are building a product, though, there is also no deadline or dateline. There is no person or persons directing us. We are in charge, and while everyone may always want to be in charge, once you are, the decisions get harder.

At the same time, we need to avoid turning it into a science project. We need to focus on completing tasks promptly, ensuring the product is ready to be sold and we aren't over-investing in a single tool.

This is something we are still trying to nail down, right now we are building out a roadmap that will certainly change as soon as we are done forecasting. We are utilizing this roadmap to build out sprints so that we have deadlines and are not over-investing in any aspect of the business or product.

A Product For All

As we build out the Catena product, we are looking at ways that we can be strict with ourselves and build a product that is valuable for the end user and not make assumptions in the bubble that is Wolfjaw.

Additionally, we are examining how to avoid letting one end user dictate so much that tools are agnostic. Too often I have seen a company get a client and then hear so much from that single client that they start essentially building the product just for them, rather than creating something that can be used by all the game studios. I will leave these companies unnamed…

As a product company, we are trying to use our knowledge of all the games we work on to develop something that would get us to around 80% of the way there before customization is needed. This is the essential reason why we are creating tools rather than a platform.

Impact On The People

Now, the business side of things is much larger than what I mentioned, and I will likely write about other aspects that we see as we go, but I wanted to touch upon a different impact of the change from co-dev to product: What does this do to the people and the culture of the company?

The biggest thing I have always seen when a service company works on a product is FOMO. We all know the fear of missing out is always there, but nothing brings it out more than a shiny cool tool that gives us the ability to make technical decisions. Managing this expectation is something that I have really wanted to focus on to avoid it becoming a distraction for the rest of the company.

The second big aspect is context switching. After spending the first 5 years of our company solely focused on working on other people's products, we now have our own. While it can be exciting, it can also be challenging to maintain our mercenary attitude while also having something that we are now responsible for in every aspect.

FOMO and context switching means someone has to be able to understand what's being discussed and who is the final decision maker. At the same time, they have to recognize that the main goal of the company is to make money. Until that changes, our clients are 100% the main focus of any discussion.

Another area that we have to see is the mind switch from working for a client and understanding who is making the technical decisions. With a new internal tool, engineers relish in the idea of "greenfield" development, as they can have authority over making more technical decisions, versus "staying in their lane" with a client's existing architecture or legacy code.

Conclusion

The change from being a service provider to a product company is both exciting and challenging. We are taking a path that we hope allows us to help developers make more game backends and integrate with many of the cool existing backend platforms on the market. Wish us luck!