Scaling the Development Team Alongside Business Growth: From the Ground Up to Market Entry

All product-led technology companies are faced with the development optimization question in one way or another: how to build processes, outsourcing or in-house, how many people to hire, what kind of specialists to hire, and what to do with all this while growing a business.

In practice, managers, founders, and investors ask these questions at every significant stage of project development: who to hire first, what stack to use, how to scale the team and increase productivity, moving from an MVP to a full-fledged market launch, and what to do with the growing payroll expenses.

In this article, I will try to provide useful tips for each stage of product development. It is based on my and my colleagues' experiences, including successful and unsuccessful business decisions we made while working in various companies.

Starting the project and beginning the development process

In general, I see three paths that a founder or CEO can take in the early stages:

1. Outsourcing MVP development

2. Start assembling your in-house team

3. Starting with no code tools

   
   

How do you make the right decision? The nature of a product will determine your first step.

What if a product is not supposed to use new rocket science technologies? For example, suppose you want to introduce a new business model to a specific market niche (XaaS product).

Outsource developers will also be able to quickly implement such a project because many of them have been in the industry for a long time and have experience developing standard solutions.

If the main value of your product is in technology (all types of AI, IoT, AR/VR/XR, etc., or just an unusual solution), then the no-code option is out because it is impossible to implement technologically complex projects using these tools. Furthermore, if you need an MVP to essentially test a hypothesis to determine whether there is market demand for your product, working with an outsourcing team is probably the best option. If there are market analogs for the product, the likelihood of failure increases, so it is better not to waste primary resources.

However, if you are familiar with the market and want to introduce your technologies, it is best to begin forming your team. This will give you more leeway in defining how your product will look from the start. In case you present an outsourced team with a new product idea that significantly alters an MVP during the development process, it will additionally bill you and will demand more time for analysing new requirenments. In this case, your development team will complete the task faster, though introducing new ideas midway will likely prompt team members to roll their eyes.

Following that, I will primarily focus on working with an in-house team, with a few exceptions for the cases where an MVP was implemented differently.

Forming a team

Who should be hired right away? If the product necessitates the use of specific technologies, such as AI, it is critical to find the best professional you can afford in the market. The skills and experience that such a professional will bring to the team, as well as the speed with which they will ensure development, will more than compensate for your salary expenses. The most qualified specialists should be in charge of your cornerstone technologies because these are the professionals who will give you an advantage over your competitors while also innovating.

After choosing a technical lead and a stack, you can hire a couple more developers. Again, hiring someone with good experience saves time in the middle of trying to implement solutions that seniors have already implemented multiple times.

There is no need to assemble a full-fledged team of DevOps, QA engineers, and system analysts right away; if we are building an MVP, team expansion should be gradual. Ensure that developers do not overlook unit tests, as they prevent the project from stalling in later stages of development. There are many testers on the market, and you can find one quickly, which is why you can hire them once the product is usable.

In the development process, there is no need to reinvent the wheel. If your application contains logic that every other product on the market has (notifications, monitoring, billing, etc.), there is a 90% chance that you will find a ready-made SaaS service or Open-Source solution that will cover your needs for a low or no cost. Concentrate on what matters most: creating a solution that distinguishes your product. Later, if necessary, you can implement your specialized notification systems or the same billing.

There is no need to construct complex infrastructure. Most major cloud providers' tools enable you to launch containers with code and load balance in a few clicks using serverless solutions, eliminating the need to set up and deal with managed clusters like Kubernetes. At this point, you can invest in simple CI/CD to accelerate the process of delivering code to the cloud.

At the very beginning, when you have written 0 lines of code, it is usually pointless to implement Scrum or any Agile approach with sprints. In reality, the initial stages of development require the completion of basic tasks such as deploying the framework, selecting libraries, creating basic entities, and implementing minimal business logic. Such tasks can be difficult to evaluate because the team has no tangible results to be able to evaluate. Establish fundamental domains, entities, and processes for your product with your team, and then create a Kanban board with cards containing these basic tasks and employees assigned to complete them. Most likely, these cards will randomly merge and divide during the work process; there is nothing wrong with that; let the developers structure them in a way that is convenient for them - bureaucracy is not required at this stage.

