Have you had one of these moments? You discover something new, yet vaguely familiar and think to yourself, “is this really a thing?” I have to be honest, this was my first thought when I saw the phrase Product Ops”. I am, of course, familiar with DevOps. I have a vague notion of Sales Ops and People Ops, but in all honesty those take place outside of the purview of what I do every day. But product? That’s my thing, man!
So I did a little Twitter poll. Turns out I was not alone:
The Ops in Product Ops
After thinking about it some more, and reading articles online by others, I came to this basic understanding: Ops is really just the practice of applying systems and automation to processes that can streamline and improve whatever it is that is being “Op’d”. When I thought about that and how we could do this in product, it all started to come together.
When you think about product strategy (or product management), it really comes down to two things: building the right thing and building the thing right. In order to do both of these things successfully, it is pertinent we bring insights into the decision process. Once that is done, we continue to do this iteratively, evolving it over time to be more and more useful and relevant to our users.
All of this requires a lot of data points. Luckily, product management software and application analytics have evolved to the point where it is common for an organization to have numerous applications that provide the data we need: analytics, research tools, NPS surveys, customer support data, A/B testing results, feature flagging data, and so on and so forth. Product Managers should be continuously utilizing this data, but it gets to a point where no single PM can keep up with it all.
A New Layer
This is where Product Ops comes in. The purpose of this “ops” layer is quite simple: to create systems, use automation, create communication channels – to do whatever it takes – to get actionable data out of all these tools to empower the product management team with the right information that they need to build the right product in the right way. Done properly, Product Ops will be capable of anticipating the needs of product managers to make the right decisions – finding anomalies in the data, finding opportunities for product expansion through social media sentiment gathering – whatever it takes.
In addition, Product Ops can further support product by operationalizing and automating the tracking of development, shipping of features and overall process of coordinating entire portfolios of products. This can aid in creating development efficiencies and optimizing the communication of product launches and upgrades throughout the organization.
So what does this role look like? The answer is it depends. Multiple factors will need to be considered to determine the best path for adding this layer to your organization. This can range from including a required skillset and time allocation on a smaller team, to an individual on a larger team, or even a full team in an enterprise environment.
Empowering with Data
Data plays a huge role in Product Ops. Now, it is common to have data analysts and user researchers. The differentiation will be that these roles will not be deployed in service of specific needs, but rather continuously to analyze, generate and report information as it pertains to the general and specific direction of the products at hand. They will use the tools of:
- Experimentation: A/B tests and feature tagging
- Product analytics
- Surveys and NPS data
- Customer support data
- Knowledge base data
- Social media sentiment mining
- User research
- Competitive research
- Business drivers and corporate vision
Product Ops will then take all of this data and distill the relevant information, so that the product team will have information that can enlighten their product design, roadmaps, and positioning.
Coordinating Development and Deployment
Where Product Ops will be most like DevOps in that it will also be tracking the development and deployment of apps. It will not be the code it is tracking, but rather the meta information about the code: the stories and epics and how they may or may not relate to other items in development on other teams. Product Ops done well will determine the ultimate strategy to gain efficiency by sharing code throughout a portfolio. To do this, they will rely on tools like:
- Issue tracking
- Portfolio management
- Design and prototyping tools
- Roadmapping tools
- Bug tracking
- Monitoring
Product Ops can use all of this data to understand what development is going on where and look for synergies and conflicts. Additionally, having a high level, yet detailed view across the entirety of your organization’s product development will yield opportunities for creating new efficiencies and finding problems that were never visible before.
Do You Need Product Ops?
So the question remains: does your organization need product ops? That depends on a few things. We’ve put together a list of questions to help drive your decision. Answer honestly.
- Is your product team mature enough? Are you already using user research and analytics to enlighten product decisions? Is your backlog deep enough and prioritized? Are you proactive or reactive in your product decisions? Product maturity is important if you want to commit to Product Ops and see it provide the results you need and want.
- Do you have a suite of tools (like the ones listed above) that your product team is using? If not, why? Is your product team is so busy with user research and product planning that they don’t have time to invest in them? This is a sure sign you may be a candidate. If you are using these tools, but you aren’t able to get all you want from them, that is another sign.
- Do you have any kind of portfolio management practices in place? Are they working? Do you use your issue tracking tool to its maximum potential and manage your backlog? You should definitely be optimizing your issue tracking tools. Having some kind of portfolio management planning in place should be a minimum. Again, Product Ops is meant to fill a gap that your current team is unable to fill.
- Are you growing and scaling your product team? A team of just a few people may not need Product Ops yet, but as you grow and scale, look for clues that there is redundant research, unused tools, inefficiencies in development, and lack of actionable data to highlight that you may need some Product Ops help.
The best place to start is with one person. Hire the right person who knows the tools and who understands products. They will need to be able to operate with little direction, as this is a very new field and they will have to figure it out as they go along. As they show value, allow them to make suggestions on how this role, and Product Ops in general, can grow within your organization. You can follow examples of companies that have embraced this role: SproutSocial, Uber and Stripe for starters.
Conclusion
The field of product is really quite young, and the advent of Product Ops – whether it goes by this name or not – is sure to bring higher value to product teams as they scale. By applying systems to the tools surrounding product, Product Ops has the opportunity to bring new value to product teams by connecting the dots they were unable to connect before. I look forward to watching the evolution of this new field. And, of course, if you are interested in trying this in your organization reach out any time.
Drew Falkman
Related Posts
-
Agile Development Teams: Size Matters
Can I make my project move faster if I simply add more team members? This…
-
Good Agile. Bad Agile.
There are Good Agile teams and there are Bad Agile teams. Building great software…