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. 

Surveying 

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

Goal

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

What you could do

Interviewing

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. 

Observing 

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. 

Documenting 

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 

Summary

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 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.

7 steps of Product Discovery

Before building a product - how do you know what product to build? While building a product - how do you know what features are the most valuable? After you've built a product - how do you know if to tune stuff or add a new one?

3 ways to prioritize a Product Discovery backlog

Discovering the right product is a vital part of a product development process. To do that effectively best product teams use a Product Discovery process. This process foresees you having a Discovery Backlog with a list of ideas, concepts, and hypothesis in need of validation. But how to decide what ideas to validate first ?