Leader Spotlight: Building an organization’s code of conduct, with Maksym Kunytsia

Maksym Kunytsia is Vice President of Product Management at Ideals, a virtual data room provider. He started his career in engineering, working as a frontend engineer for Digifico GmbH, a full-cycle product development company. Maksym then transitioned to product management while at Digifico and later became co-founder and head of product at Chanty. He moved on to join Ideals as a senior product manager and worked his way up to product leadership.

In our conversation, Maksym talks about Ideals’ code of conduct for collaboration, which is combined with continuous discovery and continuous delivery approaches. He discusses the importance of remaining transparent throughout the organization, as well as why company culture should be continuously iterating and improving.

Establishing a universal product culture

To begin, could you introduce Ideals for readers who may not be familiar with the company?

Sure. Ideals offers two products: Virtual Data Room, or VDR, and Board, which is for board governance. VDR is a secure place where users can upload documents, set up permissions, and invite third parties, such as potential buyers, investors, and auditors to review files you share with them. As the owner of those files, you can fully control permissions, engagement, tracking, and more.

Board is a relevant, adjacent product to VDR in that when you get money or raise a round of funding, you usually need the board to govern your investments. We provide software that allows users to set up board meetings and agendas, track motions, conduct surveys, and assign decisions.

You have extensive experience scaling product management organizations — earlier in your career you even founded a startup. Can you walk us through the challenges you often face when building a PM team and how you address them to ensure alignment with the company’s strategic vision?

Before Ideals, I co-founded a startup that competed with Slack. It was quite naive and optimistic of us to think we could compete with Slack, but we grew to hundreds of paying clients, and it was a very interesting and useful experience. When I joined Ideals, we had three PMs, no designers, and no analysts. Over the past five years, we scaled the team from just three people to 30 in product management and more than 100 in engineering.

The most challenging aspect of this is always culture — not just in terms of having different backgrounds, but in a lot of cases, the day-to-day work, company vision, and company strategy. Often, that’s not visible to everyone, but it should be because it impacts decision making. For example, as a company, should we implement this feature or that feature? Should we fix this bug right now or should we live with it to prioritize other things?

At Ideals, since we have two different products, these decisions can differ from one product to the other. When you already have a mature product with market share, you’re focusing your culture more on scaling and retaining your clients. “For us, this means that we invest a lot of resources into maintaining the best possible user experience. But our second product is more like a startup, so our main focus in that area is actually getting clients.

To handle this challenge, I prefer a document-first approach. I write everything down that I’m thinking about and share it with the team for iteration or feedback. The goals for each product are often different, which means the decision-making process is also different. The only way to show this is to write it down, conduct meetings, and give a lot of examples. Because of this need to share it with everyone, having it in written form is crucial.

Continuously iterating a code of conduct

Ideals has employees all over the world — what’s your process for demonstrating these decision-making processes to a dispersed workforce?

A lot of companies have their culture documented on their website within the careers page. We also have internal explanations of our culture with specific indicators. When we hire people, we have a step called CBI, or competency-based interviews, where our talent acquisition specialists talk about the behavior of candidates. This is a really important component that helps us find our people.

For example, a candidate can excel in a take-home assignment but not demonstrate what we believe is a good collaboration-oriented approach when we give them a specific scenario to talk through. Sometimes, we also read between the lines based on how a candidate describes their previous manager or company.

This doesn’t end on the company level either — it goes deeper. Within our product and engineering organization, we have our own code of conduct where we recommend how to collaborate with others. We try to visualize this based on what we’ve built so far, and then combine it with continuous discovery and continuous delivery approaches:

Do you continue to iterate on this process?

Absolutely — it’s a continuous process. It takes time for people to embrace it and see real examples. Especially nowadays, when a lot of things are impacted by AI, there are so many new tools and new approaches — so it’s constantly evolving. Plus, our company’s target market is shifting from SMB to larger enterprise clients, which also impacts our culture and goals. It’s a continuous set of changes and conversations.

I’ve found that the most effective way to communicate these changes is through 1:1s. It’s the safest environment to get feedback from your employees and deliver feedback to them. We do a 360 review for everyone and enable all of our employees to provide bidirectional feedback to anyone they’d like.

