There’s a conversation I’ve had more times than I can count, and it usually goes something like this: An organisation wants to adopt a new tool. Someone has already done the research, maybe started a trial or two. There’s palpable enthusiasm - possibly a dedicated Slack channel. And somewhere in the middle of all that momentum, they ask me what I think.

My first question is always the same: what problem are you trying to solve?

Sadly, the conversation usually gets a lot quieter after that.

This isn’t a new dynamic. I’ve been working with product organisations on their tooling for years, and in that time I’ve watched the same pattern play out at companies of every size, maturity, and vertical. Most organisations treat tool adoption as a decision - do we buy this or don’t we? Completely ignoring that what should be a structured and nuanced evaluation has been reduced to a binary, thus bypassing all the questions that would tell you whether this is actually the right fit, for this team, for this org, at this moment.

Do this often enough and the result is an operating system that grows faster than anyone can manage, is maintained by nobody in particular, and was evaluated by nothing more rigorous than how enthusiastically it was onboarded.

Subscribe now

A Hammer Without A Nail

Most tooling adoptions usually start with a legitimate problem. Teams are struggling to communicate priorities, or discovery is getting lost before it reaches development, or stakeholders keep asking questions that nobody can answer quickly. Something is genuinely broken. But instead of staying with that problem long enough to understand it properly, the conversation jumps almost immediately to solutions. We need a roadmapping tool. We need a research repository. We need a better way to manage our backlog.

From there, the evaluation rapidly becomes a feature comparison. Someone pulls together the top ten options. Demos get scheduled. A spreadsheet appears, mapping capabilities across vendors. And somewhere in the process of weighing integrations and pricing tiers and UI preferences, the original problem drifts to the back of the room. Nobody asked whether the real issue was cross-departmental visibility, or delivery credibility, or that sales didn’t have anything that would help them close deals. The problem was never communicated with enough specificity to be evaluated against - so the evaluation becomes about the tools themselves, as if you were buying a toaster.

And thus success, by the end of it, becomes about finding a tool, not solving the problem that prompted the search. And because success was never defined in any more concrete terms than that, there’s no basis on which to run a real trial, no exit criteria if things go wrong, nobody accountable for whether this actually changes anything. The tool then gets dropped into an existing operating system without anyone asking what happens before and after it - where information comes from, where it flows to, whether it creates new decision points or removes old ones. Instead, the final questions are always the same: what’s the price, how many licenses do we need, and how many features do we get?

Applying The Discipline You Already Have

The frustrating thing is that product people know how to do this correctly. They do it every day.

Before a feature gets built, there’s a problem statement. Before a solution gets committed to, there’s a hypothesis. Before it scales, there’s validation. Ownership is assigned, success is defined, and at some point someone asks whether it has been achieved. This is the discipline that separates good product organisations from reactive ones, and most product teams know what good looks like.

Then it’s time to buy a tool and none of it gets applied.

There’s no discovery phase for the problem the tool is supposed to solve. There’s no hypothesis, no trial with defined success criteria, no accountability for whether it changed anything. The same Product Leader who would push back hard on a feature request that lacks a clear problem statement will approve a tool purchase on the basis of a compelling demo and a favourable price per seat. The same organisation that treats “we’ll know it when we see it” as a red flag in a product brief will accept it as a perfectly reasonable measure of tooling success.

The result is an accountability vacuum. When nobody owns the evaluation, nobody owns the outcome either. And when nobody owns the outcome, there’s no mechanism to recognise failure - which means no mechanism to course-correct, retire what isn’t working, or learn anything ahead of next time.

Tools accumulate. Costs compound. The operating system becomes the thing that slows everyone down.

The Tool Adoption Canvas

I created this canvas because I was tired of seeing companies make the same mistakes over and over again - especially as AI tool adoption has added a whole new layer of urgency and volume to the problem. The canvas is a single-page document that brings that discipline you already have to tool adoption decisions. It’s the same questions good product teams already ask, just applied to a place they’ve been ignoring.

It’s available below in two versions - one fancy, one black and white - each with three templates: one with guiding questions to help you work through each section, one completed example so you can see what good looks like in practice, and a blank version for you to use as you see fit.

If the canvas slows down your tooling procurement process, good - it means it’s doing its job.

Tool Adoption Canvas

624KB ∙ PDF file

Download

Download

Print Version Tool Adoption Canvas

607KB ∙ PDF file

Download

Download

Last month, I gave the closing keynote at Design Ops London.

The talk was about operational disciplines - Product Ops, Design Ops, you name it - and the single thing that determines whether they survive and thrive inside an organisation, or get deprioritised and then laid off when budgets tighten. My argument was blunt: if you are in an operational role …

Read more

But now we’ve gone further and deeper with the analysis, with a little help from HyperAgent, to produce a comprehensive analysis and report of what those figures actually mean for us as professionals and our careers.

For ease of use, we have produced a version in USD ($) and a version in GBP (£).

Report (USD)

Report (GBP)

Enjoy, and please comment with your thoughts on the findings.

Graham & Antonia

Share Product Ops Confidential

We’re back with the Product Ops Salary & Role Survey, specifically for Product Ops Professionals. Throughout late-2025, Product Ops professionals shared their feedback, and now the results are in.

This survey aims to provide a crowd-sourced baseline and reference for professionals either seeking new roles or curious about their own salary, or for hiring managers looking to create new Product Ops roles.

Once again, the results are super interesting.

As usual, this survey was interested in more than just money; it also aimed to find out the different sizes of Product Operations teams, in comparison to product, tech and business sizes too.

We are pleased to share with you the results via an interactive analysis dashboard (via Airtable).

See Analysis

Enjoy, and please comment with your thoughts on the findings.

Graham & Antonia

Share Product Ops Confidential

Along with our Product Ops Jobseekers Database (read all about this here), we’re pleased to share some great, useful tools built by friends or fellow professionals to support you on your jobseeking adventure/nightmare 😆.

We’ve reviewed each of these tools (and in some cases provided early advice and feedback during development), but it goes without saying these are independent services and not provided by or connected to Product Ops Confidential. Product Ops Confidential receives NO referral fees or other payments

We’ll regularly add tools to this list as we discover them, so bookmark this page and check back regularly!

Manage your job-seeking journey

Jasper from Dreamwork-HR (Created by Michael Kincaid)

Price: Free (as of November 2025)

Jasper provides a one-stop-shop to manage everything relating to job applications, AI-supported, tailored CVs & cover letters, document management and more. While most of these types of tools are already available, having them all in one place under one interconnected platform makes a lot of sense. Something we’ve not seen in a tool - but of course we have all built ourselves in a spreadsheet - is an opportunity/application tracker. What have we applied for, when and what stage are we at with it.

Try Now

Show what you have built as a Product Professional with a portfolio

Prodfolio (Created by Santiana Brace & Meagan Glenn)

Price: $0 - $23 per month - See here

Let’s face it - LinkedIn is terrible at SHOWING what product professionals have built with limited tooling and little support for media. Up steps Prodfolio, the portfolio for product people.

