Skip to main content

Product ops process - surveying


Product operations, or product ops, is an emerging field of product management focused on empowering and increasing the effectiveness of product organisations. As with any establishing functions, the product ops process is not yet decisively defined. Every org does product ops differently at the moment. 

Here I've tried to suggest a high-level product ops process that you can take and adjust to your needs. The process is 3-staged: surveying, experimentation, and optimisation. In this article, we will talk about stage one in more detail. 


At this stage, you mostly need to talk to people, observe their behaviour and document your findings. 


Understand how product teams work, their goals and the tools they use to achieve them. 

What you could do


Talk to the PMs in your org, formally or not. Ask about their background, aspirations, what they are working on right now and what complaints they have. Document the findings. Don't try to fix something immediately, just aim to understand. 

Talk to other key players on your product teams. First and foremost designers and engineers. But also, product marketers, customer success and support folks, finances and managers. You want to understand how the product team works really, who makes key decisions, who sets the goals and who assign budgets. 


At the surveying stage of a product ops process, you'll need to join as many meetings as you can to observe and make notes. You'd want to create a map of all regular meetings, their goals, agendas, dynamics and results. Avoid talking in those, just listen and watch how interactions unfold. 
Book yourself into at least several product discovery sessions with your PMs. Here you want to understand if all PMs equally talk to customers, do they use similar techniques, how they write notes afterwards and how they turn findings into customer insights. You need to document the product discovery process across the board. 

Inject yourself into the planning phase for any new initiatives. Again, do not contribute, just listen and watch how your colleagues prioritise, plan and decide on activities they will commit to. Pay special attention to how data is used in this process - who brings it, in what form, does it get questioned, and is there a way to get to the source numbers? 

Dig into the tools people use. Make note of how they set up those tools and use them. Are all the teams use the same set of tools? Is the way of using the tools consistent? How much does your organisation pay for these tools? (not only in money but also time and effort spent on maintaining and tunning). Also, ask your product teams if there are any tools they need to do their work better? Capture not only the tool name but also the need it should satisfy and how this could be measured. 


To reach your main goal of the surveying stage of the product ops process - you need to document your findings. Feel free to pick the form that works for you. Some outputs that could be useful: 
  • A catalogue of interview notes with a reference and major trends identified 
  • A list of tools your teams use + their costs and usage patterns 
  • A description of the tools your teams want to have + why + how would we know those are bringing benefits
  • A product discovery process map + key personnel + regularity 
  • A mindmap of all data sources your teams use + data views + retention and access 
  • A competence matrix for your PMs + their career aspirations + professional development plan
  • The decision backlog + who made them + the outcomes 


You know you've successfully completed the surveying phase when you have a full and detailed understanding of how your organisation find market problems, turn them into opportunities, build those opportunities, market products and grow them. You should know the key people involved in this process, the techniques and tools they use and their goals. 

Worth noting that you can run the surveying process for smaller problems rather than the whole product development process. The activities and outputs remain but the scope of the problem might vary according to your needs. 

Also worth documenting the findings from the surveying stage in a format that is easy to change. Practices and tools might alter quickly within an organisation so you'd want to keep your understanding up to date so as your documentation. 

Only knowing how things are you can start thinking about tinkering with them and making them better. That's the next stage of the product ops process - experimentation

Popular posts from this blog

Product management and operations tools - Jira Product Discovery review

  JPD is a new player in the market of product management software. Jira (and the whole Atlassian suite) has been one of the most popular tool stacks for teams to deliver software products. Now they're adding a missing piece - product discovery.

Product Vision: an elevator pitch for your product

On this blog, I write a lot about making data-driven decisions . But what if you just starting to think about your product? You have a vague idea and nothing more. No point to go for prototyping or even talking to customers as you don't know yet who to talk to and what to talk about. In such situation - start from creating a product vision.

2 simple but powerful filters for your problem and product ideas

Nowadays lots of people and companies want to innovate. They want to generate new ideas and turn them into profitable products. But how would you separate good ideas from not so good ones? How would you make sure you invest only in good ideas?