International Collaboration & Strategic Product Alignment

Operating across multiple countries is a common reality for many product organizations. With teams spread across different regions, time zones, and cultures, ensuring collaboration goes beyond communication—it’s about driving strategic product alignment at scale. For Product Ops, this brings new challenges in keeping teams aligned and focused on shared business goals.

How can Product Ops enable strategic product alignment across global teams?

Join Dave Soetanto, Product Operations Leader at Egnyte and PMO Advisor, as he shares his real-life experiences on enabling strategic product alignment at scale across global teams.

Dave dives into practical strategies for bridging gaps and aligning product objectives across international teams. He highlights the importance of understanding cultural differences in decision-making and planning: “Understanding cultural differences helps us create processes that work across all teams.”

Dave shares his experience at Egnyte, where they operate across multiple regions with product leadership in the United States and engineering teams in Poland and India. One key focus was on balancing structured roadmaps with flexibility to ensure smoother collaboration. Dave also introduced a two-tiered roadmap strategy that provided clarity on priorities while allowing for adjustments. He also discussed the importance of tailoring decision-making structures to prevent misalignment and respect regional expectations while maintaining execution speed.

Dave’s insights offer valuable guidance for Product Ops professionals looking to improve global collaboration and drive strategic alignment across international teams. His experience at Egnyte demonstrates how understanding cultural nuances and adapting processes accordingly can turn the complexities of global teamwork into opportunities for growth and innovation.

Watch the recording now to get more advice on streamlining workflows and enabling effective global collaboration in your product organization.

Key Takeaways

• Standardizing key processes is crucial for successful international collaboration.
• Creating structured asynchronous workflows can help teams move forward without waiting on real-time decisions.
• Understanding cultural dimensions like uncertainty avoidance and power distance can help adapt processes to different teams.
• Balancing structure and flexibility in roadmap planning can accommodate diverse cultural approaches to commitment and change.

Transcript

The following transcript has been altered for readability.

Product Ops HQ Meetup Kickoff

Ana Andrade: Hello everyone! Welcome to the March edition of the Product Ops HQ Meetup. For those who don’t know me yet, I’m Ana, your community manager here at Product Ops HQ, also part of Dragonboat’s team joining you from Portugal. I’m really excited to be hosting today’s session again. As we wait for everyone to join us, please feel free to let us know where you’re tuning in from, and the chat.

With me today is Leah, also from Dragonboat’s team, who will be in the chat to assist you with some questions and to share some helpful resources as well. Let’s see and wait just a couple of minutes to see everyone joining us. So California, New York, Atlanta, Austin, Texas, Philadelphia, Brazil, Portugal, of course, shining from Atlanta. That’s really nice to see. It’s always great to see some familiar names here. I’m also seeing some new names. If this is your first meetup with us, a big welcome to you. Just for context, our community was created to bring together Product Ops professionals like you. So you can learn, share, and grow together. We also have a slack group where you can connect with others, ask your questions and keep the conversation going. So if you haven’t joined us yet, please be sure to check it out. I think Leah is going to drop an invitation link in the chat for you to join us.

And we wouldn’t be here today without the support of our sponsor, Dragonboat. Dragonboat is an AI-powered strategic portfolio management platform designed for everyone in a product operating model-from CPO’s to product managers, Product Ops and their teams. It helps you set clear strategies, build portfolio roadmaps and deliver products that delight customers and accelerate business outcomes. Dragonboat is more than just a platform. They are your partner in achieving product operating excellence which includes building and sponsoring our amazing community of strategic product and Ops professionals. If you like to learn more about Dragonboat, I encourage you to check out dragonboatio. Leah just shared that link in the chat.

Before we dive into this topic. I just want to say that today’s session is focused on international collaboration and strategic product alignment. We will have a guest speaker, sharing practical step strategies, and then we’ll jump into a live QA. Please drop your questions in the Q&A section as we go. And then if you like to ask your question directly, you can also use the “raise hand” feature in Zoom. Just a quick, final reminder that the session is also being recorded, and we will be sharing it after.