The goal is simple: help PMs tell better stories about their work. Structured, fast, credible. It isn’t just for job hunting, it’s for documenting what you’ve built and owning your story. You can turn your work into case studies that show outcomes, not just responsibilities, as is typical on CVs, and literally paint a picture for hiring managers of what you have actually done. And much like LinkedIn, this is something to keep and maintain throughout your career and share your successes again and again.

Try Now

More coming soon…

We’re back with the Product Ops Salary & Role Survey, specifically for Product Ops Professionals.

This survey aims to provide a crowd-sourced baseline and reference for professionals either seeking new roles or curious about their own salary, or for hiring managers looking to create new Product Ops roles.

The results from 2024 are available here:

This saw …

Read more

We are glad to provide this free service to match and recommend great professionals with enthusiastic hiring managers and exciting Product Ops positions globally.

Read what others say about us and this initiative (we’ll add more comments as they come in), from those we have helped:

has had a huge impact on my career - without his support, I wouldn’t be in Product Operations today, and he was a key player in helping me move into my current role. He’s consistently responsive, collaborative, and generous with his time, always offering advice and insight that have helped me grow my skills and confidence. I’ve learned so much from his deep knowledge of Product Operations, and he’s someone I truly look up to and turn to when I’m looking to continuously upskill. On top of that, he’s friendly, approachable, and a great person to speak with!

John Ellis - Principle, Product Operations - Accelya

taught me many valuable insights and a solid understanding of product management basics. His approach to the human aspect of the role, explained with real-life examples, really stood out.

He has incredible teaching skills, making complex concepts accessible and engaging. As someone who often finds it challenging to remain focused, he kept my attention throughout each lesson of the course.

I feel fortunate to have been a part of this learning journey and would highly recommend his courses to anyone looking to deepen their understanding of product management.

Katia De Juan, Product Designer & Aspiring Product Manager

has been an incredible mentor and a true champion of my career journey over the past 1 year. His unwavering support and advocacy have opened doors for me, most notably connecting me to my current role in Product Operations through his job-matching database. His newsletters have been a constant source of inspiration and practical wisdom, filled with actionable tips that have genuinely shaped my approach to Product Ops.

He is generous in sharing knowledge and his commitment to uplifting others. I consider him not only a mentor but a strong ally and advocate for my growth, and I’m deeply grateful for the impact he’s had —and continues to have—on my professional path.

Catherine Damisa, Lead Product Operations Manager, One Advanced

The Product Operations Manifesto is a set of principles, commitments and prerequisites for successful Product Operations.

Since its release in Spring 2023, the Product Operations Manifesto has been used by Product Ops folks to define their roles, by companies to share their beliefs, and by leaders to understand the implications of investing in the role. Having been co-signed by nearly 200 global practitioners and leaders, the Manifesto continues to resonate with operators across industries and roles.

The Manifesto project was spearheaded by our very own , and co-written by twelve Product Operations leaders in close collaboration. If you’d like to learn more about its inception, watch Antonia deep dive into the why, how, and what of the Product Operations Manifesto at Product at Heart 2023.

Read the Product Operations Manifesto here

Share Product Ops Confidential

c/o: Product Led Alliance

Covering:

🏗️ Team structures
📈 Emerging responsibilities
😰 Persistent growing pains
🧮 Measurement gaps
🖥️ Tech stack challenges
🤖 The influence of AI

“Today, the challenge isn’t proving the value of product ops – it’s cementing the function as a core driver of strategic business outcomes”

Contributions and analysis from Graham Reed, plus Product Ops Chronicles Podcast guests and leading industry minds Topher Fox, Clare Hawthorne & Chris Butler.

Download The State of Product Ops Report: 2025

Share Product Ops Confidential

We typically do not comment on such analysis, but the results have been very interesting, if not surprising.

This survey was interested in more than just money; it also aimed to find out the different sizes of Product Operations teams, in comparison to product, tech and business sizes too.

We are pleased to share with you the results via an interactive analysis dashboard (via Airtable).

CLICK HERE FOR THE ANALYSIS

Enjoy, and please comment with your thoughts on the findings.

Graham & Antonia

Share Product Ops Confidential

This is a free service to job seekers - at no time will it cost you to be part of this initiative (We may receive referral payments for the successful placement of applicants if offered, but that is not the point of doing this).

How does this work?

The overall point of this is to make connections between hiring managers looking specifically for Product Operations professionals, and those professionals looking for their first or next role.

There are similar initiatives out there, and you should use them all! This is different in that your details are NOT available publically - this is specifically for us to use when we are speaking to interested parties.

In addition, we make a point of being trusted with our recommendations - and we will only recommend professionals we know, either having worked with, collaborated with at events, communities, podcasts, articles or other connections. We will not recommend anyone unless we can legitimately recommend them.

To that end, inclusion in this database is restricted - contact us on LinkedIn to gain access.

Note: At this time, you cannot review your information or update it - if you want to see the data you submitted/change it/remove it, get in touch with us.

Safeguards

The information you supply is strictly confidential between you and Graham & Antonia. The information will not be made public, not be shared with anyone for any reason - with the exception of contact details where consented, and even your presence within the database will not be revealed - particularly to any current employer.

Contact details only, will only be shared, with your consent, with hiring managers/recruiters on an individual basis, when a match between role, location, etc and yourself has been assessed by us. You can remove your consent and/or yourself from the database at any time for any reason - contact us on LinkedIn.

Inclusion in this database in no way guarantees any job or any recommendation made. We reserve the right to remove any record from this database at any time without notice. Roles will not be posted anywhere, this is purely to allow us to recommend you to suitable roles as they appear to him. We may use your email address to contact you for other professional reasons in the future.

If all of this is good:

Complete the Form Here

Share Product Ops Confidential

Following on from the deep-dive into Product Ideas/ Feature Requests Forms & Workflows, and the nuances of how this simple function can support changing behaviours and embedding new ways of thinking in colleagues, this article was born.

Alongside this, I have seen with increasing regularity recently, requests for recommendations and reviews of product ideas facilities and management tools.

With my Product Ops Hat of Efficiency (kinda like a poor-mans Sorting Hat from Harry Potter fame!) on, I wanted to provide a place for both incumbents and up-and-coming platforms in this space to get some screentime, with some warts-and-all reviews. These reviews, however, are provided by real users and professionals who have implemented the platforms successfully - so no sales pitches, no marketing BS. Crowd-sourced reviews, asking the following questions:

• The unique challenges to solve

• The approach & what was delivered

• How the product added value to those submitting requests, and to those receiving the requests

• Pros

• Cons

Here is what is reviewed in this article:

aHa! Ideas - by Justin Woods

Jira Product Discovery - by Suryansh Dhingra

SalesForce Custom Objects - by Damien Harr

UserVoice - by Jana Debusk

LaunchNotes - by Chelsea Grint

VersionLens - by Feras Wilson

ProdCamp - by Mike Walters

ProductBoard - by Christopher Fox

ClickUp - by Graham Reed

Enjoy!

aHa! Ideas

Reviewed by: Justin Woods - Consultant and Roadmapping Expert at Roadmap Heroes

The unique challenges to solve 

The client had a specific need to: 

• Capture external requests from customers as well as internal ideas from employees 

• Centralise idea management and consolidate tools / processes 

• Improve transparency of product development process and provide timely communications 

