Launching Your App in a New Market: A Team Lead’s 3-Month Plan

roadmap

The goal of this article is to provide a general and agnostic vision to Engineering Managers or Team Leads/Managers facing the challenge of launching an app in a new market within a short period of time. It shows how a person leading an engineering team can align stakeholders, maintain team motivation, adhere to timelines, and follow a quality strategy to uphold good practices and manage active bugs within a reasonable number.

This is a generic plan with various ideas that you can use, modify, or adapt to your needs. That’s why I’m suggesting and assuming things agnostic to the technology and company because you are the one who knows how the company works internally.

Always explained from a team lead perspective, I want to clarify that this is not the only definitive plan to always use. It may be used for a specific moment, and the strategy can be changed or adapted for future quarters. But, I hope it helps someone. 😉

1. Stakeholders Team Lead  Interaction

How to Interact with Stakeholders and Maintain Alignment?

Effectively interacting with stakeholders and maintaining alignment across various departments is crucial for the successful launch of your app in a new market. Here are some guidelines on how to interact with your stakeholders and the recommended frequency of these interactions.

Visual Representation

In the diagram below, the interactions and alignment meetings among various roles are illustrated:

  • Engineering Team/Individual Contributor
  • Team Leaders (TL)
  • Product Manager (PM)
  • Product Designer
  • Product Data
  • Product Researcher (Legal & User Requirements)
  • Stakeholders (Business, Third-parties, External Partners)
  • Engineering Manager (EM)

By maintaining this structured interaction cadence, you can ensure that all parties are aligned, motivated, and working towards the common goal of successfully launching your app in the new market.

2. Proposal Roadmap

First of all, this is NOT the product roadmap. This is a proposed roadmap to explain one way to face this challenge. In this case, I’m generally showing two things:

  1. Align and document everything in terms of flows and technical details.
  2. Focus on development and deployment.

Keep in mind that if we’re going to launch an existing product in a new market, we already have a functional product. However, it’s important to identify the critical flows, weaknesses, and pain points of our app to ensure they are addressed in the new version, especially if time is limited.

That’s why it is crucial to have a clear understanding of the flows, mocks, legal requirements, API contracts, and various strategies to maintain the quality of our product and avoid increasing the number of problems.

My recommendation is also to always keep some contingency space at the end of the quarter to address any issues that may arise, while the team simultaneously starts planning for the next quarter.

3. Team Motivation

As a picture is worth a thousand words, I’ve tried to summarize various important points to maintain the team’s motivation during this challenging period. I’ve also written some articles to handle the relationship with individuals through 1on1 meetings, scaling your team up, and elevating team productivity that can help to keep a good motivation.

team-motivation

4. QA Strategy

Even if our application is new or an evolution of an existing one, we need to prioritize quality. Sometimes, we have QA profiles to assist with testing and developing the necessary strategies. However, there is a trend towards not having dedicated QA profiles and instead empowering teams to create these strategies themselves.

If you are the one who has to create and present this strategy, I hope the following table and graph can at least help you with your considerations.

qa-strategy

Why am I proposing Unit, Integration, and E2E testing only for new features and critical bug flows? Why is TDD a nice-to-have in this plan?

I’m proposing this approach only if you’re short on time or facing a significant challenge within a short period. In an ideal world, if you’re creating an application from scratch, it’s important to keep all of this in mind from the beginning. However, if that’s not the case, first tackle the issues that are most problematic for you and the company. Stabilize those areas and address the root causes of the problems. For those issues that you don’t have time to fix completely, at least identify and document them to address later.

METRICS

As an engineering lead or manager, I believe there are some essential metrics to keep under control. Use tools during the pipelines to help with code quality and create dashboards, monitors, and alerts to send you notifications, such as to Slack.

These tools allow you to not only identify issues but, more importantly, prevent them. We can detect issues before our users notice them in production, for example, during deployment (by checking logs through Datadog, New Relic, etc.) or by receiving alerts if one of our services is not scaling its infrastructure properly.