And with that I’m going to move forward to introduce you our guest speaker for today. So I’m super, super excited to introduce you. Dave Soetanto, which is a long time community member. I believe you are one of the pioneers here at Product Ops HQ, right Dave?

Dave Soetanto: Hi, I definitely am.

Ana Andrade: That’s awesome. Thank you for supporting and for being here since the beginning. So for those who don’t know Dave, Dave is a Product Operations Leader at Egnyte, and also a PMO Advisor, with more than 16 years of experience in product and program management.

He’s led a lot of strategic product initiatives in global organizations, such as Ping Identity, Big Commerce and Byte Squad. He specializes in product operations, roadmap development, scaling agile methodologies to improve collaboration across teams. His expertise includes technical leadership metrics and KPI’s and process automation and he also helps organizations streamline workflows and drive strategic alignment. And that’s why we have Dave today to talk about this topic.

Dave also holds multiple certifications including PMP, CSP-SM, SAFe-SPC4.0, and Responsive PPM, reflecting his commitment to continuous learning and also operational excellence. 

Dave, I’m really happy to have you here with us today. Thank you so much, the stage is all yours.

International Collaboration & Strategic Product Alignment

Dave Soetanto: Thank you. Thank you to everybody for joining. I’m excited about this opportunity to share my experience of something that I’m really passionate about.

Before moving to the US, I lived in both the Netherlands and Switzerland, immersing myself in languages and cultures of each, and through that experience, I learned firsthand that cultural differences can either slow us down or become a competitive advantage, depending on how we navigate them.

If you’ve ever had to take a meeting at 6 AM or 11 PM just to accommodate another time zone, you already know that global collaboration is not always seamless. These challenges become even more apparent in software development, where alignment is critical but not always easy. 

Two common friction points stand out to me: finding a solution to a technical problem, where teams from different regions may approach problem solving differently, based on their cultural background and technical expertise, and aligning on product priorities for the coming quarter. What the product team generally sees as the highest priority may not match what an engineering team’s capacity is, or what their current focus is.

Without precise alignment, structured workflows, and an understanding of cultural work styles, we risk delays, miscommunication and duplicated efforts. But when you manage them effectively, global teams can transform from a challenge into a powerful advantage, enabling us to build products faster.

The Reality of Global Product Development

Dave Soetanto: Building products globally opens up incredible opportunities, giving leadership cost efficiencies and allowing engineering teams to operate nearly 24/7, driving productivity and innovation.

But usually these great opportunities come with some interesting challenges. When global teams aren’t managed effectively, they can shift from being a real asset to a frustrating bottleneck—especially when leaders spend their days in meetings from 6 AM to 11 PM, trying to keep everyone aligned across different time zones. For instance, a project manager in the US might need a quick decision from the engineering team. Still, if the engineers are in Poland or India, this could mean waiting for the next day.

One solution we tackled, we fixed or figured out, for this was creating a structured asynchronous workflow that allowed teams to move forward without waiting on real-time decisions. And we also built asynchronous leadership structures that ensures that some engineering leadership is available in US time zones, so product managers are not left waiting for blockers to be cleared.

And generally this matters because global collaboration is only as strong as the systems and processes behind it. If we design them well, we maximize efficiency and impact. If we don’t, we risk slowing everything down.

Standardization for Global Alignment

Dave Soetanto: So why standardize at Egnyte? As we expanded globally with teams in Poland, India, and the US, it became clear that standardizing key processes was crucial to successful international collaboration. Without clear requirements up front, something that should be as straightforward as running a Beta program became really complicated.

We standardized multiple aspects of our workflows, including product documentation templates, JIRA issue management and KPI’s across all teams. For Jira issue management, specifically, we focused on the 3 most common status “types”: what’s considered “planning”, what’s considered “in progress” and what’s considered “done”. Which allowed teams the flexibility to name them whatever they wanted. And using the metadata from those statuses, we were able to build larger reports. 

