Between Technology and Management: My Nexters Cohort 26 Retrospective

Taking on the PM Challenge

I did not even know how Nexters operated, yet I boldly submitted an idea.

Taking on the PM role would give me countless details to manage, but I believed that pushing myself through a genuinely difficult experience would help me grow. I wanted to become the center of collaboration and gain experience leading a team and solving problems. Rather than simply completing my assigned work, I wanted to become someone who could set a direction that helped the entire team work efficiently.

What Kind of PM Was I?

I thought of a PM as “the person who will do whatever it takes to make the product successful.” However, because I had not defined the role more concretely, I wandered a little and struggled at the beginning of the project.

During that time, I asked one of the PMs at my company for a coffee chat. They agreed that “a PM exists to make the product successful,” but advised me that it was important to decide how I would position myself to achieve that goal.

Just as PMs with planning or design backgrounds have their own strengths, I was encouraged to think about how I could use my strengths as a backend developer. That conversation helped me define and carry out my PM role more concretely.

Schedule Planner

I believed one of a PM’s most important responsibilities was keeping the project on schedule.

I divided the work into first, second, and third phases, setting intermediate goals that would lead us toward the final objective.

We did not execute the plan perfectly, but I focused on checking our progress and adjusting the schedule at every stage. When we fell further behind than expected, I discussed it with the team and responded by adapting the plan flexibly.

Bottleneck Breaker

Because Nexters required us to produce a working result in only two months, I believed that a bottleneck could directly lead to failure. Minimizing bottlenecks was one of my most important responsibilities.

• I gave teammates fast feedback to keep the work moving, including code reviews before work and during lunch.
• When collaboration across disciplines was necessary, I quickly coordinated communication between the relevant teams.
• When the team needed to discuss something, I proactively organized meetings to prevent delays.

Leading the Backend

Our team had more backend developers than the other disciplines. I left the details of implementation to my teammates while setting the broad direction and helping the project move forward smoothly.

My goal was to minimize how long the app and frontend teams had to wait for APIs. I created a work plan so that backend teammates could begin immediately, then represented it as milestones and issues on GitHub. As soon as our business policies were decided, I modeled the domain and presented a diagram. The backend team discussed it together and quickly finalized the structure.

classDiagram
  accTitle: Domain model for questions, answers, and keyword scores
  accDescr: QuestionBundle and Record compose the core domain objects. ChoiceQuestion and BalanceQuestion implement Question, and choices contain keyword scores.

  class QuestionBundle {
    +List~Question~ questions
  }
  class Question {
    <<interface>>
  }
  class ChoiceQuestion {
    +List~Choice~ choices
  }
  class BalanceQuestion {
    +Choice choice1
    +Choice choice2
  }
  class Record {
    +User user
    +Question question
    +Choice choice
    +Answer answer
  }
  class User
  class Answer
  class Choice {
    +List~KeywordScore~ scores
  }
  class KeywordScore {
    +Keyword keyword
    +number score
  }
  class Keyword {
    +String name
  }

  QuestionBundle *-- Question : questions
  Question <|-- ChoiceQuestion
  Question <|-- BalanceQuestion
  ChoiceQuestion *-- Choice : choices
  BalanceQuestion *-- Choice : choices
  Record *-- User
  Record *-- Question
  Record *-- Choice
  Record *-- Answer
  Choice *-- KeywordScore : scores
  KeywordScore *-- Keyword

A Partner Working Alongside the Team

Turning the abstract concept of “exploring personal values” into a service took much more time in the planning phase than we expected. By the time the design was finalized, less than a month remained before the final presentation, and we had many pages left to build.

Although a PM is responsible for adjusting the workload to meet a deadline, there was not a single feature we could remove without compromising the app’s completeness.

I naturally believed our teammates had the ability to finish everything. The problem was morale. The frontend team looked overwhelmed by the amount of work, and doubts were growing about whether we could complete it on time.

In that situation, I had only one option: support the frontend development myself.

I devoted every available moment to frontend development and completed the first MVP pages within a week. That allowed us to run the usability test (UT) we had planned. After experiencing that small success, the frontend team regained its confidence and accelerated development. In the end, they pulled off the remarkable feat of completing every page in just three weeks.

The Person Handling Every Odd Job

Another important part of being a PM was helping teammates focus on their own work. I therefore handled a wide range of tasks myself, including Flutter development, the iOS review process, backend bottlenecks, small frontend issues, and QA. I also took care of many other large and small tasks, such as advertising, presentation preparation, and booking meeting rooms. I moved nonstop, leading the backend while handling all these practical responsibilities at the same time. I also learned firsthand just how exhausting an entrepreneur’s life can be.

What a Leader Needs

A leader’s mistakes affect the entire team. What matters, however, is learning from those mistakes and not repeating them. This experience led me to reflect on the core capabilities a leader needs.

Judgment

