5 Reasons Why Technical Writers Need a Product Owner Too
At OutSystems, we have a centralized technical communication team. The team works closely with other engineering teams on product documentation. When I was invited to join, I learned that the team’s workload was rapidly increasing and they needed assistance with prioritizing and managing their backlog.
One of the inspiring things about working at OutSystems is that we believe there is always room to err and to improve. Our CEO Paulo Rosado says “We do not do anything right at first, but we try many times” (disclaimer: this is a link to a translated article). I love this mindset because it keeps us on our toes, we are always looking for ways to grow. Not long after joining the team, it was apparent to me that there was room to improve and that my guidance could help boost morale, the things we would work on were:
- Last-minute content and edit requests
- Changes in scope that affected predictability
- Lack of a sense of accomplishment due to high volumes of work, but few closed tasks
- Value-driven prioritization
The team was used to this constant pressure; they’d say, “Our team is special; it’s impossible to plan ahead,” or “We have all these tasks that different teams requested, and they are all a priority.” It was time for me to roll up my sleeves and do the 5 things necessary to address the challenges and pressure.
1. Shield the Team (or the Art of Saying No)
My top priority was to shield the team from constant interruption. At the time, we determined that there wouldn’t be scope changes during the sprint we had already committed to.
I started challenging the requests from the engineering teams and other stakeholders (e.g., Why do we need this? What’s the value of this? When should this be delivered? Is this that urgent?).
The results were almost immediate:
- Increased productivity: The team was more focused, and each technical writer could plan work without having to deal with incessant changes to context.
- More predictability: We started to understand how much the team was able to deliver in a two-week sprint, which led to better estimates and consistent delivery.
- Increased motivation: The team made more confident promises and then delivered.
Communication is key. Product owners must manage stakeholders’ expectations so that we achieve good collaboration and great results.
2. Own the Product
The engineering teams work at a fast pace, and sometimes the pressure to deliver features pushes the documentation to a lower priority. At this point, we are relying on the definition of value that the product owner of the development team has for the documentation.
As product owner of the technical communication team, I understood that I hadn’t joined the team just to manage dependencies and timelines. I had joined the team to own, manage, and strategize documentation as a product. It’s essential that we see documentation as a product in its own right. Documentation plays a critical role in a customer’s experience with the product. It helps users make the most of OutSystems, and if it doesn’t, users will become frustrated with the product and might even give up forever.
3. Make User-Centric and Data-Centric Decisions
When building applications with OutSystems, the possible use cases are infinite. The bigger the product, the more demanding users will be. They want more examples, more completeness, more depth. So it begs the question: what’s the best way to prioritize documentation?
A technical communication team needs a product owner with in-depth knowledge of the users to make user-centric decisions:
- What are the most common use cases?
- What do users struggle the most with?
- Where do they spend more time?
- What are users looking for but cannot find?
The product owner also makes data-driven decisions based on feedback from several sources:
- Feedback submitted by the users in forms at the bottom of the documentation pages
- Scores submitted by the users on the documentation pages
- Analytics gathered from the documentation pages
- Feedback from stakeholders (product management, support team, customer success, for example)
4. Deliver the Minimum Viable Product
One thing I have noticed is that my team seemed to be idealists. When you ask them “So, what’s the minimum we can write about this subject?” they will roll their eyes at you.
Incremental planning allows the team to deliver the most valuable piece of documentation first, so our users benefit from it earlier. And, we also receive feedback a lot sooner. When product owners teach the team to think from the problem side, the team starts to look for the quick wins to solve user pain. Some iterations later, our refinement meetings were mostly about splitting user stories and about having a value-driven Sprint. From then on, we were ready for continuous delivery and continuous integration.
5. Build a Long-Term Strategy
How can we write documentation that users will want to read? Is written documentation the best format for every part of the product? How useful is our documentation? What is our success criteria? To what degree are we accelerating the learning of the platform? How much time and money are our customers saving by having the content they need? What are the critical paths when using OutSystems? Should we invest in context-sensitive help? And most importantly: What is the best strategy for our documents?
Spoiler alert: we’re still trying to figure out the best answers to many of these questions. Without a strategy and roadmap, teams tend to focus on short-term performance. What I have learned is that the documentation team will start following a daily routine of delivering the requests of other engineering teams, lowering the priority of own its vision and aspirations.
Product owners should create and facilitate a shared vision with their teams; these are the people that give their best effort to execute the roadmap we drafted.
Our team has:
- Completed a design the box exercise to align with the outcomes we want to achieve.
- Designed our benefit dependency network to understand how to progress and achieve our vision.
Next steps:
- Align with the product management team and other stakeholders for a definition of our priorities.
- Have a roadmap that will keep us focused on the team’s long-term vision. ❤️
Dreaming About the Right Value
From an early age, we learn that dreams lead the way to greater things. They inspire us, fill us with joy, and motivate us.
We, the technical communication team, dream about providing OutSystems users with the knowledge they need to make their lives easier when using the product. We want them to be successful; we want to provide the tools to help them be productive and proficient in the platform with the least effort. When you believe in what you’re doing, you know that you are on the right track and that your vision of where to take our product is clear.
But let’s not just rely on our dreams; we must also fight important battles. But isn’t that the fun part? Product owners and product managers must work together to define a strategy to reach the end goal, one that will embrace innovation, align with market trends, and keep us ahead of the competition.
This journey has been very gratifying. A while ago, I joined a team that was heroically attempting to document everything that was requested by their many stakeholders; this put them under a lot of strain and was not sustainable. After overcoming many hurdles, we are now an organized and inspired team, our timeline is predictable, our eyes are on the future, and we are certain (and proud) about the value we deliver to our customers, sprint after sprint.
It’s my job to keep us on the right track to provide the right value to our users. Technical communication isn’t confined to documenting new features; it’s also about supporting users with the right information at the right time in the right way. I am the technical communication product owner, and I am proud of what we have achieved.