Our KPI’s were set at the leadership level to ensure that we were all looking at the same high level targets, and reports were being pulled from a standardized source, so we were all talking about the same numbers.

One lesson, from my experience at Egnyte is to very much avoid rigid framework.s While we standardized on the most critical aspects of each document, you have to leave room for some local flexibility. It’s also easy to neglect to ask for feedback from the engineers that are doing the work, relying on engineering managers to be their representative. I don’t suggest you talk to everybody, but you should definitely have one or 2 people that you can talk to, to ask for feedback.

A real world example that we had at Egnyte: before we standardized our beta processes, each product manager managed betas differently. This inconsistency led to confusion for our customers, who would be using a beta feature and assume that it was live and fully deployed, and sometimes we would have a customer that was not aware that the feature could be turned off at any moment. Without proper communication inside the Egnyte teams, the feature was now assumed to be enabled permanently on their domain, and could have been shut off without warning.

Introducing a standardized Beta Brief Template clearly defined the roles, responsibilities, and timelines, so when it could be turned off, and when we are going to go live with it, reducing customer confusion and internal miscommunication.

Scaling Product Operations – Doing More With Less

Dave Soetanto: Scaling product operations is probably one of the hardest things. We’ve had talks here before about how there are several people that are a team of one. We have slowly been able to grow product operations as a whole. But scaling product operations across a global team is one of the biggest challenges we face, especially when resources are tight and headcount growth is just not an option.

The challenge was that we were growing across the world. We had contacts in the United States, Poland, India, and as we grew, so did the operational workload from maintaining alignment across product roadmaps to tracking ongoing initiatives. Instead of simply hiring more people to manage the complexity, we needed to optimize our work and remove unnecessary friction.

So one example was that rather than relying on manual updates, status meeting and creating slide decks, we looked for opportunities to streamline and automate repetitive tasks. Now this might sound familiar, but one of the biggest time sinks was creating roadmap slides. I believe, in total 80 man hours at 1 point to create an update roadmap slides, and that was for the VP level of PM’s. At that point we looked at our processes and said: this is a very expensive roadmap deck. So one of the biggest time sinks was just creating that maintaining it, going forward and making sure that the status was going to be continuously updated. The biggest issue immediately afterwards was making sure that the product marketing managers also had the opportunity to review that to ensure that their message from across the product team was consistent. 

Instead of spending hours compiling, formatting slides, we spend more time upfront, defining what a roadmap slide should look like, including what level of details required in the description, and pulling that data from our roadmap and tracking tools which allowed us to generate them whenever needed. So if we had an update that was basically put inside of our system of record, we were allowed to, or we were able to generate a slide deck that would have the latest and greatest information, including the status that the development team was using as well. The information was immediately available as soon as it was done compiling, and it was shared through a leadership channel by implementing the automation. 

By implementing this automation, we reduced misalignment, eliminated redundant work, and gave leaders back valuable time to focus on more strategic initiatives. Most importantly, this approach helped us scale product operations efficiently, ensuring that our processes could grow with the company, without requiring additional headcount.

Of course, while automation and process improvements help us work smarter, they don’t solve everything, especially when it comes to how teams collaborate across different cultures. That’s why understanding cultural differences in decision-making and planning is just as important as optimizing workflows, because at the end of the day processes only work when they align with how people work best.

Product Operations Navigating Cultural Differences

Dave Soetanto: At Egnyte, we operate across multiple regions, with product leadership based in the United States and most of our engineering teams in Poland and India. While this setup provides significant advantages, allowing us to scale product development and leverage a nearly continuous development cycle, it also introduces operational and cultural challenges that impact how teams collaborate, make decisions, and execute product strategy.