The approach & what was delivered 

The client was already using Aha! Roadmaps which includes Aha! Ideas Essentials. 

Our approach: 

• Understand the problem, the existing systems, and define the future state 

• Establish processes for handling new ideas, enhancements, defects, and support requests. 

• Determine which teams will handle specific types of requests and in which system 

• Configure Aha! to meet the defined process and migrate records to new system 

• Conduct training sessions for employees to ensure a smooth adoption of the new system 

What we delivered 

• Implemented a public ideas portal to capture customer requests with mandatory fields to ensure key information is collected: 

• What is the problem? – trying to get out of solution mode 

• When (ideally) is it required? – rough indication of urgency (week, month, quarter, year) 

• How many users would benefit? – rough indication of reach 

• Enabled employees to submit ideas directly into Aha!, capture additional company-specific information such as business case, impact opportunity size, and return on investment 

• Enhanced integration between ideas management and product management 

• Introduce guideline timings and SLAs for idea management including how updates and communications should be handled 

• Retired the standalone website-driven portal and imported existing records into Aha! Ideas 

How the product added value to those submitting requests, and to those receiving the requests 

Value to those submitting: 

• Provided a simple, branded portal experience for ideas and request submission 

• Clarified user journeys on how to get help for different types of requests (support, defects, new requests, enhancements) 

• Set expectations for idea management process and timings 

• Automated communications for important updates such as idea votes, comments and status changes 

Value to those receiving: 

• Centralised system for all ideas (customer and employee), integrated with Aha! Roadmaps), retiring the old system 

• Mandatory fields ensure all necessary information for idea evaluation is complete 

• Consistent prioritisation of ideas based on scoring, value, and alignment to goals 

• Idea statuses set expectations without committing to delivery timescales 

• Dynamic reporting for improved idea management and stakeholder updates 

Pros 

• Unlimited idea portals and portal users 

• Reasonable pricing model (you pay for idea management users not the number of idea portal users) 

• Highly configurable portal / in-app experience with branding options 

Cons 

• Can’t send ideas directly to a development tool (JIRA, ADO etc.) unless you also use Aha! Roadmaps 

• Can’t integrate with some popular CRM / support tools e.g. Hubspot, Intercom 

Jira Product Discovery

Reviewed by: Suryansh Dhingra - Product Operations Lead at Nord Security

Unique challenges to solve

In my role as a Product Operations Lead for a Product Organization that develops a single product across multiple platforms (Windows, MacOS, iOS, Android, etc.), we face unique challenges that we aim to address using Jira Product Discovery (JPD). Our organization also has shared Data, Design, and Product Operations functions across all these teams. We operate under yearly OKRs, which are executed through quarterly roadmaps. Here are the specific challenges we aim to solve with JPD:

1. Consolidate Requirements from All Stakeholders: Previously, requirements lived in silos, making it difficult to get a comprehensive view. JPD provides a cross-platform layer that consolidates these requirements, ensuring that all stakeholder inputs are gathered in one place.

2. Consolidate Ideation: Ideation used to happen in various siloed tools such as Google Sheets and different Jira instances across platforms. JPD helps in consolidating all this ideation into a single tool, streamlining the process and making it more efficient.

3. Unified Ideation and Prioritization: JPD allows us to bring ideation and prioritization together in the same tool, facilitating a smoother workflow from idea generation to prioritization.

4. Macro and Micro Roadmaps: Creating both Macro (Product Organization level) and Micro (Platform level) roadmaps to share with stakeholders is essential. JPD enables the development of these roadmaps, ensuring that all stakeholders have visibility into the product's progress and future plans.

5. End-to-End Linkage: Ensuring end-to-end linkage is crucial. JPD allows us to link Objectives -> Key Results (Jira OKR Board) -> Initiatives (JPD) -> Delivery (Jira) -> Impact (Jira & OKR Board), providing a seamless connection across all stages of product development.

The approach & what was delivered

To address these challenges, we implemented the following approach using JPD:

1. Training and Support: We conducted training sessions for all stakeholders to ensure they understand how to use JPD effectively. Ongoing support is provided to address any issues and ensure the tool is used to its full potential.

2. Centralized Repository for Requirements and Ideas: We set up JPD as the central repository for all requirements and ideas. It worked very well from a requirement gathering perspective and will also allow us to create a transparent & passive tool to create a consolidated backlog. Also, we’re not missing out on any ideas and have the ability to say no to ad-hoc requirements with much more confidence.

3. Streamlined Ideation Process: By utilizing JPD's features, we established a standardized ideation process that includes idea submission, discussion, and prioritization for all platforms, leading to unified direction of the product org rather than siloed platform development.

4. Development of Roadmaps: Using JPD, we created detailed roadmaps at both the Macro and Micro levels. These roadmaps are auto-updated as they are linked with Jira delivery epics / tasks.

5. Transparent Development: Now, the delivery of the roadmap for the whole product org can be tracked in one place for any stakeholder to view, providing transparency and aligning everyone on the progress. Reduced the “what’s happening in X initiative?” questions a lot.

How the product added value to those submitting requests, and to those receiving the requests

For those submitting requests, JPD provided a centralized platform where they could easily submit and track their ideas and requirements.

For those receiving requests, JPD offered a streamlined process for managing and prioritizing these inputs. The consolidated view and linkage to delivery tasks made it easier to picture everything on the same level.

Pros

1. Integration with Jira: JPD is an excellent tool if Jira is your primary workhorse, as it integrates seamlessly with other Jira products. This integration allows for smooth transitions between different stages of product development.

2. Customization: JPD is highly customizable in terms of fields and options. This flexibility allows us to tailor the tool to our specific needs and workflows.

3. Filtering, Sorting, and Views: JPD offers a fine assortment of filtering, sorting, and views. This makes it easier to project the exact view you want depending on the audience you are sharing it with.

Cons

1. All fields or nothing when creating an idea: JPD currently has the inability to allow you to choose specific fields to be mandatory and others as optional, when a stakeholder creates an idea. It’s either all are ‘required’ or everything is ‘optional’.

2. Merging Similar Requirements: Merging similar requirements is not an option in JPD. The two options we have are:

   1. To actually create a new one and then cross-linking them (crowds all views).

   2. Changing one while deleting the others, with a large scope of human error.

3. Splitting Multi-Team Requirements: JPD lacks nested views, which can make it difficult to manage multi-team requirements. This limitation can be a hurdle when trying to split and manage tasks across different teams, where we have to end up duplicating them and then linking them across the board. Very messy, especially in the Roadmap view where we have duplicated requirements floating around across teams with different timelines.

4. Not being able to restrict changes to a view: While we want most updates / changes to be tracked across all views within JPD, there are some that we would like to restrict to a specific view. Can’t be done yet, the only way out is to create isolated fields for different views.

5. Permissions: Permissions in JPD can be tricky and not being able to edit your own idea as a “Contributor” is a pet peeve of mine. While we want all stakeholders to be able to create and edit their own ideas and requirements without, this requires a paid license. This can be a significant cost factor, especially to include teams like support/marketing / legal who do not have a larger use for JPD outside of our product org.

SalesForce Custom Objects

Reviewed by: Damien Harr - Technical Program Manager at Twilio

