Work is Data; Adapting to Adapting to Change
Good talent can adapt faster than any tool; AI workflows mean we can build tools faster than ever; if you (a) focus on people and people's expections, and (b) treat work as open data (plain text, spreadsheets, lo-fi); then, your team will always be able to build what's needed at any time.
The one constant of Product Ops is change. In particular, my last organization was allergic to 'doing one thing for a while.' New tools were always being considered, processes always revised, and the carousel of change management was not a temporary beast to tame, but an embedded part of the culture. This won't be good for all orgs, but this way of approaching product work comes with many advantages.
For one, a constant willingness to explore, to change who was in the room, what information was relevant at what times, and fundamentally how product teams worked meant that resources could always be shuffled around to where they needed to be, when they needed to be there. Besides a few core staples, this openness also bled into the realm of tools. If there's an issue with transparency, people didn't just ask: "how can we communicate better?"; but also, "do we have the right source(s) of truth?", and "how can we ensure our partners have the information they need without an extra meeting or post?". These are powerful questions which can drive large and meaningful changes in people's work.
Sometimes the 'answer' to questions like these is simply 'people management,' but equally as often the status quo, the expectations people have about what their job is and how to do it, fail to live up to the change that happens in an org. Some people will do new work without the expectations of others changing to demand it; and others will continue to try and do the same work, while their peers begin to expect more, expect difference. Expectations change dramatically and different teams will be caught flat-footed not because they, the people, can't adapt, but because time was invested in a tool, in a material process, that no longer matches the new expectations.
When change is deeply embedded across an organization, new expectations drive the need for new tools and processes; and new tools and processes inspire the possibility of new expectations.
Good people will not just be able to adapt faster than off the shelf tools; good people will drive the demand for rapid change. It's our job in product operations not just to navigate or "manage" the change, but to support the imagination and demand. Not all product operations teams work the same way, but under the broad umbrella of 'product operations value' (be it driven by a director of engineering, an agile coach, a CTO, or a dedicated product operations team), adopting a tool strategy which prioritizes rapid change is key. Don't get trapped thinking that certain teams like certain tools; high functioning teams have goals and expectations about how they can interact with one anothers work, and tools simply facilitate this.
"Work", in this broad sense, can really mean anything—it's not standing in for a specific kind of output, but gesturing at all the elements and outputs of Product as a discpline: documentation, headcount and org charts, code, meeting notes and action items, slack posts, financial data, time tracking, and so on. There's no sense here where some work is privileged or distinct from other work, it's all needed to move an organization forward, and so it's all subject to the same changing expectations. If someone knows of an off the shelf tool that can rapidly and easily adapt to the changing expectations in all these areas, please let me know! Until proven otherwise, I intend to plant a flag, and one that I think is only further validated by the advancements in AI today:...
The way to keep our tools up to date with change is to treat everything we do in Product as data. Your documentation, your meeting notes, your org chart, your code, is all data which can be interacted with, queried, reformatted and re-presented. Keeping your work in open formats is mission critical to rapidly changing the context by which your work can be interacted with.
If your org commits to a specific tool that stores data in proprietary formats, binaries, or restricts your ability to interact with the data to an overly closed off API, then you're not just creating risk via a contract or pricing, you're limiting the possibility space for people's expectations. Either, the tool chosen, for whatever relevant work, becomes monolithic—it takes over the conversation, it says "no" to ideas people have or new emerging patterns in the way people coordinate their work—or, it becomes stagnant and the people being asked to use the tool outgrow it, outpace it.
Today, anyone with a bit of elbow grease and willingness to try can create internal tools to facilitate all areas of Product work. Strip away the "tool" itself, and ask yourself what the expectations are that someone has when it comes to interacting with the output. What information do they need? What kinds of things do they want to be able to do with that information? What formats, what ways and in what mediums, do they intend to share or reshape that information? How are teams doing and producing the work in the first place? Then, only once you have the scope of the expectations, represent the work as data. Take the slack post and put it in a markdown file; take the roadmap and put it into a csv; take the spike and put it in a folder in a gitrepo.
For those with the know-how already, I hope this insight has sparked your imagination for your team and what you can do today. For those intrigued but skeptical or not sure where to go, I'll share in a follow-up post (end to end, with recommendations on tangible next steps) how this approach can be used to attack a core Product process: goal tracking. If your org struggle with keeping people up to date and in the loop on the status of team's and department's goals, I hope my experience will help.