To better understand these dynamics, we can look at Geert Hofstede’s cultural dimensions theory, which examines how cultural values shape workplace behavior. His research identifies six key dimensions, but today, we’ll focus on two that have a direct impact on how we run Product Operations at Egnyte.

The first is “uncertainty avoidance”: how different cultures approach risk and planning. And the second is “power distance”: how teams make decisions. Understanding these dimensions helps us adapt processes to different teams rather than assuming a “one-size-fits-all” approach will work globally.

The first one we’re going to cover is uncertainty avoidance for product roadmap planning. One of Hofstede’s key dimensions is Uncertainty Avoidance, which measures how comfortable a culture is with ambiguity and change. Poland has a high uncertainty avoidance score, meaning polish teams prefer structured, long-term commitments that minimize uncertainty. The United States and India have moderate uncertainty avoidance, which makes them more comfortable with flexibility and adapting plans based on shifting priorities.

At Egnyte, this became clear in how different teams approach roadmap planning. Polish teams were excellent at maintaining focus and execution discipline. Once a project was committed to the roadmap, it became the highest priority, ensuring consistency and follow through without distractions. US and Indian teams brought adaptability and responsiveness, allowing for adjustments when new information or business needs emerged, showing we could remain agile in a crazy world. That’s happening right now.

Without a structured process, we risked misalignment, some teams were looking for commitments, while others wanted flexibility. The solution to this, or rather the balance to this, was to create a structured two-tiered roadmap strategy. We had 2 levels: annual strategic themes, where leadership defines broad outcome-driven themes, providing a high level direction without locking teams into very rigid execution plans, and quarterly initiative and feature planning, where leadership selected 10 key initiatives, revisiting completed initiatives each quarter to assess whether we needed to reinforce or pivot to another initiative based on evolving business needs. This framework ensured that teams had clarity on priorities while still allowing for adjustments where needed, combining structure and flexibility.

Another crucial Hofstede dimension is Power Distance, which measures how much a culture expects hierarchical decision-making vs. individual autonomy. The United States has low power distance, meaning teams expect individual ownership and the ability to make independent decisions without constant oversight. Poland and India have high power distance, where formal leadership approval is expected before moving forward with major decisions.

So I briefly touched on this before but before we introduced Beta Briefs, PM’s in the United States launched beta features quickly and haphazardly. They assumed any issues could be resolved in the moment, if there were any issues. Meanwhile, Polish and Indian teams expected product leadership to sign off on nearly every step, including closing out a beta. This slowed execution when processes were not clear.

To bridge this gap, we introduced a Beta Brief Template that provided a clear set of questions for the product managers, product marketing team, customer success, a clear set of questions, requirements to think through before launching the actual beta, a standardized process for presenting proposals to leadership in regions where approval was expected, and a single streamlined approval step that reduced unnecessary delays. By implementing this shared framework, we were able to reduce overhead, ensure consistency globally, and align all teams on how decisions should be made – respecting regional expectations while maintaining execution speed.

Key Takeaways From Dave Soetanto

Dave Soetanto: So some key takeaways here: 

• Understanding cultural differences helps us create processes that works across all teams
• Balancing structured roadmaps with flexibility ensures smoother collaboration
• Tailoring decision-making structures prevents misalignment and bottlenecks. 

But I suppose one of the most important that you see on this last point here:

• People are not numbers – successful product operations must be built around how teams actually work, and not just how we expect them to.

I had couple more notes, but at the same time I believe that this is great place to wrap it up. But just to close, global collaboration is a challenge. When done right, it’s a huge advantage. By combining clear structure, smart automation and cultural awareness, we turn complexity into an opportunity to build better, faster, and smarter. 

With that said, thank you so much for listening to me. Love to hear your thoughts, and I’m happy to take any questions.

Live Q&A

Ana Andrade: Thanks so much, Dave. I think this was a great start for our discussion now, so I would love to open up the floor for questions. If you haven’t already, please feel free to drop them in the Q&A, and we will get to as many as we can. Or if you prefer, and I really encourage you to do it, now is the time to raise your hand if you want to ask directly, or share your ideas with us. So please just raise your hand through the button that we have here in zoom, and we will unmute you to join the conversation. 

