The Joy of Working with Teammates Who Make Things Happen

DelightRoom: An Organization Where POs Are Never Lonely

Unless you're a one-person company, every organization in the world runs on "collaboration." As the years go by, your experience with collaboration becomes more colorful as you work with a wide variety of people. This is especially true if your position is a PO or PM. Not to mention the range of teammates you collaborate with (business departments like marketing and business development / product departments like engineers, designers, and data analysts), the types of collaboration you experience span a broad spectrum (considering B2B, B2C, and their specific domains).

As a PO, I've passed through three organizations, building collaborative experience with at least a hundred engineers, about ten product designers, and roughly twenty business teammates. Since the organizations I've been with have always prioritized a solid talent density, my collaboration experiences with all my teammates have been a continuous journey of growth. Even so, collaborating with my current teammates in the Subs squad at DelightRoom is quite different from my past experiences. I've always wanted to reflect on exactly what is different and how, and with the new year upon us, I thought I'd organize my thoughts by listing some recent real-world examples. It might be even more fun to read if you recall your own collaboration experiences and think about what you would have done in my shoes.

If it's not working, 'I' make it work.

A newly discovered definition of ownership

01. What if a blocking factor is expected during work?

Engineers and designers in the Subs squad don't just have squad tasks; they also juggle their own functional group's tasks in parallel. There are also internal review processes within their groups (code reviews, design reviews). Because of this, to complete a squad task, they must carry out their work while carefully considering their group tasks and internal procedures themselves. At times, these considerations can create situations where they might not be able to properly execute squad tasks, but the voluntary responses from my Subs squad teammates look like this:

• Proceed for now, and if they hit a blocker, share it and push the remaining work to the next sprint. [X]

• Mention in advance that it might not be completed due to expected blockers, but try proceeding anyway. [X]

• Aim to make it work no matter what, figure out a "way to make it work" on their own, and execute it. [O]

Of course, even with this approach, the work might still not be finished due to blocking factors. But even if the end result is the same "not done," the team's motivation level is vastly different, and our mid-to-long-term performance will undoubtedly reflect that difference.

02. What if a specific task is so heavy that completing it within the quarter seems overwhelming?

When it comes to achieving quarterly goals, the individual competency of each worker is a major variable, but how the PO plans is incredibly important. You have to craft the sprint tastefully by considering the Impact, Confidence, and Ease of each backlog item to hit the intended targets. In doing so, backlogs that have high Impact and are very tempting but have excessively low Ease can hurt overall quarterly productivity, making me hesitate to pull them into planning. When Ease is still low despite splitting and breaking down the product spec into an MVP level, the voluntary responses of the Subs squad teammates look like this:

• Say it can't be done. [X]

• Say they'll try for now, make some progress, and push it to the next quarter. [X]

• Use the buffer time in every sprint to chip away at the work in advance, thereby increasing the Ease. [O]

** Note) The Subs squad allocates 25% of available work hours as a buffer during planning.

These experiences led to the confidence that no matter how difficult the product spec, we can make it happen if we collaborate together. Unlike the past, where we were mostly stuck inside the box with "hypotheses for increasing revenue by 20% or 30%," before I knew it, the Subs squad's backlog was filled with outside-the-box, "bold hypotheses for doubling or tripling revenue."

Your Work = My Work = Our Work

Willingly sacrificing my own efficiency for the team's efficiency

01. What if a new surprise occurs that's different from what was planned?

The "sprint," which revolves around delivering value to users in a timely and effective manner, places great importance on increasing sprint predictability through planning, reviews, and retrospectives. The better the predictability, the more accurate the planning becomes, allowing us to stably keep our promises to users. But the key here is that the goal of a sprint isn't just "timely delivery," it's "effective timely delivery." If it feels like we can "deliver" according to plan, but maybe not "deliver effectively," then hastily adjusting the plan is the right move. We usually call these things "surprises," and they are a common occurrence in most startup growth teams. Here are the reactions of my Subs teammates to this:

• Say it can't be done. Suggest sticking to the plan. [X]

• Say it can be done, but express annoyance about the surprise. [X]

• Say it's possible and that they are actually glad we get to deliver it even better. [O]

There was even a time when an entire sprint planning changed, not just a single task.

It is the main role of the PO to manage things well so that surprises happen as rarely as possible, but how can you predict everything? Unexpected things are bound to happen, such as user feedback, sudden requests from other departments, and individual members' schedules. In the past, those things lowered the personal efficiency of teammates, which caused me a ton of stress as a PO and made even me conservative about changing plans. But now, thanks to teammates who consider the efficiency of the entire team, I can rationally make optimal choices that are most beneficial to our team performance in the end. Through this, we get a strong feeling that we are "one team" achieving a common goal together. The PO position is by no means a lonely one.

02. What if, according to the collaboration process, the design/engineering work isn't ready yet?

Normally, if a PO plans A, a designer designs B, and an engineer develops C in this sprint — then in the next sprint, the PO plans a new D or analyzes the deployed C, the designer designs A, and the engineer develops B. That's in an ideal, highly stable, and smooth-sailing scenario. Given the nature of a startup where everyone has to wear multiple hats, there are times when the backlog to be developed hasn't been fully designed yet, or the backlog to be designed hasn't been fully planned out yet. In this case, we have no choice but to juggle product spec, design, and development all within a single sprint. The reactions of my Subs teammates to this are as follows:

• Say running things in parallel is inefficient, so let's stick to the process and move on to design and development after the product spec is ready. [X]

• Say they'll run it in parallel, but express discomfort over the inefficiencies. [X]

• Agree to run it in parallel and suggest that since time is tight, let's take care of what we can in advance and get it done. [O]

There was even a case during a sprint where, before the design was finalized, an engineer sneaked a peek(?) at the design work in progress and built an initial draft of the code. The intent was that even if major revisions occurred, they would willingly make the changes. Compared to developing off a finalized and polished design, it would take more personal effort, but it brings us closer to our team's goal of "completing the task." Thanks to this, we were able to complete 90% of the entire process (product spec ~ design ~ development) in just two days.

Of course, this kind of "parallel work" caused not by an unpredictable "surprise variable" but by "poor planning" is definitely not right in terms of sustainability. The PO needs to manage the pipeline systematically so that teammates can run a long marathon with a stronger sense of stability. It's something I should feel very sorry to my teammates about. Even so, I think my teammates understand these situations because of the strong trust and gratitude we have for one another. The funny thing is, thanks to these situations, my trust and gratitude toward my teammates also grow stronger in return. Therefore, I also find myself responding flexibly to any "poor" situations they might have; it's almost like a loop of reinforcing trust and gratitude. I am trusted, so I'm given some leeway; because I'm given leeway, I also trust them; so I also give some leeway, and then I earn trust again...

In 2022, we were able to achieve the following rebound in our subscription conversion rate,
and as a result, drove a 1.8x revenue growth compared to 2021.

The experience of running together toward a common goal and delivering results,

Looking back closely on the past year, all of this was possible because I had "teammates who make things happen." I want to express my deepest gratitude through this post.

You guys are truly the best!

I'm already looking forward to what we'll make happen this year! (And feeling a bit of pressure on the other hand.. lol)

Joyfully and boldly...!

Anyone want to join teammates who make things happen? 🙋‍♂