The unique challenges to solve

Our Product team was lacking a single lens of solution gaps, product feature requests, or enhancement requests gathered from Pre-Sales, Post-Sales, and Support. This led to disparate guidance for Product Managers on where to find valuable information when producing their quarterly and annual roadmaps. And perhaps more importantly, cross-functional teams had reduced, or in some instances stopped, using the tools due to lack of visibility or action taken against them, completely cutting off a critical source of Voice of the Customer data.

The approach & what was delivered

To combat this, I set out by establishing goals for a new program, highlighting the challenges in front of us as an organization. The goals were:

• Identify, publish, and qualify customer product request data for Product Managers across all product pillars

• Product Managers can trust the data to be complete and accurate

• Product Managers can make informed decisions to support their Quarterly and Annual Product Roadmapping

• The Go-To-Market team and their Customers remain informed through notification feedback loops creating a clear and unambiguous communication channel

The tool we landed on was a custom object built into our Salesforce instance for Feature Request intake. The combination of flexibility and cost to implement made it the most attractive solution for our company, having already invested a lot in establishing a Salesforce ecosystem.

How the product added value to those submitting requests, and to those receiving the requests

The primary advantage to using a Salesforce custom object was to remove any complexity and barriers for our friends in Go-To-Market to submit and prioritize feature requests based on direct customer feedback. Account Reps, Solutions Architects, and Customer Service Managers spend much of their time in Salesforce tracking their customers’ health, opportunities, and contracts. “Meet them where they are” was a phrase I used early and often when mapping out the program.

The largest advantage to using Salesforce is the easy access and integration of the wealth of customer data already captured in Salesforce. The ability to seamlessly tie in Account ARR, upcoming contract renewal dates, churn risk, etc. help form a complete picture to the feature request that’s invaluable when considering what Product needs to focus on next.

This approach can also lead to an influx of new requests, so it’s just as important that the follow up by Product is seen as swift and comprehensive. Customer feature requests that are never reviewed and never prioritized do nobody any good, so developing a cadence for review and response, along with a comprehensive scoring and prioritization framework, was critical to the success of our product feature request program.

Pros

• Custom designed interface means you can tailor the intake data to capture exactly what you need for your organization.

• The ability to directly tie the request to important customer data, such as ARR, Customer Health Score/NPS, contract renewal dates, etc. provides powerful metrics with very little effort.

• Easy access in a familiar tool for the people working with customers and capturing requirements every day (meet them where they are). CSMs, AEs, Sales Engineers are all working in Salesforce already.

• Native reports and dashboards are relatively straightforward to create. And it’s relatively simple to bring the data into Tableau/Looker/Power BI/etc. to run more robust analytics.

• With a wide variety of Salesforce plug-ins, you can extend the functionality in a number of ways (e.g. we published automated biweekly emails digests to the Product org with the latest submissions for PMs to easily review using a plug-in). There’s a Jira plug-in to allow users to look up existing feature request tickets.

• Salesforce workflows allow for dynamic intake based on product area/team as well as prioritization.

Cons

• Requires a company-wide adoption of Salesforce.

• Additional licensing costs for Product users.

• Custom objects require internal support to build/maintain/revise functionality.

• Longer lead-time to implement, depending on level of in-house Salesforce developer knowledge.

• Upgrades to Salesforce may break custom objects/integrations.

UserVoice

Reviewed by: Jana Debusk - Senior Manager Product Operations at Playvox

Note from Jana: Although I wasn't involved in the initial implementation of UserVoice, I worked extensively with it when I joined the Product Operations team and now own the tool.

The unique challenges to solve:

Working in a start-up environment, we needed a solution that was simple and straightforward for both our customers and our team. We didn’t have unlimited resources and needed a way for our customers to quickly and easily submit their feedback and ideas directly to the product team (without hopping on a million discovery calls). UserVoice was centralized and efficient. It allowed us to simply get the job done which is exactly what we needed at the time.

The approach & what was delivered:

Though it would be most widely used by our Product and CS team, we decided to roll out UserVoice more broadly to our entire team. We provided enablement internally, and a Help Centre article detailed the what, why, and how for our customers. Due to customer preference, we made the Idea Portal accessible by invitation only which allowed a centralized way for POCs to submit and vote on the most crucial ideas for their business cases. Our team can also contribute ideas on behalf of our customers using the Contributor Portal. Once an idea is submitted, other customers can vote on it, and our product team reviews it. They then label it with one of the following status tabs:

• Acknowledged - A Product Manager has read the idea and is waiting for more votes from other customers.

• Under Review - A Product Manager is investigating the idea in detail and determining if we should move forward with development.

• Prioritized - The Product Manager has determined that the idea should be developed. The idea is now in line for development.

• Planned - The idea has been slated for development.

• Started - The product team is actively working on the development.

• Completed - Development is complete and the item is released in production.

• Deferred - A Product Manager has determined that we will not develop the idea at this time.

There will be comments from the Product Manager explaining the decision. Most recently, we’ve connected the UserVoice idea portal to their roadmapping tool which not only allows customer ideas to be directly linked in feature cards, but it also builds trust with our broader team.

How the product added value to those submitting requests, and to those receiving the requests:

Because of its simplicity, it was adopted quickly by our customers and team members which means more engagement all around; more ideas got submitted, every idea got looked at, and our product team was able to gather feedback, analyse, and prioritize more effectively. It also enabled our Product managers to streamline customer communication by sharing personalized updates to everyone who voted on an idea.

Furthermore, this tool became a great talking point in customer meetings. We like to celebrate how many ideas they’ve submitted as well as how many we’ve been able to build. We can quickly glance at our customers’ most critical needs by prioritization they chose: Not at all important, Important, or Critical. I’d say customer engagement and transparency have been the biggest wins with this tool.

Pros

• Intuitive process for gathering and utilizing feedback

• Economical

• Easy to add branding (logo, colours, subdomains)

• Constant enhancements in the product

• Idea portal connects to roadmap and integrates with Jira so there’s a great holistic view of the idea from start to finish.

Cons

• Reporting is lacking depth and not easy to use (at least in the basic package)

• Lack of integrations

• Lag issues

• While the idea portal seems to fit our needs for the most part, the connected roadmap has a lot of feature gaps. It’s hard to optimize the

LaunchNotes

Reviewed by: Chelsea Grint - Product Communications Specialist at BuilderTrend

The unique challenges to solve

• A customizable Kanban style board, for easy digestion of what releases are in progress, in early adoption or recently released.

• Roadmap cards that could include different font sizes, images or videos and links.

• Separate roadmaps for our internal and external stakeholders, and ways to communicate what’s new.

• The ability to gather feedback on specific roadmap cards, especially for releases in early stages of development. In 2022 we moved from Waterfall to Agile – feedback on current projects is instrumental for quick iterations as we release small slices.

The approach & what was delivered (Also includes value to different audiences)

Our internal product roadmap is for an all-company audience. Each roadmap card provides a summary of what’s changing in the program, the customer value, the company value (including what quarterly initiatives and yearly goals the release is tied to), and links to additional internal resources if people want to dive deeper.