Sprints are useful and convenient; they can be implemented after the developers have laid the groundwork for the future product.

At the moment, it’s critical that your small team communicates constantly - there's no documentation, the requirements are vague, and no one knows what kind of system you'll get. Make up for it with daily meetings and timely communication.

A small life hack that I've been using successfully for the last four years is to conduct all work communication regarding tasks, emerging problems, technologies, deadlines, and so on in the main team chat. Even if a developer believes there are only two people involved in the task, he should communicate in the main team chat by tagging another person. Direct messaging should only be used to discuss personal matters. This method keeps everyone on the small team up to date on the product's progress.

Completing the MVP

The closer the team gets to finishing the MVP, the better they understand which product components require more and which require less resources. When the product has its primary functions, it is time to consider QA specialists. Testing during the development process is a necessity, not a luxury; it's not just about potential bugs, but also about product owners having confidence that the team is creating exactly the kind of product they need.

Now that developers can be assigned more specific tasks and the system foundation allows them to assess their complexity, it's time to consider development methodology. In my practise, we've always used "near-Scrum" processes because they allow for good planning while also allowing for quick changes in product requirements.

You can hire additional performers as needed. For example, if the project involves a server load that is disproportionate to the number of users (complex calculations, processing large amounts of data), use DevOps to begin building a scalable infrastructure.

Once the MVP works, carry on with product development

So your MVP is up and running and has found a market niche. You're increasing your marketing budget and learning about what your customers want. You must now focus on several things at once: business clients want convenient tools, consumers require engagement mechanisms, and so on.

It makes sense to scale the team further for new tasks for each product subsystem separately. For example, one team should deal with your core technology, another with billing, a third with internal tools, and so on.

This method allows you to keep small teams with minimal internal bureaucracy while also preventing developers from stepping on each other's toes when working on the same code.

It would be preferable to separate the manufacturer team from the producers of subproducts (or services), with separate code. In the case of a marketplace, for example, keep a personal account separate from a storefront. Make the developer who does the most work in the back office the team leader (but only if he wants it), and hire new people in a specific team. If it is possible to assign/hire a separate product manager for a new team, do so; this will allow you to manage backlogs regardless of basic functionality.

In general, the rule is as follows: if there are an increasing number of tasks in a specific development area that are difficult to prioritise, form a separate team with its own backlog, priorities, and sprints to complete these tasks.

Each team can develop its own internal processes, such as changing the release cycle and task estimation techniques. However, it would be preferable if some general principles were followed everywhere.

Simultaneously, it becomes difficult to build communication between teams when one team is tasked with maintaining the work of another. This is where documentation comes in handy. Draw diagrams to describe and support interaction interfaces between services. You can hire a systems analyst or architect to do this as well as act as a mediator in contentious issues.

Add in regular cross-team meetings. At MyGig, for example, we hold all-teams big retrospective meetings that allow all participants to voice their opinions, including those on other teams and the systems they control. Create architectural committees where team leaders can discuss technical solutions, overall technical debt, and interaction patterns. Small meetings for synchronization on this project can be added if more than one team is involved in its implementation. Finally, product managers from all teams meet on a regular basis to synchronize backlogs.

Develop communication - each individual team operates as a single organism in a 100% single information field, and more bureaucratic procedures involving documentation, described contracts, and so on can be used to interact with other teams.

The DevOps team, the analytics team, and the "R&D special forces" are all examples of departments whose resources are used by everyone else. Form them separately and consider them to be service ones. Create a request system that allows everyone to use these service teams' services.

Every business is unique

Of course, the process I describe may differ in different companies. However, in the three companies where I served as CTO, these general principles enabled the synchronization of three components: product growth, development costs, and the required level of planning flexibility. New products were successfully launched into the market in a short period of time and at a low cost. In contrast, existing ones were allowed to develop more quickly in various directions.