So let’s give you some time, and let’s dive into these questions. We have one coming in from Sarah. Hi, Sarah, Sarah is asking: “Do you do any kind of large team structure planning, example PI planning? And if so, curious how you navigate time zones.”

Dave Soetanto: That’s a great question! At Egnyte, we do not do PI planning per se. What we do instead is that 2 layered approach. We realized very quickly that while big room planning or PI planning was an advantage for teams that were co-located at a smaller company like Night, and I say smaller. Comparatively, we are breakdown 1,200 people with about 300 in the Dev organization. The large big room planning was just not feasible from a financial point of view. So we ended up doing that 2 layered approach, making sure that we had the product managers creating a connection with the leadership team who provided the KPI’s, and then would break down all of those results into specific features. Those would then be swarmed on and scored, based on all the different measurement metrics that we have and prioritize based on that. Since we have that ready, we were able to get all of that information inside of our smaller teams and group it and roll it up into my actual roadmap.

Ana Andrade:: Okay, I hope this answered your question, Sarah. Let’s move to the second one. So we have one from Peter. “You mentioned OKR’s as an instrument to align work. Were cultural differences taken into account in writing these OKR’s?”

Dave Soetanto: Yes, at a high levelm yes. And the best example I can give was how our users would adopt a feature. So one example we had was the way in the United States, large customer of ours wanted to start using the Egnyte web but culturally, they were focused on using desktop app instead. So to make sure that we would drive engagement instead of just hammering down on, we’ll use the web client. We reoriented the objective to also include desktop app usage numbers.

Ana Andrade: Nice. Thank you, Dave. So the next one we have in the chat is from Sandra. “Did you encounter a time when you were trying to introduce a new process and got major push back from one of the teams? How did you navigate that?”

Dave Soetanto: I mean, yeah, all the time. We get that nearly every time I change anything. The fastest or the simplest way I can explain it is, we need to understand what their issue is with whatever the process changes. So a good example is, during quarterly planning, we end up with some teams that are not comfortable with committing to something that they may or may not hit. So one example that we had to be flexible about was, why, of course you. It’s hard to put cultural differences into words, but what we ended up doing instead was allowing them some flexibility and saying this instead of a hard commit, this is a stretch goal, and we understand that if you were not able to 100, get this. Then it’s going to be okay. You’re not going to be penalized in any way. The flip side to that, of course, is to make sure that you keep them accountable on things that they did commit on, and make sure that you keep tracking exactly what’s going on.

Ana Andrade: Thanks, Dave. Well, we have a lot of questions coming in, and we also have a hand raised from Jenny. Jenny, I will go to you next. But first, let’s go to Connie. Connie asks: “You mentioned building slides automatically. How did you gather all the details that went into the slide templates, custom code or an integration?”

Dave Soetanto: Good question. The first iteration of it was focused on using the corporate template that we already had. So if we had any issues with the, let’s call it high level view of what the company had, we would basically just see, what does the company do today? What do we do now at Egnyte today. And the next step that we had to take was really define what a perfect slide looked like. Of course we’re never going to be able to do that for the first iteration. We used Jira at the very high level, and we’re able to use the details at the highest level of that feature. So for us it was either an epic or initiative. We marked those through a filter and based on the filter on the Jira side as well as the corporate slide template that we got, we were able to generate slides that we had all the details, and that we needed. Now., sometimes some things were misaligned but for the most part, I believe the most important thing is that we had the ability to create those slides quickly and not have any duplication of effort. But at the end of the day the question, I believe, was duplicate or custom code. I think there was some custom code in there. We did for the most part, put all of that in, let’s see, Jenkins, and allow anybody who had access, or anybody to basically make their own filter and generate as many slides as they want, because at the end of the day we want to enable them.