As the Product Operations Communications Specialist I work directly with Product Managers to ensure I have the release information I need to publish the roadmap cards. I use LaunchNotes’ Announcements for a weekly Wednesday recap of roadmap card movement, and we have an all-company Product monthly newsletter where I provide links to the roadmap or specific roadmap cards.

This has been valuable for our Customer Success, Sales and Marketing teams along with Corporate Communications and leaders in departments outside Product. Everyone can stay up to date, vising one main source of truth for what’s coming in the next quarter.

---

Our public product roadmap is for our customers, written for that specific audience, in our brand voice. We simply provide what’s changing in the program, how it will be valuable to them, and ways they can provide feedback or learn more.

After I have the internal roadmap card approved by the Product Manager I write a customer-facing roadmap card and submit it to Marketing for copy edit and approval. I use LaunchNotes’ Announcements for a weekly Friday recap of roadmap card movement. Marketing uses public roadmap card links in their monthly customer newsletter or on in-program Intercom messaging.

We have a little over 5,100 subscribers. We see an average of 100 new subscribers each month and we have an average ~55-60% open rate of weekly roadmap recap emails. This has been valuable for our clients who want to provide feedback and want to know every single change that may affect their workflows.

Our Customer Success team directs traffic to the roadmap. Be it email, e-chat or phone, if a customer has feedback or a suggestion they are encouraged to leave it on our roadmap.

---

We found that a weekly update works best for our communication style, because stakeholders know it’s coming on a certain day and time, and they aren’t inundated with multiple messages when we have multiple changes in the same week. LaunchNotes recently provided the option for people to opt into real-time movement alerts, but we aren’t using that right now.  

I’ll be candid, communicating releases while working in Agile has been a challenge. We’re often delivering small updates that are foundational to a larger experience / initiative, and it’s difficult to communicate to external stakeholders that you have a grander plan in place but the “how” of the experience isn’t fully flushed out. We use a combination of having a “parent” roadmap card with multiple associated releases and we have a roadmap card dedicated to small QOL monthly updates.

Pros

• LaunchNotes has great out of the box features and design so you can set up branded roadmaps without the need of a Developer or any code knowledge. With that, they also allow you to customize with HTML and CSS if you want. We did have one of our Devs change a few things on our roadmap layout, for some specific branding and page design desires. It was very easy for them to do, no more than 2 hours of work.

• I love Announcements in LaunchNotes. I have templates created so my header images and sections are consistent, and I love how easy it is to connect release cards and categories. I also like the preview and that I can schedule for a later send.

• LaunchNotes gives us the ability to get feedback on specific releases, and it captures the customer’s name and email so our Product crews can reach out to those customers, if they want. At a basic level, this is great.

Cons

• Would love an easier way for our internal Customer Success teams to get feedback from customers into LaunchNotes. A lot of competitors have Chrome connections where our associates can highlight an email or feedback from Intercom, click the Chrome extension and it will populate the customer’s information from Salesforce.

• In this same vein, we would love to have “forms” so all feedback, coming directly from our customers or our associates, has the same vetting information. We often get feedback or suggestions on what people want, but not the WHY behind it. People also put multiple ideas into one message, making it difficult for us to splice and assign to the right Product areas or respond to those people when we’ve solved their issue.

• We get roughly 800 pieces of feedback a month. LaunchNotes isn’t the right repository for organizing and categorizing each piece into idea areas – even with their “Ideas” section, they can’t manage feedback at large scale.

• The current way to close the outer feedback loop is using Announcements and tagging an associated roadmap card or category, so subscribers will be notified. You can send emails to individuals who provided feedback, but I’m not a fan of the user experience and some of the limitations.

• Other competitors will integrate with Salesforce to show us a dashboard or reports for high volume feedback, including ARR and segmentation breakdowns. LaunchNotes has only a basic Salesforce integration.

Version Lens

Reviewed by: Feras Wilson - CTO at Pedal Mates

The unique challenges to solve 

Before Version Lens we would end up spending a lot of time on refinement and coordination across our teams. Having the whole team aligned on our roadmap and product decisions is always a challenge.

And when it comes to receiving feature requests from our stakeholders, it's not certain that everyone knows what a good ticket should include, sometimes not even ourselves. As an example, instead of focusing on specific feature requests, my priority lies in understanding the underlying pain points.

The approach & what was delivered 

Version Lens is a product intelligence platform. A co-pilot for product managers focused around automations and intelligent workflows for stakeholder communication, documenting product decisions and managing internal stakeholder requests and feedback.

In practice what this means is that Version Lens connects Slack with our task management system to make sure stakeholders are proactively kept in the loop with all their feedback collected and triaged automatically. Helping make sure our backlog is up-to-date and closing the feedback loop with stakeholders.

How the product added value to those submitting requests, and to those receiving the requests 

Version Lens has made this process seamless, gathering context for us, and ensuring that all tickets we get are actionable as soon as they enter Jira.

This efficiency has significantly reduced the need for time-consuming weekly follow-ups and ad-hoc meetings, saving both myself and the team countless hours.

Pros

• Built natively in Slack to make communication easier

• Asks investigative questions autonomously for requests and bug reports

• Built to be easily implemented for teams using their backlog as source of truth today for planning

• Due to focus on SMB, pricing is significantly cheaper

Cons

• Most focus is on Slack + Meetings so fewer integrations to e.g. CRM system

• Newer to the market, only allows certain customers to use full platform

• Early-stage company, so not everything is there yet and you have to be open to growing with the platform

ProdCamp

Reviewed by: Mike Walters - Co-founder of Action1

The unique challenges to solve 

After a successful exit with our previous venture, we were looking to get product management right from the start. Our complex technical products generated an vast amount of feedback from knowledgeable users and clients. Tracking this feedback in Excel and discerning trends to inform our product roadmap became increasingly difficult and a waste of time.

The approach & what was delivered 

I started looking for ways to automate this process, realizing that refining my spreadsheet wasn't the right approach. That's when I found ProdCamp. I was immediately able to understand and implement its core basics, which allowed us to centralize feedback quickly using a public roadmap and email forwarding features.

ProdCamp revolutionized our approach, giving us the ability to track which users requested specific features and attach potential dollar values to each request based on the interested accounts' revenue. 

This insight proved invaluable for prioritizing our development efforts.

How the product added value to those submitting requests, and to those receiving the requests 

The impact on both our users and our business has been remarkable. We reignited so many deals that we lost before. Our customers are still surprised when they actually get an email saying, 'Oh yeah, you asked about something, you placed your upvote on that. And here you go. We released it yesterday.' They just get blown away by that.

For Action 1, ProdCamp has transformed our decision-making process. Now we know exactly what features we need to build in order to influence entire chunks of revenue. When we have a prioritization meeting, it's clear why we're working on this set of features instead of any other, and we're spending more energy exploring the 'how' instead of the 'what'.

The results speak for themselves. ProdCamp has helped us reignite dozens of deals, including one worth $40,000 in annual recurring revenue.

Pros 

• When looking for solutions, I found that some tools were overkill or relied on homegrown solutions. What set ProdCamp apart was that it was out-of-the-box and just works. This simplicity, combined with its effectiveness, is a major pro. 