A leader’s judgment determines the team’s direction. When a leader points the team the wrong way, teammates endure unnecessary trial and error. Leaders must therefore understand their product deeply, gather plenty of information, and remain sensitive to trends. Above all, they need a strong understanding of every discipline so they can enable smooth collaboration.

This was an area where I fell short. I was insensitive to trends and lacked confidence in my decisions. In particular, my limited understanding of UI/UX and user-experience design kept me from giving the design team well-reasoned feedback. Most importantly, I overlooked user-centered interactions.

I was afraid to make decisions without feeling certain. My instincts told me the design needed revision, but thoughts such as, “What if we waste resources?” and “What do I know about design?” stopped me from deciding easily. I hesitated even on important matters and sometimes left decisions unresolved for the team instead of making a clear call.

This confused the team and prolonged the planning phase. Because the product direction remained unclear, the design team had to revise its work repeatedly, while the development team had to proceed amid uncertainty. As a result, the entire project schedule slipped.

A leader is not someone who always produces a perfect answer. What matters is the ability to give the team a clear direction even in uncertain circumstances.

Planning and Strategy

A leader needs a clear plan and strategy. If execution begins without a strategy, teammates repeat unnecessary work and lose morale. A leader’s role is to think several moves ahead.

After deciding on our service concept, we conducted user research to derive insights and immediately began building wireframes. A major problem emerged once we started discussing those wireframes, however: the design work had begun before our core policies were decided. We ultimately had to redo the design, and unnecessary revisions wasted a great deal of time.

We would have been far more efficient if we had followed this order:

Discuss and decide core policies -> Create wireframes -> Provide detailed flow feedback -> Create the design

This demonstrates why a strategic approach must account for both the importance and sequence of the work. Without a clear direction from the leader, a team repeats the same trial and error. Execution without strategy wastes resources and ultimately makes the objective harder to achieve. A good leader does more than simply encourage execution. A leader must build the strategy that moves the team in the right direction and design the best path forward.

Crisis Response

I also believe helping the team respond effectively to a crisis is an important capability.

Midway through our schedule, one teammate suddenly became too busy with work at their company to continue participating in the project.

In particular, losing a designer was a major crisis for our team because illustrations were central to the product. I was shaken at first, but I tried to maintain a positive atmosphere so the team would not panic.

After the project ended, I admitted that I had actually been badly shaken. Thankfully, everyone said I had not looked that way at all.

To reduce the design team’s burden, I decided to write the UX copy for the character introductions myself. I found a copy of The UX Writing Textbook at the office, read it, and wrestled with GPT for quite a while as I searched for the best wording.

Other teammates also participated actively in content creation and QA, continuing to raise the app’s level of polish.

Ultimately, the project schedule held steady, and we did everything we could to finish the project despite the crisis. This experience taught me how important it is to remain calm, find a solution, and lead the team through unexpected circumstances.

How I Changed

A Leader’s Perspective

Taking on the PM role made me think from a leader’s perspective more often at work as well. By a leader’s perspective, I mean understanding the resources available to the team, planning a realistic schedule around them, and considering how to move the product in a better direction. A leader should be someone who does more than complete tasks: someone who optimizes the team’s capabilities and draws out the best possible result.

When the team’s plan looked likely to slip, I tried to step forward and solve the problem without worrying about whose role it was. It also became natural for me to think about how teammates could grow and help them move in that direction.

Understanding Advertising

At work, I collaborate closely with the person responsible for advertising. My role is to add code that enables effective use of Google Tag Manager, Google Ads, Meta Tag Manager, and related tools. Throughout that work, however, I had viewed the advertising system only from a technical perspective. I had spent relatively little time considering how advertising campaigns were planned and operated or what strategies they required.

Then, taking on the PM role gave me an opportunity to operate an ad campaign myself.
At work, advertising requests had meant handling tasks such as adding tracking code, tagging events, and configuring pixels. This time, I was responsible for measuring and analyzing campaign performance myself. Instead of thinking only about “which data should we collect,” I needed a new perspective: “How should we optimize the advertising strategy?”

I ran an ad campaign myself using Meta Ads Manager.
The budget was not large, but I gained experience running ads with my own money. Operating the campaign gave me opportunities to speak with the person responsible for advertising at my company and learn about many aspects of the work. In particular, I gained specific insights into how strongly target selection affects performance and which step-by-step strategies work best for capturing user interest in app advertising.

Through this experience, I realized that the data I had been collecting was not just a collection of numbers but essential information that could determine real business outcomes. It may have been a small change, but for me, it marked part of the process of growing beyond a developer into a developer who understands the business. I want to continue becoming a developer with a broader perspective across both technology and business.

Retrospective

I gave so many presentations that I grew thoroughly tired of them.

Taking on the PM role let me experience more than being a developer. I had to lead a team and think carefully about its direction.
At first, I felt lost and began with the question, “What exactly is a PM supposed to do?” As the project progressed, however, I gradually defined the PM role in my own way.

I want to become someone with a broader perspective, not merely learn more technology.
Whatever role I take on, I want to be someone who can solve problems and help the team grow.