How We Transformed Our Product Team with 3 Small But Powerful Changes

Product Management is hard! Setting the right priorities to maximize customer satisfaction, creating alignment with stakeholders, collaboration with other departments, keeping focus yet staying open to external triggers, and the list goes on… Trying to do it right requires constant effort, especially if your starting point is lacking a bit! 

A few quarters back we got some cues that led us to inspect the role of our Product Team and rethink how we collaborate with the rest of the company. Here are some of the “hints” we got:

• We released features, in which we’ve invested time and energy, that our users were not using!
• Product managers felt demotivated, not challenged, or developing personally.
• Our engineers and product managers clearly shared the need to better understand WHY we are doing the things we do and how they contribute to the success of Transifex.

Retrospectively we could identify these problematic areas:

• Focus: We struggled to stay focused on our path and we spread ourselves and our engineering team too thin. We kept setting a direction but in the end, we found ourselves working on things that were not helping us get there.
• Autonomy: Product managers had little say on what was a priority, as well as on why and how it should be handled. In many cases, we acted more like task managers than decision-makers, which was not only demotivating but also unproductive, as we were not taking advantage of our great minds and skills.
• Alignment: We weren’t all on the same page about why we were doing things. This made it impossible to communicate our goals properly to the rest of the company, which is our responsibility.

We realized that our Product team needed to step up, gather data, build confidence about knowing our customers’ needs, and build a strategic roadmap to address those needs.

The timing was perfect. Our Product team had enough people with a variety of skills and personalities that complemented each other and everyone was eager to do their best work to grow in their role. After several years the whole product team was located in Greece, removing the impediment of time zone differences. At the same time, our engineering team was mature and eager to step up and support the Product team. Finally, we set a new exciting strategy for Transifex Native that required all hands on deck and gave us a new sense of purpose.

And so the change began. This change did not happen overnight nor was it based on a plan; it happened through continuous inspection, adaptation, and teamwork. Below you will find three small but powerful changes that in retrospect helped us transform our product team. 

1. Revisit goal setting processes

In an attempt to set clear objectives, stay focused, and communicate progress, we are using OKRs (Objectives & Key Results) and a timeline roadmap. Even though we have had these in place for years in many cases they have failed in achieving their purpose.

OKRs

We adopted OKRs several years ago, and although we used to set our OKRs quarterly, in reality, we ended up working on totally different goals during the quarter. We used to set them and forget them. We always missed check-ins and did not align our everyday work with those OKRs. It was as though our OKRs were set on top of everything else we had to do anyway.

So what are we doing differently now? 

• We create the OKRs collaboratively as a Product team after we brainstorm rather than having them be announced by Management.
• We make sure they are aligned with the company’s and other teams’ OKRs.
• We specify Objectives that describe the expected outcome rather than list the tasks by which we will achieve the goals. This gives us the flexibility to decide how we will achieve the objective during the quarter.
• We stopped setting more than 3 OKRs.
• We always set one OKR related to our internal processes to improve the way we work as a Product team. 
• We check-in on OKR progress together in our weekly product meetings, so our weekly priorities evolve around our quarterly OKRs. Each week we get a step closer to our objectives.
• At the end of the quarter, we gather as a team, rate our performance, and reflect on each objective. This way we can celebrate our achievements and learn from our failures. 

Lean Roadmap vs Timeline Roadmap

In the past, we would spend several hours negotiating the timeline of a yearly roadmap. We would set priorities and estimations, then add extra lanes for the smaller items, change colors, write big letters, then small letters, and move everything around. In the end, it was all in vain as we are truly an agile company that adapts to a constantly changing environment. So this was a waste of time and it only caused frustration as it created false expectations that we could not and we should not try to satisfy in the first place.

Here is what the structure of our roadmap looks like today:

In the current column, we have the items that we are currently working on or the ones that are about to start. In the medium term column, we have the items we intend to work on in the near future as long as things don’t change. In the long term column, we have the items we would like to work on in the not so near future. Moving from the left column to the right one the items become more and more abstract as the unknown factors increase exponentially. This roadmap has no estimations on it. It only shows priorities and intentions.

OKRs, together with a Lean Roadmap, are all we need in order for our company and our users to:

• see the direction in which we are heading,
• have transparency,
• be aligned,
• give feedback,
• and have some basic predictability.

2. Product Newspaper

Transifex has two offices: one in California and one in Greece. These two offices not only have a 10 hours difference between them but they also have different mindsets in some cases. The Greek office is mostly engineers and the US office is mostly business operations, so despite our heroic efforts to be aligned, we became masters of creating silos.