• Another pros of using ProdCamp is its responsive and thoughtful team that drinks their own champagne. I appreciate that I can use ProdCamp's public roadmap to upvote features or submit requests, getting notified when requested features become available.

• And for us, the ability to easily associate user emails with specific features and assign dollar weights to features are two critical aspects that differentiate ProdCamp from other solutions I've tried.

Cons 

• As for cons, while ProdCamp has many valuable features, the user interface could be more intuitive. I'd recommend scheduling a quick demo with the ProdCamp team to ensure you get the most out of the platform. 

• And while the ability to attach revenue potential to features is powerful, it's important to note that this requires accurate input and data hygiene from the user's side to be truly effective. Companies need to be diligent in keeping this information up-to-date for the best results.

ProductBoard

Reviewed by: Christopher Fox - Director of Product Operations at Dashline

Unique challenges to solve

When we set out to adopt Productboard, we wanted to solve for:

1. Disparate sources of truth across many tools

2. Disorganized and neglected feedback channels

3. Consistent approaches to prioritization

The approach & what was delivered 

At Dashlane, we onboarded Productboard similarly to how Productboard recommends:

1. Setup

2. Migration

3. Maker Enablement & Training

4. Contributor Enablement & Training

During Setup, we configured our integrations to Zendesk, Salesforce, Gong, Satismeter, and other solutions we had already set up to work with our existing solution at Dashlane. This process involved collaboration with the owners of those tools across the organization and gave us the opportunity to start fresh with new requirements.

During Migration, I used bulk import and export options to help the process along. It wasn’t as easy as clicking a button, but it was relatively straightforward to export from the existing solution and use some spreadsheet magic to get it into a format that Productboard accepted. I used this bulk export and import option for both feedback notes and the backlog and in-flight “features” from our existing teams. It was important to rebuild a basic hierarchy that our teams could approach based on the existing solution they were used to.

On the enablement and training side, we identified champions first and worked closely with them to figure out what the biggest pain points of the transition would be. Using their insights, we were able to curate training for our organization that included predicted FAQs based on our specific context. Productboard was a massive help in training documentation and running sessions for us. Prior to the transition, we made sure to implement a rough prioritization framework for teams to follow (modified RICE in our case, with custom drivers) that fit with the old solution and Productboard to make things a bit easier.

When it came to the rest of the organization, the formula was relatively the same: identify champions from each department, go deep with them on how Productboard can help them, then scale out relevant training for those departments. For example, we met closely with customer success managers to teach them about the Customers board, the Portal, and how they can submit and follow up on feedback.

Having now been at the forefront of 3 Productboard onboardings, I have a few lessons learned that from our approach:

• It’s important to identify champions across departments to help adoption along. This helps you push back against the “oh, great, another tool” narrative and identify the key value propositions for the new tool.

• Keeping things simple by not trying to revamp everything in one go minimizes disruption to teams. A basic “mirroring of the status quo” approach to migration can help get things up and running faster.

• The key subversive goal for a Product Operations professional in this area is to make sure the platform is as valuable as possible, as early as possible. This means getting feedback funnelled in quickly so that teams can action on that. A blank slate can be quite daunting to a team, so any pre-population is highly recommended.

• Don’t be afraid of opening up a feedback channel directly to your customers! Many times, teams or leaders are wary of doing this (especially in the B2B space) because of volume or exposing strategy to competitors. While these are certainly risks, they can be easily mitigated by employing good management and auditing of the feedback intake process and auditing the portal on a regular basis.

How the product added value to those submitting requests, and to those receiving the requests

Especially for larger customers who want deeper visibility into what we’re working on, the Productboard Portal has proved quite useful. We have noticed a pretty consistent flow of feedback coming from our B2C and B2B customers, which we can attribute to our broad dissemination of the portal link: we posted on Reddit, included the link in our help centre, included it in our customer-facing folks’ email signatures, and operationalized through our support team and chat bot to let folks know they can submit feedback any time. We also added a generalized feedback email to receive any email (oh, and we set up some spam and malicious email filtering).

This success did translate into a few considerations for the product teams receiving the request: we started to get some noise. Product Operations then build automations to identify that noise, then tagged it accordingly to measure it over time. We even identified new trends around feedback for our support process itself, which was helpful and interesting!

But we didn’t stop with active feedback - we also included those “passive” channels as well. Importing closed Salesforce opportunities really helped us quantify deal loss and attribute to “features” in our backlog. Without this visibility and automation, we’d be stuck in the classic loop of spreadsheet prioritization that’s inspired by “anecdata” or an exhausting Salesforce report.

As for the feedback itself, because of the volume, our automations, the nice AI summarization features in Productboard, and some operational curation from our Product Ops team, we’ve increased the confidence in our prioritization by quite a lot. We can now pinpoint the highest trending features based on a few areas: current customer ARR, overall volume, weighted importance, and lost ARR.

Pros

• Relatively easy to get started with integrations, import features, and SSO/SCIM

• It’s (usually) quite snappy, even with lots of data

• Once you get the hang of the UX, you can really fly around the platform (three cheers for keyboard shortcuts!)

• Email notifications are actually useful!

• The flexibility to create as many views and roadmaps as you want is quite a blessing (as long as you consistently audit for those “Untitled” views that get created!)

• Reporting, reporting, reporting. Ahhh, so much great data in this platform! There are more advanced features I wish were present, but understanding general throughput, age of features, and efficiency is critical running a great Product organization

Cons

• Filtering and swimlane options are sometimes limited, depending on if you’re in a roadmap, a feature board, or an insights board

• Some UX takes a while to get used to. For example, you won’t find a save button in any text fields, but you better not forget to save the board filters!

• Permissions were sometimes a little wonky to get set up when we were starting out. By default, views were private, so folks would create something, send a link, and others couldn’t access this. Productboard has since set the default for most views to be open, but we haven’t stopped considering permissions every time we create something

• It’s a hard sell to executives. This is true of any tool, but when they saw their first Productboard roadmap, they immediately wanted some slides. My advice to folks is to ease into it - don’t create the perfect roadmap on day one. Start with enabling folks through training and Q&A, even your executives!

• The API can sometimes be limited if you’re trying to do some advanced things. It’s relatively new, and still useful for most cases, but doesn’t cover all the bases. For example, you won’t be able to query any feature attributed to a particular customer easily.

ClickUp

Reviewed by: Graham Reed (i.e. Me!) - THAT Product Operations Guy

The unique challenges to solve (at a now former business)

The business had two major issues: A lack of communication and transparency within the business on product strategy and development, and no decent analysis and prioritisation process for new features and initiatives. The teams used different Jira projects in different ways simply as a task tracking facility, and updating the business on what was being developed and why was non-existent. Roadmaps were difficult to find and interpret. Decision making was not transparent (often by the HIPPO) and took little notice of internal or external feedback. Feedback that was provided by the business came in all sorts of methods (Teams, Email, Jira, carrier pigeon) and with varying degrees of detail and usefulness.

The approach & what was delivered

It is no secret that I have been a fan of ClickUp for many years (I wrote an article a few years ago that ClickUp CEO Seb Evans framed and had a picture taken with!), because of its excellent flexibility to allow me to add the fields I wanted to add, including formula fields, to have multiple view for different stakeholders, and to easily create forms that anyone can fill in without needing lots of expensive licences.