Ana Andrade:: Perfect. So we have one from Kiran. “As the teams are shuffled after every few years, what steps did you take for smooth transition?”

Dave Soetanto: Yeah. So it’s very brave to assume that we always have a smooth transition. What I can already tell you is that’s not always the case. But we usually, when we create teams or reorganize teams, the biggest most difficult part is making sure that they have the skillsets that allows them to do what they need to do. So the most difficult part for us was basically doing the storming phase, getting to that storming phase and tuckman’s model. But we were able to basically get through that by finding what they needed to work on, or we’re going to work on, and as soon as they were, we were able to expose what they wanted to really create. And once the transition to an actual formed team or normed team is there, we’re off to the races.

Ana Andrade: Perfect thanks, Dave. So now I will allow Jenny to talk with us. Hi, Jenny! Welcome to the big stage.

Jenny Wanger: Always glad to be on the big stage. So, Dave, one of the things that I’ve been thinking about as you’ve been talking about all this is you’re talking about, especially the cultural differences between the US And India. How much did you think of your strategy as trying to make those cultures come closer together versus having the product cultures in these 2 countries remain distinct and just sort of enabling, almost like an API interface between the 2 different cultures.

Dave Soetanto: So yeah, that’s a great question. I can’t say it’s gonna be either, or the biggest, most important thing to take into account whenever we’re going to that, let’s call it global direction is really to find what the most important things are. We had for each of the different levels. So the leadership team in the United States had very specific requirements on what we needed for quarterly planning, for example, our focus at that point was making sure that the product management team in India also had that knowledge that what that is what they needed and that was non negotiable. But as soon as we went beyond the most important thing so the lowest common denominator, the conversation became a lot more simple, and we were able to get to what are the things that allow them to basically be a team and really create their own process. So I’m trying to say this as nice as possible. Something I’ve ended up saying is, give them enough process to teach themselves, so that at that point they were able to really create their own process and eventually teach us things that we didn’t even think about. And that comes from product ideation all the way down to processes that each different of the different teams use. I hope that answers your question.

Jenny Wanger: I think I was wondering a little bit more about like the overall, like your strategy, and how you were like where you know, it sounds like there were some ways in which, It sounds like it was much more of “hey, India needs to adjust to US ways of working.” Then US adjusting to like there were places where you said India can still work the way that they want to but US wasn’t changing their culture to accommodate India. It sounded like it was much more. The expectation was there were going to be places where India had to change to accommodate the US. Am I reading that correctly?

Dave Soetanto: Well, no. We definitely changed on our end as well. The one of, I suppose, biggest changes that we ended up having was, we didn’t just open an office in, I don’t know, Punya, and say: “that’s it, we have our team there”. We ended up sponsoring visas, bringing people over here, and they’ve become citizens to actually become a part of Egnyte to make sure that they can teach us. So we’re very much focused on adapting to some of their needs, and that includes having for me at least very early meetings. So that way, they can still work on their times, and we don’t force them to be basically shoehorned into our not just time zone, but processes. There are several teams which I am a hundred percent disconnected from, that I’m unable to really talk to simply because of time zones at the end of the day. But I always make the effort to find out what their issues are when it comes to our process. And from a process point of view, the most important thing is making sure that they are able to voice their concerns, and how we incorporate it into ours. 

And, like I mentioned earlier the previous iteration of the roadmap. Actually, I’m not sure if I cover this. But the previous iteration of the roadmap planning process was a hundred percent focused on making sure that everybody followed the United States way, the one advantage of the automation was being able to standardize for all the different groups, and that allowed us to basically give them the lowest common denominator and focus for them on the different features that go underneath it, while the product manager, who would be our, quote unquote, liaison in India, would be the one to flesh out the details at that epic level, giving us the value that we were allowed to be able to get the slides and the roadmap commitment for the entire engineering team, as opposed to Poland, where in Poland we ended up having less, let’s call it different issues. They were very focused on every single detail, technical detail, and because of that we were not always able to go, come to a commitment at the expected end of the Quarter Review.

