This week, a post on Twitter/X by Félix López made me reflect on the importance of knowing how to tell your story and your impact on the organization. This entry is dedicated precisely to that aspect of the product world, and how in my experience as CPO, I faced the challenges of communication and observability, understanding the former, communication, as the set of actions that proactively provide information about product function initiatives, and the latter, observability, as the set of tools and artifacts you build to enable passive communication. We could perhaps talk about a push strategy for communications or a pull strategy.
I like to start these posts by describing the starting situation, what I found upon arriving. At that moment, I believe there are three key points.
The first point is that as CPO, I was fortunate to report directly to the CEO and be part of the executive committee (from here on referred to as ExCo). This is not necessarily the case in companies; there are various possible organizational models, such as the CPO reporting to the CTO, or the CMO, to name a couple of examples. But being directly in the room where things happen is a competitive advantage for this position because not only can you whisper in the CEO’s ear, but you also have a voice and a vote where decisions are being made.
However, not everything that glitters is gold, because despite being in that position, I lacked a lot of information about how the rest of the departments in the organization worked. You know what I always say: we are all product. If we wanted to carry out a transformation process, we had to understand how each department understood this product function and if it was aligned with the strategic objectives. That information did not flow much. Naturally, that access to information improved over time as I built relationships with the various members of the C-Level, but it is not an easy task.
Finally, the opposite situation occurred: in the ExCo, no one knew what a product manager was or what responsibilities product management had within the organization. As an anecdote, I will say that the CEO in the early iterations referred to my product initiatives as your projects, which I think is the worst thing you can say to a product manager, but well, we had come to make a transformation and changing the mindset was something to address.
So, from this starting point, what actions did I take to improve the communications and observability of the product functions?
Well, the first clear action was to start explaining the strategy in the ExCo to align the entire C-Level around the actions we wanted to take. To do this, in each executive committee, I brought a roadmap that included the key initiatives in the strategic lines agreed with the board, as well as other initiatives I considered including for this whole transformation process, such as the product processes and operating system that we will discuss in another entry. Additionally, I established monthly meetings with the various C-levels to address and discuss mutual needs in each dimension represented by that C-level member: CMO, COO, CFO, etc.
Since the communication lines upward (CEO and board) and with my peers (CXOs), other executive committee members, were covered with the ExCo conversations and these one-to-one meetings I mentioned earlier, the next step was downstream communications, both to my team and other teams.
For the product team, the communications were mainly in three lines:
- The main highlights from the executive committee (obviously only what can be shared). This allowed the teams to understand why they were seeing what was happening within the company and helped them manage their stress due to uncertainty.
- The strategy we were following and what the long-term goals were. In short, trying to visualize a bit what the success scenario was so that the team could make those micro-decisions in their day-to-day that would lead to an execution aligned with that strategy without depending on a manager’s decision-making. In a way, I was empowering the team and preparing it for a sustainable way of working where decisions would not be a bottleneck as they were before I arrived. My mental model for this approach is that if I won the lottery and retired (I still think it wouldn’t happen), this team could be working and achieving their goals independently.
- Sharing my concerns as CPO and listening to the team’s concerns. That is, building a psychologically safe environment where we could all express our challenges and perceptions without being judged for it.
There were also communications with other key people in the organization, such as the support department, where I gathered a lot of insights, sales, customer meetings, where I could understand their challenges and test my ideas.
On the other hand, we talked about observability, and in this sense, what I found was a greenfield. There was absolutely nothing; as in many organizations, there was tacit knowledge and a transfer of this information almost by osmosis.
In that sense, I tackled this challenge by building a knowledge base, a source of truth, that would serve as a reference for everything we were doing from the product side. We called it the Product Wiki and used Notion to organize it. One of the first artifacts we created was the use of a PRD (Product Requirement Description) to capture the description of new functionalities we were developing. The reality is that we didn’t use it for all functionalities, but for those that were perhaps more relevant. This served two purposes: one, for the observability itself, and the other, to help us organize ideas since writing requires structured thinking.
In this wiki, we also posted the roadmaps, as well as the release plans we worked on with the teams, which, along with the dashboards built on the backlog of functionalities, bugs, and repetitive operational tasks, constituted the set of artifacts known in the field of agility as information radiators. This allowed the teams to free themselves from constant questions from stakeholders about the status of their initiatives. Now we could simply refer them to a link where everyone could access it.
Finally, to complement these information radiators, we had two more initiatives. The first was to send release notes for each team sprint, indicating the main functionalities and product modifications. We did this in a higher-level language than that of the product teams themselves, and it was sent by each of the POs along with the recording of the demo session for each Sprint. Additionally, a second initiative was to create what we called product pills for the most critical functionalities, aimed mainly at salespeople and both internal and external users. This was a PDF document with more detailed information about the benefits and results that clients could obtain, as well as the process for activating and using these functionalities.
In summary, in this entry, I have reflected on the importance of communication and observability in the field of product management. As CPO, I faced the challenge of improving these aspects and implemented detailed communication strategies, such as the distribution and presentation of strategic roadmaps and monthly meetings with the C-level to align product initiatives with the company’s objectives. Additionally, we developed observability tools, such as a Product Wiki and information radiators, to improve transparency and reduce the need for constant inquiries from stakeholders. All these actions were key to transforming the product culture and improving the effectiveness of our initiatives.
I hope you enjoyed the post; tell me how you handle your communications. Do you have a team dedicated to communications and observability? What other communication and observability artifacts do you build for your products and services? Best regards and see you next week.