With this in mind, I was able to provide a form asking the exact questions I wanted to ask, which then provided tickets in ClickUp with that information - which then can begin its flow through idea to review to prioritisation to roadmap* to development to delivery - all from the same ticket.

The questions asked teased out the information I needed from the correct source of truth - the end users or internal staff by-proxy. My teams had all the information, quantitative and qualitative, to help them make decisions.

The views allowed me to tell the right story with the right level of information for the right audience, with minimal additional effort each time.

How the product added value to those submitting requests, and to those receiving the requests

ClickUp gave me the flexibility to ask the right questions and constrain the possible answers where needed, on a simple form branded up and available to anyone without worrying about licences and additional cost. This allowed the rollout to be very easy and smooth, and quick. I had exactly what I needed to get the data in.

From there, the information followed the initiative right through to development, via reviews, internal assessment and prioritisation. The same tickets were also made part of the weekly project reports for senior leadership, available in the ‘report’ by virtue of clever tagging, filtering and custom fields.

These same items also appeared, where appropriate, as assets on the roadmap, and said roadmap was multi-layered again by virtue of tagging, filtering and different Views, each of which could be independently shared (again without additional licences) with the wider business.

Overall, the right mix of transparency and expectation setting with information coming in and out, as well as customised, bespoke logistics of the information itself for the product teams.

Pros

Keeping this to my personal favourites:

• The ability to share lists, boards, forms (costs extra) with external audiences without extra licences (view only), with a GUID, has been game-changing for years now. Forms mean you can accept new ideas and feature requests from ANYONE.

• Automations are very cool, easy to implement, and work on just about every field, hardcoded and custom (Jira is a bugger for their limited use of such automations). Automations are metered though so big orgs be careful

• Tonnes of customisations, fields, views. Having a different view, which is a custom filter, fields showing, sort, etc for different audiences makes multi-layered roadmaps a doddle.

• Multi-homed tasks - a task can live and be viewed in different lists projects and spaces - a massive time-saver and great for collaborative working (again, looking at you Jira!)

• Although I don’t use these much, it does have Whiteboards (who doesn’t these days, sorry Miro!), collaborative document area like Notion and Confluence (I don’t think this is as good as these two right now).

Cons

• A common complaint, and I kinda agree for those not deeply into experimenting and finding innovative solutions, is that ClickUp is a bit too flexible - you really can do whatever you want with it, but if you want ‘Product Out of a Box’ you will find it a little difficult to get started.

• Watch the pricing tiers, some of the clever things you want to do come at a cost.

• The UI is over-stacked with tools now, menu bar after menu bar.

Do you have feedback on any of the mentioned platforms, good or bad? Mention in the comments below.

Have another platform you would like to see on this list? Get in touch for a possible part 2!

Thank you to all authors for your contributions.

Graham

Share Product Ops Confidential

Co-written with the brilliant Jake Brereton, co-founder at LaunchNotes, we deep-dive into product communication practises, strategies to drive tighter internal alignment and demonstrate how great communication workflows are the foundation to everything Product Ops delivers.