So that was a different set of expectations that we had to accommodate and make sure that we started our planning much earlier for the teams that specifically wanted those technical details.

Ana Andrade: Thank you, Dave. I hope that answered your question, Jenny. So let’s move on to the next one. Drew Kerrigan asks: “A lot of what you said was awesome, and reminds me of Atlassian’s “team anywhere” and “async collaboration” learnings. I’m curious. Have you followed the work they’ve been doing there, and if so, what thoughts were available or not there?”

Dave Soetanto: I have not heard of team anywhere in Async collaboration, and that is definitely something I’m going to be reviewing. Thank you, Drew. I’d love to learn more. I’m always on the lookout for new, interesting material. So anything that I can really focus on. I’ll definitely take a look at.

Ana Andrade: Drew, I don’t know if you want to join the live discussion. If you want, you can raise your hand and share your ideas and also share with us a little bit more about this, if not, we can chat in slack later. Okay. So next one is from May. Hi May, nice to have you here. So, “are your team’s employees or contractors? If you’ve experienced both, have you seen a difference and how all these difference are handled?”

Dave Soetanto: We, for the most part, have everybody as an employee. We don’t have a lot of contractors out of the 300 people number I mentioned earlier. I believe we have, I think, less than 50 generally, because we have such a high ratio of employee to a contractor, we end up not really noticing that, at least from my point of view, we end up not noticing that they are contractors, and most of the time the differences more soon, I guess tenure. So if somebody has been at a comp at Egnyte in particular longer, I’m very interested in seeing what they have observed over the course of the process. Evolution versus somebody who’s newer, who might have seen something much more efficient at a different company. Somebody that’s in particularly talking about now is our new Chief Product Officer, Prasad. And he’s amazing but a lot of his experience is also focused on B2C, so we are a B2B company at Egnyte, and that gives us some different problems when it comes to process organization.

Ana Andrade: Awesome. That’s always a challenge when a new CPO comes in, right? Alright. So let’s go to the next one, which is: “can we get the transcript of the call?” Yes, the call is being recorded, and we will send you the the recording and the transcript after. 

What else? We have some in the chat as well. “Are your designers embedded in local teams? If not any tips on how design, engineering, PM’s can collaborate globally and async?”

Dave Soetanto: Great question. I actually had a conversation with the design lead last, actually, this week. We don’t have them located in the the same physical location. But that’s mainly because we are like a global company. So the more focus is time zone overlap, we made sure that when we are going through our planning for the coming quarter. We had product and product engineering and design in the same time zone. So when it came time for them to reorganize for the coming quarter, they could review everything that was in or out of the quarter, and specifically for designers to be able to work ahead of schedule. So that way, they were able to, for the most part, review everything that was gonna come through and reduce the amount of free work. This also allowed us to work at a much leaner group size for the designers. So you know, it’s a bit of a give and take.

Ana Andrade: Awesome. Thank you. So Rachel is asking, “how do you ensure that strategic focus isn’t lost when we you engage product marketing later in the process?”

Dave Soetanto: So strategic focus is really defined at that higher executive level. And when I mentioned that we were talking about the KPI’s and making sure that we had those organized at that exact level. We also wanted to make sure that there was a story behind it. So when it comes to any kind of like slide, you’ll see just KPI. But we also have a system of record where anybody can go in and read the brief, of what the product manager or the chief product exec wrote about it, and how we are not there yet, and why we need to get there for the next stage for a company. Generally, that’s always linked inside of the roadmap slides, and always presented at every single SKO.

Ana Andrade: I hope that answers your question, Rachel. And thank you, Drew, for sharing Atlassian’s resources. I also heard about some GitLab documentation about async work. So that’s also a good resource for teams who are working globally right? At least for me, it’s helpful because I also work with US teams, on the European side. 

