
When product teams waterfall their work, everyone faces critical risks. Here's how to turn the tide to collaborate in a parallel workflow.
Imagine this. For several weeks, you've heard about an upcoming feature for a product you've worked on before. Though product team members have been discussing user flows, functionality, and interfaces, no one has approached you for input on content design. Then, a week before launch, you're tapped to "just write the content" for multiple flows serving different audiences.
In traditional waterfall development processes, content designers might be excluded until just before release. And while you can deliver quickly, you also know the team and users will suffer when your full expertise—shaping information architecture, ensuring messaging consistency, and aligning content with business goals—isn’t reflected in every stage of the build.
When product teams waterfall their work, everyone faces critical risks:
For product managers
For product designers
For engineers
For users
So, how can you turn the tide to collaborate in a parallel workflow? The key is to show, not tell: Show how your full range of skills improves every stage of product building.
In roadmapping sessions at College Board, I don't just listen—I ask pointed questions to show that I'm thinking ahead about crucial messaging to convey to users, how content shapes the user experience, and how we can meet business goals. Take this opportunity to demonstrate your product knowledge and your strategic perspective.
You likely grasp substantive expertise as deeply as SMEs and other business stakeholders. Use that to your advantage!
After years of distilling complex education policies for users, my product teammates now see me as a crucial partner who understands our communication requirements and can translate them into natural language. This expertise also brings me into conversations with compliance SMEs to understand legal, privacy, and other regulatory implications, so I’m aware of any constraints well before delivering content.
I can't align stakeholder goals with user needs unless I access feedback directly. I get insights by:
This helps me create a coherent user experience that clearly guides users through flows all the way to completion.
When working in parallel with product designers, I can properly weave information architecture into the user experience. Using Ditto within Figma wireframes means our team approves content within the context of user flows, while also letting stakeholders zoom into a dedicated interface to decouple content review from design review when needed.
This also helps developers because when designs and content are approved concurrently, developers can build without multiple rounds of pouring copy into the codebase.
If there's no standard format for your team's content deliverables, create one. As my team's design deliverables have evolved, I've evolved, too. I used to deliver spreadsheets mapped to Zeplin wireframes and Drupal nodes, and when we switched to Figma, I proposed using Ditto.
Moving to a parallel track is difficult if content is stuck in spreadsheets or Word docs while design is in Figma. This is where a single source of truth for content, like Ditto, allows for content work to happen in sync with design and development.
At every stage, explain and show how your involvement enhances output. When I discuss my content choices through each delivery round, I frequently reference product requirements, user research, and design co-creation as core parts of my strategy. Ultimately, this shows how content solutions align with product goals.
Content designers must help build product teams that give them room to fully contribute. I realized that respectfully wielding my strengths would take me further and help colleagues view my contributions as critical.
Instead of a scenario that leaves you scrambling near the end, take your seat at the table early on. Advocate for full collaboration with your teammates, where content foundations elevate your product.

.png)
