A practical guide for people who teach, mentor and support students, founders and teams building businesses with game technology or gaming methods in other industries.
Purpose
These principles are a quick guide for people who help teams and individuals use game technology, game development knowledge or gaming methods for business purposes. They are particularly relevant if supporting entrepreneurship is not your main professional role, or if you have strong expertise in games, technology, education or another sector but less experience with startup mentoring.
The principles are not a fixed methodology. They are reminders to stay curious, understand the people and context in front of you, and adapt your support to the company’s actual needs.
Coaching and mentoring
This section uses the term coaching because it is commonly used in startup support and in the Game Tech Academy project. In practice, however, the principles draw heavily on mentoring. For startups, the two approaches often overlap: a good mentor brings relevant experience and perspective, while using questions, reflection and dialogue to help founders develop their own understanding and make their own decisions.
The distinction matters less than the intention. Do not become an on-demand problem solver or simply tell founders what to do. Use your experience to help them explore unfamiliar challenges, recognise blind spots, consider alternatives and build their own capacity to move forward.
Help the Team See Itself Clearly
Principle: Act as a mirror for the team. Help founders make their assumptions, strengths, weaknesses and blind spots visible.
Why this matters
Teams working across industries can easily transfer assumptions from one professional culture into another. A team with a strong background in games may assume that it understands a new target sector, while a domain expert may assume that understanding the problem also means understanding how to design the solution. Hidden assumptions can affect market understanding, team communication and decisions long before anyone notices them.
In practice
Useful questions
Reflect on Your Own Preconceptions
Principle: Bring your experience, but do not let your own agenda, sector bias or institutional incentives quietly determine what success should look like for the founders.
Why this matters
Specialised knowledge is valuable, but it can also narrow the advice we give. A games mentor may see problems through a games-industry lens; a technology mentor may apply standard startup frameworks too rigidly; a sector specialist may assume that familiar business models or validation methods are always appropriate. Support can also be shaped by the interests of the organisation, educational institution or funded project behind the mentor. These interests may be legitimate, but they should not be confused with the founders’ own goals.
In practice
Ask yourself whose success you are trying to optimise. Your primary role is to help founders succeed with what they are genuinely trying to achieve.
Use your experience to identify challenges the team may not yet see, but avoid pushing solutions mainly because they fit your preferred method, sector or personal experience.
Be explicit when organisational requirements, funding criteria or educational goals affect the support you can provide.
Do not assume that unfamiliar business models, timelines or ambitions are wrong simply because they do not fit your usual framework.
Practice openness, active listening and mutual reflection. Contribute specialised knowledge with as little unnecessary judgement or negative bias as possible.
Recognise when your expertise is not enough and help the team access other mentors, specialists, networks or perspectives.
Useful questions
Am I helping the founders achieve their goals, or am I steering them towards mine?
What assumptions am I bringing from my own sector or career?
Could my institution’s or project’s success criteria be influencing my advice?
What do I know well enough to advise on, and where should I bring in another perspective?Have I listened long enough to understand what the team actually needs?
Maturity Assessment
Principle: Assess maturity continuously and across multiple dimensions. Do not mistake strength in one area for overall readiness.
Why this matters
Game-tech and cross-sector companies often develop unevenly. A team may be highly capable technically and have an impressive prototype, but have limited market understanding. Another team may understand the target problem well but lack the skills, business model or resources needed to deliver a solution. Traditional measures such as technology readiness remain useful, but they do not describe the whole company. The right support also depends on timing: game companies and technology startups may eventually face many of the same business questions, while differing in when those questions become relevant and how validation should take place.
In practice
Look at several dimensions, such as product or solution maturity, market and customer understanding, business development, team and skills, founder development, and the team’s self-perception.
Treat maturity as dynamic. Revisit the assessment as the company learns, changes direction or enters a new market.
Look for gaps between confidence and evidence. A convincing pitch is not necessarily proof of market understanding.
Adapt the conversation to the company’s stage and context. Avoid forcing every team through the same startup timeline.
Consider whether the company is dealing with a product challenge, a business challenge, a team challenge or a founder challenge before deciding what support is needed.
Use maturity assessments to prioritise the next useful step rather than to label the company as simply ‘mature’ or ‘immature’.
Useful questions
In which areas is the company mature, and where are there still significant gaps?
What evidence supports the team’s understanding of the market and users?
Which capability is currently the limiting factor?
Are we introducing this business topic at the right time for this company’s journey?
What is the most important next step rather than the longest possible list of improvements?
Help the Team Look Beyond the Product
Principle: Help the team distinguish between building something and building something that creates value for a customer, user or other stakeholder.
Why this matters
Many students and startup founders come from a technical, creative or game development background. Their primary focus may naturally be on building the software, developing the game, solving a technical challenge or creating a compelling prototype.
This can lead to an important blind spot: assuming that because something works, is innovative or is enjoyable to use, it automatically has commercial value.
A prototype is not necessarily a product, and a product is not necessarily a business.
This can be particularly challenging for companies applying game technology or gaming methods outside the games industry. The founders may understand how to build the solution, but have limited knowledge of the industry they are entering. They may not yet understand what problem the customer is trying to solve, who receives the value, who makes the purchasing decision, who pays, how the solution fits into existing workflows, or what alternatives the customer already has.
The business model may therefore be far less obvious than it initially appears.
The mentor does not necessarily need detailed experience from the specific target industry. However, they should be able to recognise when the team is focusing exclusively on the product while important questions about value, customers and commercial sustainability remain unexplored. Experience from comparable situations—including entering unfamiliar markets or finding ways to commercialise new types of products—can help the mentor guide the team towards the right questions.
In practice
Help the team move from “What are we building?” to “What value does this create, for whom, and why?”
Distinguish between the technical solution, the product or service, and the wider business around it.
Explore the actual context in which the solution will be used. A game designed for a classroom, hospital, museum or professional training environment may have very different requirements, customers and distribution channels from an entertainment game.
Help the team identify different stakeholders. The user or player may not be the customer or payer.
Explore who experiences the value, who makes decisions, who controls the budget and who is willing to pay.
Encourage the team to investigate potential revenue and funding models rather than assuming that a familiar model from the games industry will apply.
Help them validate the underlying need and value proposition, not only whether the technology or prototype works.
If neither the team nor the mentor understands the target market sufficiently, identify what needs to be learned and who else should be involved.
Useful questions
What problem or need are we addressing?
Who experiences the value of solving it?
Who uses the product, and who pays for it?
Who makes the decision to buy or adopt it?
Why would this organisation or customer choose our solution instead of doing nothing or using an existing alternative?
What is the actual added value of using game technology or gaming methods in this situation?
How and where will the product or service be used?
What might the customer be willing to pay for, and why?
What potential revenue or funding streams could support this?
What assumptions are we making about the business model that we have not yet investigated?
Game Tech Academy is a collaborative project which aims to discover synergies and showcase the potential of game technologies to tackle a growing number of complex challenges beyond the entertainment industry.
