Increment: How do YouTrack’s product roadmaps and public tracker affect its product development strategy?

Elena Pishkova: Because YouTrack allows teams to manage their projects with the level of flexibility they want, it needs to be adjustable to any specific business scenario. The best way for us to learn about these scenarios is to be as close as we can to our customers and discuss their needs constantly. 

When we announce the strategic vision for product development for the next year or two, we get customer feedback [on the roadmap]. Some of these customers are happy to see long-awaited features, which confirms we’re moving in the right direction. Other customers express what they’d like to see on the list. This gives us an opportunity to explore the demand for new features and adjust our plans. To properly prioritize these tasks and set out the scope, we go deeper using the public tracker.

An excellent example of this approach is YouTrack’s Knowledge Base. There was a longstanding request for a feature that would allow customers to keep project documentation and notes alongside tasks. It had been gathering votes since 2011, and we were planning to address it [at some point]. But in 2019, when we published our roadmap for the first half of the year, we again heard from customers who wanted this feature. 

Instead of trying to build a tool right off the bat with lots of advanced functionality, we decided to take a different approach. We assessed customer votes and product discussions, and we limited the scope of the initial release to functionality requested by customers who were genuinely interested in it and who used YouTrack the most. The Knowledge Base was added to our next publicly announced roadmap, and we shared a list of hundreds of tasks for its minimum viable product on the public tracker. It was released in mid-2020.

What are the benefits and challenges of collaborating with customers on product strategy on public platforms?

Sharing plans and commitments publicly creates additional responsibilities. First, we need to fulfill our commitments while still keeping our plans flexible. Instead of tracking KPIs, we often make decisions about specific feature attributes on the go. This means some parts of our product might be released earlier or later than we estimated, but we believe our customers trust us to take time to release a high-quality product and understand that this flexibility allows us to rely on their feedback, too.

Second, a development engineer or feature owner might reach out to customers directly to get details on how something is expected to work. That only works when the entire team shares the same vision, attitude, and values toward collaboration. 

Finally, the entire process of working on any product flow, bug, or issue is also reported publicly in the tracker—from [a product team member] getting assigned a task to implementation, testing, and release. That’s a challenge because it makes negative feedback visible, but it also helps us build trust by making sure those affected by an issue get updates on it. We benefit from getting the information required for an investigation quickly, and we enjoy immediate confirmation and gratitude when something is fixed. 

Are updates to the tracker made in real time? Is there a team member who’s responsible for keeping it up-to-date?

YouTrack is the main tool our developers use to collaborate. We don’t create anything specifically to be accessed by our customers—we simply make our processes public and available to them.

In YouTrack, tasks have fields that reflect team processes. For software development, this usually includes the assignee; all stages of the process, from the first submission to testing; when it’s fixed and released; and product details, such as the component and build version. Once a task is assigned and the assignee starts working on it, they change the task’s status and comment on all stages as needed. We also use integrations such as IntelliJ IDEA and TeamCity, our build server system, which can automatically update tasks in YouTrack.

Our default setting for tasks is “visible to guest users,” and we only limit that visibility in specific cases—say, for a sensitive piece of data—to JetBrains employees, project teams, or specific individuals. That way, we can still have all of our work tracked in a single tool.

In an exchange on YouTrack’s public tracker, a team member shared that while the team does consider public votes and comments during product planning, that’s not the only criteria they rely on. What other criteria does the product team use to decide what to build? How do you ensure you’re building products that satisfy the needs of all customers, not just the most vocal ones?

We rely on multiple channels to communicate with our users directly. These include roadmaps, requests and issues submitted via the public tracker, and traditional forms of direct communication with customers, such as meetings, briefings, events, interviews, support tickets, social networks, messengers, forums, and user groups.

These requests are systematized, then we explore how they can be implemented. Requests range from minor changes to significant enhancements to a new part of the product altogether. To help us [contextualize and] execute on requests, we use product usage statistics, customer analytics and profiling, and extensive product, UI/UX, and customer experience research.

During customer research, we segment participants to reflect the customer base. For example, among our customers, 12 percent are CEOs, CTOs, and CIOs, and we have to consider their experiences when researching product development strategies. Another group is potential customers who are considering switching from another product.

An example of an experience that emerged from customer voting is YouTrack Lite. For a long time, we’d received some contradictory requests from our customers, who range from small startups with 10 team members to large enterprises with several thousand employees. Some needed the product to go deeper and pack more extensive functionality for software developers, while others expected the product to be more lightweight and work well for non-technical teams. Through extensive product and design research, we confirmed that people needed the flexibility to choose between two drastically different ways of working within the same company project. 

It took us about a year to fulfill these feature requests and launch YouTrack Lite while keeping the YouTrack Classic experience in place. Now, each user can choose between customized views of tasks in YouTrack Lite. Meanwhile, YouTrack Classic is still there to provide a well-known experience packed with issue management features for developers. 

Are there any particular challenges to managing customer expectations? If a requested product feature or issue isn’t prioritized by the product team, how do you handle that?

Many of our customers are building strategies for the next three to five years, so it’s beneficial for them to know if we’re working on something they might need in the future. We usually let our customers know that any plans are preliminary and that some of the items and dates may change. 

Ultimately, we manage expectations through transparency. If we feel the request can’t be prioritized, we share this information with customers right away. They’re also the first to know when that changes.

At times, we can find alternative solutions to customer requests. We might not deliver a feature out of the box, but we’re happy to go deeper into customers’ specific scenarios to check if customized workflows might help instead. 

How have the YouTrack product team’s internal dynamics changed as a result of directly engaging customers in the product development process?

Our technical support staff, product marketing managers, and sales engineers communicate with customers every day. They ensure all customer requests are given the attention they need, and they bring in relevant developers and other team members to discuss trickier questions.

We also have an “engineer on duty” role that’s randomly assigned to a different team member each day. The engineer on duty triages issues submitted by customers and makes sure they’re properly categorized, prioritized, and marked as related to the appropriate part of the product. This person also checks whether the task duplicates an existing issue or relates to other issues and links them if it does. This rotation ensures everyone on the team is tuned into customers’ feedback and experience.

Customer interactions and feedback are also a massive part of our internal chats, communications, planning and retrospective meetings, and daily standups. Feeling connected [to our customers] inspires us to do more and do better. 

Planning product strategy publicly is unusual. What makes you confident it’s the right approach for your team?

As a company, it feels right for us to be within reach of our customers. Digital spaces are getting more and more public. Closed user groups and forums are switching to open communities and massive networks. Customer support is no longer private, since it’s easier to share feedback on social networks or seek a response. Our goal is to be a part of all of these discussions. We enter them with information about our vision and product plans so [these conversations are] not only a reaction to something going wrong, but also a great exchange with the most experienced partners we have—the teams that use our service.