The long and messy journey to product-based work, and why it was worth it
I first began working for CBC in 2006 as a Project Manager for the online production team. At the time, and for many years thereafter, it was a projectized environment in a complex, multi-stakeholder, multi–reporting line setting, often referred to as a high-matrix organization.
And then we made a significant change.
Fast forward to 2017. Products are succeeding and more people are using them. Our platforms are more stable. We are focused on the user. Innovative ideas are emerging. We are happier people.
Let’s go back to the beginning.
The expectation was that our processes would be rigorous, controlled and directed. Projects were funded by various sponsors, charters were created and Gantt charts were part of most conversations. Requirements and designs and budgets needed approval, and then, of course, the inevitable change requests ensued, which meant another round of requirements, designs and budgets.
We struggled with deadlines and funding. Project scope disproportionately determined what was delivered to the audience.
We weren’t relying on our in-house experts — designers, builders, maintainers and content producers. More importantly, project sponsors acted as the proxy for the audience. We were missing the magic that comes from directly connecting with users.
Clearly, we needed to change something. As a way to help us manage our ecosystem of platforms, producer tools and audience interfaces, we started learning about product management A product-based approach to our work would require us to think more long term and, most importantly, would force us to focus on the users above all else.
Sounds great, right? But transitioning from a project-based to product-based model was difficult. Only in hindsight do I realize that it was an incremental, multi-year, rather messy journey.
Previously, we relied on a functionally gated, waterfall approach to deliver prescribed products. Now, we gather evidence, test-drive products and continuously iterate. Many development teams adopted scrum or kanban strains of Agile.
We’ve improved how we gather evidence so we can better iterate.
A note on recommended reading: We learned about rapid build-measure-learn methods described in books like Lean Startup by Eric Ries. And we’re still a work in progress, fine tuning how to surface our riskiest assumptions, articulate useful hypotheses and validate them.
We also acquired new tools to enable things like multi-variant testing, feature-level audience measurement and user testing.
With time, we learned how to use the Agile methodology to pursue continuous integration practices. Now we’ve upped our game on testing automation and test-driven development.
How all of these changes directly affect our team members continues to be both the toughest and most personally gratifying dimension in this process.
Once upon a time, teams were formally created and disbanded as needed, with funding tied to defined deliverables. Now, we have have permanent product teams with stable, people-based funding for lifespan of the product.
Managers and other product stakeholders have pivoted from a posture of negotiating, directing and controlling to one of informing, enabling and empowering.
Product team members transitioned from delivering the pre-defined to defining the deliverables. This has increased their sense of ownership, responsibility, and emotional connection to their product’s success.
But don’t take my word for it — next week, we’ll give you another perspective. In his CBC Digital Labs post, Richard Loa, a developer turned product owner, will describe the growing pains and successes he observed during this transition.