This has been in the works for sometime across 2024, and it is no secret I focus on outstanding communications more than anything within Product Operations. So to finally be publishing this passion project & all the resources inside (which includes a comprehensive Product Ops Self-Assessment & Report I've built) is simply amazing.

This is aimed at both Product Ops professionals, and product leaders wondering how to get started with Product Operations.

TOTALLY 100% FREE for anyone

Download now from:

The Product Ops Playbook

Graham

Share Product Ops Confidential

What is in the report

• The essential attributes defining a successful product ops manager in 2023.

• The diverse applications of product ops in the realm of business.

• Insights from industry experts regarding the evolving landscape of product ops, year by year.

• Core objectives essential for excelling in product ops.

• A comprehensive overview of the metrics used to gauge the wins of product ops.

Some findings

• 91% of those surveyed have a product ops function in their organisation.

• The most important principle of product ops was voted to be enabling product teams, coming in at 33% of all the choices.

• Of all the roles in product ops, analysing data to inform product decisions was voted the most important at 24%.

The Authors

• Graham Reed & Antonia Landi

• Lindsey Bell

• Hugo Froes

• Camila Gargantini

• Gabby Peralta

• Shintaro Matsui

• Chris Compston

• Jessica Burgamy

Download the report for free (Sorry, you do have to provide your email etc!):

The State of Product Ops 20231

This is a list of interview questions & scenarios for Product Operations roles.

Some of them have been taken from real interviews both myself and others in the Product Ops community have been given, others are possible ones to be used.

This list is for both hiring managers (& recruiters) to use and adapt, and applicants looking to prepare for interviews.

The list has been contributed to by several Product Ops professionals:

Gabby Peralta

If you have any questions or case study examples you would like to add to this list, please get in touch!

Currently: 18 standard questions, 16 scenarios-type questions, 1 case study.

Questions

1. What does Product Operations mean to you?

2. How do you approach improving a way of working?

3. How do you investigate what needs improving in the product team/business, and what do you focus on first?

4. How do you measure the success of an improvement you make?

5. How do you measure the success of Product Operations?

6. How do you approach improving a way of working with a colleague who is resistant to change?

7. How do you communicate a new process to different parts of the business?

8. How do you use data/metrics in your role?

9. How do you support the use of data/metrics in product teams?

10. How do you enable internal knowledge sharing and documentation?

11. Describe Product Operations’ role in the Product Development Lifecycle (PDLC).

12. Describe Product Operations’ role in the rollout of a new feature or product.

13. Describe Product Operations’ role in user feedback/customer discovery.

14. What process are you most proud of improving?

15. How have you been successful in managing projects crossfunctional projects?

16. How do you prioritize work?

17. Tell me about your management style.

18. What scrum metrics do you track?

Scenarios

1. Talk to me about your first (30) (60) (90) days in starting Product Operations here.

2. Talk to me about your experience supporting and maintaining OKRs/KPIs for product teams.

3. Talk to me about your experience supporting and maintaining quarterly and/or annual planning cycles for product teams.

4. Talk to me about your experience of supporting and maintaining product documentation.

5. Talk to me about your experience of supporting customer feedback/discovery/feedback loops.

6. Talk to me about your experience working with & supporting GTM teams/marketing teams/product marketing teams.

7. Describe a time when you implemented a change in process and it didn’t work out. What mitigations did you make leading up to rollout and actions you took after?

8. Describe a time when you worked with a colleague who was resistant to the changes you were making. How did you approach the situation and what was the outcome?

9. Tell me about a time when you’ve had to do something you didn’t want to do.

10. Tell me about a time you’ve reduced complexity.

11. Tell me about your management style.

12. Tell me about a time you received hard feedback or feedback you didn’t agree with.

13. Tell me about a time you’ve worked yourself out of a process.

14. Tell me about a specific example that required more process or a different process.

15. Tell me about a time you ran into a problem with data. What did you do.

16. Tell me about a time when you’ve had to make a decision that others disagree with.

Case Studies

• You’ve just joined the Product Team and see that each Product Manager has multiple streams of customer research going on (qual, quant, customer interviews, data analysis, NPS, etc.). There is a lot of inefficiency and overlap in these efforts, and learnings aren't being effectively shared so everyone can benefit from these insights.

  • How would you operationalize and optimize this experience for product managers to be more effective and deliver more value?

  • Describe your approach and identify goals you would use to measure the effectiveness of your plan.

Share Product Ops Confidential

This career path matrix for Product Operations professionals has been designed to capture the qualities sought and the high level responsibilities across the different levels of both IC and Manager tracks. This covers from Associate level through to Staff Product Ops Manager, and through to VP of Product OPs.

Anyone may freely use and adapt this without permission or attribution (but please do not pass it off as original content at any time)

Download the spreadsheet here:

Product Operations Career Path Matrix - Udit Chhibar & Graham Reed

Share Product Ops Confidential

Full details and book in with Chris at ndxcc.com

Empowering teams to build a continuous improvement mindset is the most effective way to create sustainable and scaleable change across your organisation.

Incentivising them to focus on areas of improvement and allowing them time and space to experiment, will ensure they’re effective at bringing customer value and business benefit.

I’ve never come across a team that didn’t want to improve how they were working together. However, how many of those ‘ways of working’ meetings do we see driving any real change?

If you’re building high-performing teams then the Lean Capability Canvas is a powerful tool at all levels of the product organisation.

How do we define a high-performing team? This is a question that product leadership should be asking, aligning on and communicating to their teams. For me that looks something like this — “We consistently get things to customers that they value enough to pay for.”

Product leadership needs to incentivise teams to maximise their performance and impact, enabling strong product thinking and continuous improvement mindsets.

The Lean Capability Canvas aims to very quickly move the team into a position where they can take those theoretical “We want to improve!” conversations into the practical actions required for change.

Whether you’re part of the cross-functional product leadership that leads multiple teams, a member of a product team looking to improve working practices, or a Product Ops practitioner accountable in enabling teams to become more effective — the Lean Capability Canvas will be an invaluable tool that provides the structure for real actionable change.

Sustainable change can only be achieved via ground up co-creation. Without a self-driven continuous improvement mindset, or the tools that allow for it to grow, product organisations will be unable to drive feasible change within teams. Equally critical is the ability to replicate that success across the wider organisation for a sustainable competitive advantage.

While frameworks themselves do not solve problems, the value that is driven from the time carved out to have strong discourse about team challenges and where to go next, is where they excel.

This article and content has been reproduced with permission of Chris Compston.

Share Product Ops Confidential

This template is designed to be used by hiring managers and recruiters, used as a base template to modify and customise, containing responsibilities that align with the Product Operations Pillars. Anyone may freely use and adapt this without permission or attribution (but please do not pass it off as original content outside of the hiring process)

The Role:

Product Operations is a multifaceted role that focuses on optimising the end-to-end lifecycle of our product, driving cross-functional collaboration, and enabling product teams to focus on what they do best: build great products. It is a role that is a mixture of strategic and tactical outcomes.

You will:

Align: work closely with the product leadership to help their teams communicate effectively with the wider business, and each other, as well as business leaders throughout the business to ensure their interaction with the product function is as efficient and valuable as it can possibly be. 

Enable: Provide the means for product teams to complete routine and strategic tasks themselves, as efficiently as possible (but not taking on their tasks for them).

Improve: Work continuously and iteratively to improve how teams work by removing barriers and bottlenecks, reducing time spent on processes or tasks, and providing everything teams need to do the best job they can.

What you will be doing:

Strategic Support: Assist and enable the Product Management teams, squads and tribes in the production and maintenance of product strategy, by ensuring effective, reliable communication, providing necessary resources & tools, and facilitating cross-functional collaboration to build, publish and execute the plan.

Business Alignment: Be focused on both supporting the product function, and by extension the technology function within the business, as well as supporting and enabling the entire business with what they need from the product teams to sell, support and market the product. Support the business but through a Product lens and product focus.

Data-informed Decision-making: Leverage and provide data and analysis to inform decisions, identify trends, and uncover insights that drive continuous improvement and help guide the overall product strategy. Facilitate the establishment of key performance indicators (KPIs) and ensure these metrics are tracked and reported consistently across teams.

Valued Communication: Ensure that Product communicates clearly, efficiently and regularly with internal stakeholders with information and updates that have value and they can easily consume and reuse in their own roles. Provide guidance on delivering value to the right audience at the right time with the right level of information, and formalise feedback routes for suggestions, ideas and opportunities supporting efficient, focused inbound communications

Iterative Improvement: Ensure existing product operating processes, frameworks and methodologies are needed, add value or require iterative improvement, focusing on processes for data, communications, collaboration specific to our business. Implement a good change management mindset in rolling out iterations of all changes across your close teams and all teams in the business.

Cross-functional Collaboration: Foster open communication and facilitate alignment between various groups, such as product management, engineering, design, and marketing, ensuring everyone works towards common goals. Use project management methodologies to drive outcomes through process changes or tooling, defining scope, milestones, timelines and risks to execute on the work being done by you and the teams. Promote a positive working environment by creating empathy with people beyond the boundaries of their working group, being an ambassador of the company values.

What are we ideally looking for from you:

Product Operations is a strategic support role for the whole business, that is as much about coordinating people as it is technology and processes. Therefore, the role supports a vast array of experiences and enables a wide diversity of backgrounds and careers, each bringing their own skills to the position. 

Predominantly, product management careers have a large crossover of skills and experience. However, those from a project management, product marketing, business analysis, people management/HR or Quality Assurance background could also contribute well. 

Specifically we are looking for the following, but we know this is a wish-list, so if you do not have everything on the list, you should still enquire
 

• An understanding of the full software development lifecycle (SDLC), including discovery, feedback, analysis & data analytics and release processes. 

• Works iteratively and pragmatically - Rome is not built in a day, so do not try to change the way colleagues operate in the first week!

• A logical and analytical mindset understanding what can be changed, what value change can bring, and comfortable using data to back up proposals.

• As well, an empathetic attitude to truly understand the problems you are trying to support and solve with your colleagues.

• Being comfortable with ambiguity, resilient to change, having the ability to adapt, and happy to be challenged, and challenge others.

• Experience managing task management & roadmapping solutions - e.g. Jira, Asana, ClickUp, Productboard Aha!, Prodpad.

• Ability to understand, refactor and implement large knowledge bases, using the most suitable information architecture and documentation solution at hand - e.g. Confluence, Notion, etc

• Ability to grasp product data and analytics to drive better decision-making, forming relevant insights from data using the most suitable product analytics solutions - e.g. Pendo, HotJar, Google Analytics

• Proficient in crafting precise and visually appealing data visualisation dashboards, empowering the audience by enabling data manipulation and interaction, business intelligence tools - e.g. Looker (Google Data Studio), PowerBI, Tableau, etc

• Experience administering, facilitating, driving adoption and managing software tools in general 

• Experience and confidence in facilitating, as well as presenting at, meetings and presentations with large audiences (whole company).

• Experience and confidence in working with all levels of the business - from c-suite to individual contributor (IC) level. Not afraid to make suggestions, to argue your point, or roll out net-positive changes that might not please everyone, every time. 

Share Product Ops Confidential