Product Management

Purpose

Product management involves defining the product vision, strategy, and roadmap. It ensures the product meets market needs and aligns with the company's overall goals.

Key Processes

• Market Research and Analysis: Gathering insights about customer needs, market trends, and competitive landscape.
• Product Roadmap Planning: Defining the product's direction, key features, and timeline for development.
• Requirements Gathering and Prioritization: Working with stakeholders (customers, sales, marketing, engineering) to gather and prioritize product requirements.
• Backlog Management: Maintaining and refining the product backlog, ensuring that the development team focuses on the highest-value features.

Product Vision

The Product vision is resumed and updated into a MOU ( Memorandum of understanding ) document. This is a live document, evolving time by time according with our evolution in the market.

This document has the following structure and is available in the Witboost sharepoint:

• Product Vision
• Product Strategy
• Product principles
• User Personas
• Go to Market Strategy
• High level roadmap

Product Roadmap

We embrace outcome-based roadmap, and it means that the roadmap focuses on solving business problems instead of being just a list of features. We love this approach because it is really result oriented and it is aligned with other practices we adopt within the company, like OKR. The items of the roadmap have not due dates, we only group them based on their outcome and with a general timeline. We aware that up-front plans never work in our world, and also we want to be free to discover and learn new things along the path and change business priorities based on this. We rely on high integrity commitments and positive intents. The team is always doing its best to accomplish the goal, but in case it fails no drama, it is just another opportunity to learn something new about the process. Product management is about learn and discover, by definition an uncertain process, let's deal with that.

Our roadmap has always a key goal, something that we want to enable for the customer, and that is our North Star. It is totally useless to define a roadmap for more than a quarter, because product management it is simply too unpredictable and we don't want to loose the opportunity to bring great value and innovation for our customers, because we already promised a specific roadmap for the next 12 months.

After the team brainstorming and the discovery activities, the product manager is accountable to take the final decisions related to the roadmap and commit it with customers and stakeholders. The roadmap should be accessible to the whole team and it is important to notify the whole team when something is changing at that level (not at backlog level).

The main tool where the product manager work on the roadmap is Miro. After defining the key goals and capabilities in the "MOU" product document, the full flow is developed in Miro according with several best practices.

Our roadmap is data driven so the first phase is data collection. This happens along the way through several sub-processes:

• customer interviews: periodically we interview our customers to collect experiences, needs and ideas. When interviewing a customer the product manager is not interested in the solution, but in the underlying pain-point and motivation. Customer interviews are organized by the professional services or customer success, to easily connect the product manager and the customer. During these interviews also the product designer and the product dev lead participate to better get flavours and specific elements. All the customer interviews are written into a specific miro section "customer interview"

• pre-sales interaction: the product manager must be strongly connected with pre sales process because it is important to discover what prospects are looking for in their strategic journey. This is especially important to be able to sense what the market requires and how our value proposition can support it. All the insights and opportunities collected during demo and prospect interactions are written into a specific miro section "prospect interactions"

• independent study: continuously understanding the market needs by studying and participating at conferences

• feature requests: all customers and professional services can create a feature request with a specific Form. These requests are periodically reviewed by the Product Manager, filtered and moved into the feature backlog on Miro

• customer and market surveys: once a quarter we submit a survey to our customer and prospects to better know their priorities. All these information are then moved into Miro

After collecting these data, we enter in the data processing phase, with the following phases:

• Conversations to opportunities: All the conversations are processed in order to cluster insights and opportunities in "Pains" and "Delights", basically to understand what is painful for the customer and what would delight the customer. The obvious goal is to identify opportunities to improve the product.

• Map opportunities to the product vision: A good product should not solve every kind of problem the customer has, but only those that are aligned with the strategic vision of the product. To do this we adopt the Opportunity Tree method. In Miro there is a specific section for the opportunity tree. This is representing as a tree the business outcomes that we want to achieve with the product (e.g. "Increase the number of users in each Witboost installation"), then under each business outcome we map the product outcomes useful to reach the business outcome (e.g. "reduce the friction for data consumption from new users"). Under the product outcomes we map the opportunities that can move the product towards the product outcome (e.g. "I need to understand where the data is before consuming the data"). Now that the opportunity tree has been created we can try to map solutions, ideas and features requests into these opportunities to create value. If a feature request cannot be mapped in the opportunity tree means we should not develop that feature. Very often the Product Manager has hard times in deciding what to not develop, instead of deciding what to develop.

• Features progressing: If a feature or solution can be mapped into the opportunity tree, then we can progress with the rest fo the flow before deciding to develop it. The feature need to go through the following phases:

  • Brainstorming and early validation: the feature is evaluated with the team to understand where it can fit and have a first idea of feasibility, viability and desirability

  • Prototype and Discovery: if it is a complex one we always try to build a prototype first. The prototype can be only a static design or it can be an implemented one. The prototype has the goal of acquiring more information about feasibility, viability and desirability. With a prototype is possible to ask feedbacks to customer and prospects without the risk of misunderstandings. Also implementing a prototype will provide more confidence to the team about the feasibility of the feature itself for the real implementation

  • Validation: Lot of good ideas, in line with our strategy stop their journey here because maybe they don't bring too much value. When we have a good set of solutions in the validation stage we run the validation process typically involving customers with survey and interviews, or by collecting feedbacks from the wide market. A feature that is worthy to be developed must add enough value to the overall customer perception. We use the Kano model to do this evaluation.

    All the features we want to validate are scored based on importance and satisfaction and the relative value that each feature can add to the customer perception. We focus always on top-right corner ( High Opportunity Area ). This process happens on Miro as well.

  • Prioritization: After a set of features are validated, we need to prioritize them. For this we use the "Impact vs Effort Matrix" framework. We estimate the effort needed to implement a feature and we compare it with the perceived impact for the customer. After this we prioritize in order "Easy Win" --> "Big Bet" --> "Incremental" and we skip "Money Pit". Because our current market fit phase we tray to stay away also from incremental and take risk towards "big bet". After this step we have the feature backlog, prioritized for the development team.

This process is continuously repeated based on new opportunities, ideas or market scenario changes. We don't want to stick to the plan, we want to fit the market.

The roadmap is then an emerging picture from this process. When we have the features validated and prioritized, we go back into the opportunity tree and we understand which strategic goal we are targeting the most.