metrics

5. QA Bugs Strategy

What Can We Do About Current Active Bugs?

Some of the following points may seem obvious, but they are often not taken into consideration:

  1. Keep Bugs and Quality Strategies Visible to the Team:
    • Ensure that everyone is aware of the current bugs and the strategies in place to maintain quality.
  2. Define Severity Levels (L1-L4):
    • L1 and L2 bugs are critical for the company and need immediate attention.
  3. Allocate Time for Bugs and Technical Debt:
    • Dedicate 20% of each sprint to addressing bugs and technical debt, focusing first on critical paths and user impact (the percentage may vary based on the number of current bugs).
  4. Keep Bugs Tracked:
    • Ensure all bugs are tracked consistently.
  5. Define a Keeper Role:
    • Assign one engineer to rotate each sprint to monitor bugs while also developing new features. This allows the rest of the team to stay focused, while active bugs are mitigated.
  6. Create a JIRA Query:
    • Use JIRA to create a query that displays the current number of active bugs by severity in a graph.
  7. On-Call Strategy for Critical Issues:
    • Implement an on-call strategy at the company level for handling critical issues outside of work hours (using tools like PagerDuty).
    • Ensure the team documents everything thoroughly to help on-call peers mitigate issues quickly if something happens.

By implementing these strategies, we can better manage active bugs and maintain the overall quality of our product.

bugs-strategy

6. Time Adherence

Oh yes, these strategies and plans sound nice, great, and wonderful, but… how do we ensure time adherence during these months? There are no magic steps; in my opinion, it’s a matter of culture, a combination of many processes and decisions, which I’d summarize with the following graph.

team-adherence

7. Scaling Strategy

All the processes described will take time to become ingrained as a culture within your team, but I can promise you that it’s entirely possible. Once you see that these strategies are working effectively, what’s next? Well, don’t you think that you could expand some of these points to the rest of the company and even improve these strategies by discussing the results with other peers?

Some points come to mind that could be expanded upon in the near future and implemented across the company, such as those I’m showing below.

scale-strategy

8. Scenarios to prevent in your plan

There are numerous situations that, as a manager, you may encounter along the way that can impact your plan. I don’t believe you can plan for everything, but in my opinion, it’s important to be mindful that such situations could arise, and I’ll provide you with some real examples that I have experienced:

  1. PM or Engineer Departure:
    • If an engineer leaves the company, you must ensure that knowledge and team capacity are not compromised.
    • Regarding PMs, the impact may be felt in terms of priorities and interactions with stakeholders.
  1. Increasing Team Size:
    • Could you achieve the same goals earlier with more engineers on your team?
    • Be cautious with this answer. First, gather numbers and measure everything possible. Are all engineers working with the same technologies? Do they need ramp-up time? Do they have the same seniority?
  2. Accumulating Technical Debt:
    • This should ideally be avoided, but it sometimes occurs. Don’t ignore it; if necessary, track it along with its impact and negotiate with stakeholders when it should be addressed.
  3. Missing Deadlines:
    • Communication is key. Have a system in place to identify missed deadlines as soon as possible and notify the team. It’s even better to have a proposal ready at the time of notification.
  4. Reacting to Production Issues:
    • Have a quick reaction plan in place to address issues in production promptly.
  5. Infrastructure Issues:
    • If the infrastructure is not functioning as expected, address it promptly.
  6. Expanding Project Requirements:
    • If project requirements expand after planning, address them with stakeholders and adjust the plan accordingly.
  7. Silos Between Teams and Dependency Handling:
    • Establish recurrent checkpoints with other teams. Request estimated timeframes and clarify ownership.

By being aware of these potential challenges and having strategies in place to address them, you can better navigate through unforeseen circumstances and ensure the success of your projects.

Conclusion

There are several ways to plan a project. We are always fighting against time, but one thing is certain: numbers don’t lie. So, measure everything—metrics, impacts, capacities.

Once we have the numbers and understand the resources the company provides, we can then create and execute the plan.

Best Related Posts