A few quarters ago we took a step back and decided to treat our communication issues as we treat our customers’ problems. So we sent out a survey to the whole company trying to gather data and better understand the problem. We wanted to know where we stood and what our colleagues were interested in. 

Here is what we found out our colleagues wanted to know about:

1. Progress and Activity

• What is the Product Team working on?
• A summary of what was released, what is coming next, and future plans (short and long-term).
• When and how to provide feedback regarding priorities or implementation.
• What is going to be released so that they can take action and contribute to the release?
• What is the state of specific tickets (have they been reviewed, planned, rejected, etc.)?

2. General Knowledge:

• How strategy is decided and shaped.
• Product vision and intentions.
• Market positioning and competitive advantages.
• The reasoning behind our priorities/decisions.
• ROI & impact for things we’re building and maintaining.
• Feature adoption and new learnings.
• What our users are doing and how to help them do it better.

It was also clear that we needed to expose this info in a simple, centralized, and consistent way.

We wanted to create an interesting, concise and maybe even fun way for the whole company to get updates from the product team. The first thing that came to mind was a newsletter, but let’s admit it, newsletters are rarely interesting or fun. So we wanted to create something that will not lead people to look for the unsubscribe button. Instead, we wanted to create something they could read casually on their own time, during a 5 min break. Something that would have a variety of topics for all kinds of tastes but be formatted in a predictable way so that it becomes easier and easier to read it over time. 

Enter the Product Newspaper. The Product team issues what we call the Product Newspaper every two weeks. It follows a template so people know which sections have the information they are interested in. The consistent sections we’ve included so far are Roadmap updates, Strategy Updates, announcements of recent and upcoming releases, product OKR status, and Product Insights. There are also free sections about items worth noting since the last issue, like our recent competition analysis, team changes, or just something new we learned. We also added a Joke section, but we admit that some of the jokes are not as funny as we hoped they would be :-p

We make sure that all issues of the Product Newspaper can be found in one central place (Confluence, in our case), that we are always delivering them on time, and that we announce every new issue both on Slack and via email to make sure people don’t miss it.

Even though this initiative was originally intended to pass information to the rest of the company, it has actually deeply affected the way we work as a Product team. It has made us more transparent, aligned, accountable, and open to the rest of the company.

Lately, our newspaper has even become interactive as people have started to add comments and suggestions at the bottom of the Confluence pages. We make sure to reply to all comments and act on feedback in an effort to encourage more interaction.

3. Move away from Project Management and closer to customers

Localization is tricky. Everyone does it in a different way because companies usually start thinking about it too late and often after they are already set on a specific way of work. On top of that, Transifex targets agile companies which, apart from doing agile development, also means making changes in the way they work to follow modern practices and improve. As a result, there is always new information our Product team needs to know about our customers and their problems in order for us to solve them effectively. 

So how do you get to know these problems first hand?

Here at Transifex, we have an awesome Customer Success (CS) team – if you are using Transifex you probably already know this. The information they collect can be found in our Jira. They are doing an amazing job gathering all the data they collect from customers, grouping that data, and adding metadata so that we can get a good idea of what the issues are. In these tickets, our CS team even tries to quote our customers though in many cases the customer describes a solution rather than a problem. This leads to miscommunication and the real need behind a request might be concealed.

The CS team is still one of our main points of information as they are in constant communication with our customers. But the Product team has made a huge shift recently and created direct connections with our customers. The tools we’ve used so far are user interviews, usability testing, demoing beta features, joining Quarterly Business Reviews (QBRs), and webinars. When possible we even visit our customers’ offices.

This shift came with a bonus. At Transifex, we value work-life balance. It is one of our core values. So how could we add all these time-consuming sessions to our already packed schedules? The answer came from our engineering team. 

In order for our team to create time to speak directly to customers, we needed to let go of our old ways. One of the most time-consuming tasks was our involvement in the “WHAT” of each project. Grooming sessions, ticket estimations, acceptance criteria, etc. were taking valuable time away from the “WHY”. It is after all within the core of the product management discipline to guide teams towards solving the right problems.  What if engineers could own most of the “WHAT” for each project? Thus, little by little, our Product team is shifting from fully owning the “WHAT” to sharing it with the engineering team, allowing both teams to step up in their roles.

Aaaand this is it, we are a whole different team! 

• We are much more focused since we set stretched but realistic goals collaboratively.
• We keep all teams and ourselves engaged and excited by putting all we know and do in the product newspaper.
• We own our stuff since we know it first hand by being close to our customers.

Don’t get us wrong, we have not found all the solutions to our problems. Actually many of our current solutions might be our future problems. Isn’t this the case when you are bold enough to try new things? So far these changes have led to an increase in our customer and employee satisfaction. So we believe we are on the right track. We will keep inspecting and adapt as needed!