Building an Empowered Product Organization
I write about Product Management and Technology development. For more, you can follow me on Twitter or LinkedIn.
When I took over at Savi as their Head of Product, one of the first things I set out to do was to engage the entire company as Product acolytes. This is something I had seen done at Capital One, done myself at WEX, and was now repeating at a post-A startup. No doubt my Customer Service, Distribution, and Operations partners would have small requests for me (bugs, small features, etc.) that I would need to resolve. But they would also contain the power to identify, refine, and test new features that I want to add to my roadmap.
So the question is, how do you build not just an empowered product team, but an empowered product organization?
Defining an Empowered Product Organization (EPO)
I’m sure Cagan has his own definition, but here’s my own version. An Empowered Product Organization is one where everyone feels a shared sense of ownership of what should be on the roadmaps (click here for some good thoughts on Roadmap 101), and Product transparently owns what ultimately is on the roadmap.
This means that everyone, especially at companies under 100 people in size, feels an obligation to raise up bugs, customer opportunities, internal tool improvements and any other value-driving features that we could deliver. In return, Product synthesizes these inputs, puts together the roadmap, and goes on frequent roadshows to share it, explain it, and invite challenges from the rest of the company.
This last part is really critical. In order to ensure that the flow of ideas to Product stays unbiased, and uncompromised, almost academic in nature. If your partners start to feel that their viewpoints are unimportant, likely to be ignored, or otherwise not valued, your product will suffer*.
Building an EPO
As with most of my articles, everything below is basically lifted from my first product team at Capital One. My manager, fellow PM, and tech lead implemented systems so resilient that they remain the foundation of what I do at each new job several years later.
Step 1: Identify all of our key partners, and create Product acolytes. The first thing to do is list out all of the parts of the organization where new intent could come from. This is both where inspiration (e.g. new, user-need driven features) and “work” (bugs, sales driven features, etc.) might emerge. In a traditional company, this will be some combination of:
- Customer Service/Support/Success
- Account / Relationship Management
- Business Development
- Marketing / Growth
- Design / Research (if not already a part of Product)
Each team should identify one key person to be the liaison between Product and their team. Their explicit accountabilities should include:
- Soliciting new intent from the team
- Working with the Director to maintain a roughly prioritized list of intent
- Understanding the tradeoffs made by Product in the feature delivery process
- Helping coach their team on what’s been delivered, and what’s coming up next
Step 2: Build ceremonies taking in new intent. Once the key people are identified, it’s time to build ceremonies that “work smarter, not harder” for everyone.” There are three main ceremonies that I’ve used in my past:
- Bi-weekly Product Sync. In this ceremony, all of our Product Acolytes come together for an hour to introduce any new features they need, or changes to their internal prioritization. Given how often features overlap between teams, attendance should be mandatory. Features discussed should result in a specific decision by Product to discuss it separately, or do a live, mini-refinement (<5 minutes) to make sure Product can prioritize it appropriately later.
- Monthly Roadmap Review. This typically involves folks at the Director+ level, but allows all key constituents to review the roadmap, identify any gaps, and argue about any tradeoffs between one feature and another. Typically, this ceremony has been quite useful at identifying choke points, and rationalizing the value of different product features.
- Regular Product / Tech Planning. The frequency of this ceremony can vary by org and co-location structure, but this is basically a review of what we’re signing up for in the next quarter, and the true feasibility of it relative to dev resources and engineering priorities.
Step 3: Evangelize about Roadmap Principles. It is just as important to define your roadmap principles as it is to build the roadmap itself. Below is the first slide in my Roadmap deck which I shared with the entire company in each Sprint Update, and each Roadmap conversation. Principle 4 is my favorite: if you (i.e. anyone in the company) don’t understand something, you are not just encouraged to ask questions, you are obligated to do so. Only then will Product really benefit from the Wisdom of (Internal) Crowds.
So go on a roadshow! Create your own principles and sing them from the rooftops. I often joke that the more senior you are in PM, the more your job becomes about internal sales. This is a prime example.
Step 4: Celebrate the hell out of features that came from Step 2. Whenever I deliver a feature that came from one of our Product Acolytes, I celebrate it like crazy. Internal swag, slack celebrations, shout outs in the Sprint Updates, shared demos do the whole company, etc etc. It is so crucial that everyone knows that their voice influences Product (and it reinforces to Product that they need to be better listeners, in general).
Step 5: Iterate. Once the machine is running, it will require gas, oil changes, etc. But overall, it runs itself. Your job as a PM will go from herding cats to focusing on the exciting product work that motivated you to get into this job in the first place.
Share your thoughts below! I’m curious to hear what has allowed you to build roadmaps more effectively at organizations of all sizes.