Measuring collaboration

When you measure the effectiveness of team collaboration, what metrics do you tend to rely on?

A product team works based on the specific individuals within it. There are different domain experts, and we have expectations for each one. This is public information, so, if you’re a backend engineer who’s curious whether your PM is doing everything they should be, you can read their job expectations. Then, you can provide feedback, voice any concerns, or identify areas for improvement:

In this, our teams can see our mission and corporate strategy and what we’re trying to achieve overall. Corporate strategy is about how and where we invest money and the ROI we expect. Then, we have a product strategy, and each product team has a target objective for each quarter. Further, people can contribute to goals that are assigned to several product teams. We track default metrics on velocity but also want to measure the quality of what they deliver. How does the feature perform in terms of user experience, technical, adoption, and other metrics?

Most importantly, we try to build connections with higher goals like revenue, churn, customer satisfaction, life time value, and so other metrics. We want to connect each goal to one of our four basic business values: increase revenue, protect revenue, reduce, or avoid costs.

Is there an example you could share, either from Ideals or from a previous role, where the collaboration between the different members of the team was especially critical in terms of getting the outcome you wanted?

We released our previous product version around 2015, and benefitted from it for many years. But, at some point, the technology and UX became outdated, and we decided to invest in a new version of the product. After building the engineering components, we started focusing on the go-to-market. This was a really challenging project — all client-facing teams were involved, as well as legal, billing, marketing, support, customer success, and more.

---

Over 200k product managers and developers use LogRocket to create better digital experiences

Learn more →

---

Overall, there were around 300 people involved, but we had one goal: to deliver this new version of the product to existing clients. Most people don’t like change, so persuading them to migrate to the new version was hard. We prepared sales enablement materials and educated all of our salespeople on how to sell this new version of the product. That included explaining all the new nuances, the best parts of the UX, etc.

We started this last March, and held weekly calls with sales and development to prepare. We included a small learning management program to explain everything, and, to make it more fun and exciting, we added a monetary reward for the person or team that created the best demo of the new version.

Within three months of the launch, we migrated our thousands of existing clients and started to sell this new version of the product with much higher conversion rates. The key takeaways from this experience are to be as open as possible during collaboration and to clearly identify the goal. Don’t just collaborate on paper — be open to feedback and change, even if you don’t like it. Explain the business and product goals, and add a reward mechanism so people are excited to launch and sell the product.

The importance of remaining transparent

You talked about how important it is to be open to feedback as a leader. What is your approach to collecting that feedback from different teams?

We’re open to gathering ideas from everywhere, including market competitors, clients, stakeholders. We aggregate feedback from Slack channels, emails, and integrations with our CRM and support software so product managers have easy access to this feedback:

Also, in receiving feedback, it’s important not to just say no without giving an explanation. That disincentivizes people to share feedback with you in the future. But, if you provide the right context and receive feedback with grace, you’ll establish an endless feedback loop from different sources. Sometimes, you can build what a client told you to build, yet nobody will use it and you will not receive any outcomes. That’s why my product managers exist to not just listen to clients, but conduct wider research. This is good for gaining context and explaining decisions to other departments.

With all of the information that your different teams collect and synthesize, how do you avoid silos, where data just ends up in one area and maybe isn’t shared widely?

Overall, our company is very open and transparent. For example, literally everyone in the company can see our revenue numbers, total number of clients, company code of conduct, product strategy, and more. We also utilize Slack a lot, so we have individual channels for cross-teams collaboration, various initiatives, and so on. On Slack specifically, I find that it’s important for a responsible PM to respond to a message if it’s related to their product area. This is because the best things happen on the peer-to-peer level. It creates a different, closer level of collaboration.

Further, despite being remote, we occasionally conduct offline events. At these events, we want people to communicate on a more personal level. When we establish this chain of relationships, people get to know each other personally and act differently in the best way. For remote-first companies especially, it’s critical to build these personal relationships. Doing so enables the company to achieve great things.

LogRocket generates product insights that lead to meaningful action

LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.

With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.

Get your teams on the same page — try LogRocket today.