So let’s see if we have any additional questions, or if someone wants to jump into the big stage, now it’s the time, before we wrap up.

Dave Soetanto: I’m reading a question here by Drew, I think. “What are remote teams or satellite offices of the main company, or talking with contracted work from 3rd party resources.” Can I answer that?

Ana Andrade: Of course, and I’m sorry I missed that.

Dave Soetanto: Yeah, no. So they are satellite offices that are 100 employees, and the remote teams are not any less employees, or viewed as any less employees than any other ones. We are very much a global company, and we do have leadership in all of the different offices. So in the United States, I believe we’ve 4 or 3 offices. The satellite offices are mainly focused on sales. So as long as we focus on organizing ourselves to make sure that they’re aware this is what they do, then everybody’s still very much in the same information network.

When we’re talking about the larger group in India in particular, I have a easier time to plan with them personally, simply because of that API contract, so to say, we want to make sure we have, like all of the things in the right systems of record, and I can always rely on all of my product managers to make sure that everything is in that format where, whatever it is and wherever it is.

Closing Remarks

Ana Andrade: Alright. So, thanks a lot. I think that’s all the questions we have, and I think we are almost on time to wrap it up. So let me re-share my slide deck. Thank you all so much for your great questions, and thank you again, Dave, for your insights during this live Q&A.

Before we wrap up today’s session, I really want to share some helpful resources. The culture factor tool that Dave showed us is here for you to check. Leah is dropping the link in the chat. Also, don’t forget to connect with Dave on LinkedIn, if you want to continue the conversation with him.

Finally, I want to invite you all for an “Ask Me Anything” session that we will be hosting with our sponsor Dragonboat. This session will be featuring Aaron Hall who’s the VP of Portfolio Management at Carfax. Both Aaron and Dragonboat’s founder, Becky Flint, will be talking about how to accelerate strategic impact at scale on March 26. So if you want to join us, please scan the QR code in the screen or check the link that Leah also dropped in the chat. Feel free to register. I think it’s going to be a great session as well to learn more about portfolio management. And if you want, you can also invite your teams to join us.

Last, but not the least. Please feel free to join us in slack to continue this conversation. This doesn’t need to end up here, right? So I think that’s all for today. Thank you again, Dave, for sharing your real-life experiences, which I think it was super helpful, and a big thank you to all of you for joining us. I look forward to seeing you all next time. Have a great day and thanks again for being part of today’s session. Bye, bye!

Reference

• Product Ops HQ: https://www.productopshq.com
• Dragonboat: https://www.dragonboat.io
• Slack: https://slack.com
• Dave Soetanto on LinkedIn: https://www.linkedin.com/in/davesoetanto
• Egnyte: https://www.egnyte.com
• Ping Identity: https://www.pingidentity.com
• BigCommerce: https://www.bigcommerce.com
• PMP (Project Management Professional) by PMI: https://www.pmi.org/certifications/project-management-pmp
• CSP-SM (Certified Scrum Professional – ScrumMaster) by Scrum Alliance: https://www.scrumalliance.org/get-certified/scrum-master-track/certified-scrum-professional-scrummaster
• SAFe-SPC4.0 (SAFe Program Consultant 4.0): https://scaledagile.com/certification/courses/safe-program-consultant/
• Responsive PPM (Responsive Product Portfolio Management): https://responsiveppm.org
• Jira: https://www.atlassian.com/software/jira
• Jenkins: https://www.jenkins.io
• Geert Hofstede’s Cultural Dimensions Theory: https://hi.hofstede-insights.com/national-culture
• Atlassian’s “Team Anywhere” Model: https://www.atlassian.com/company/careers/teamanywhere
• Atlassian’s “Async Collaboration” Model: https://university.atlassian.com/student/path/1333162-async-collaboration-for-distributed-teams
  GitLab’s Handbook on “How to Embrace Asynchronous Communication for Remote Work”: https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous
• Tuckman’s Team Development Model: https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development