I have been using and teaching others to use what I have called the product management and development playbook. I have written about this playbook before, where I show it and explain in what order and how often we should define, revise, and communicate the vision, strategy, team structure, and OKRs. These are very useful tools to help us increase the chances of success of our products.

Product Management and Development Playbook

In my interactions with my clients and other consultants who help their clients make better products, I realized that there was a key element missing from this playbook:

Discovery and Delivery: ongoing initiatives, hypotheses, tests, and experiments to deliver the product or functionality that will help us achieve the key results that help us achieve our goals.

So here is an updated version of the playbook:

Updated Product Management and Development Playbook

This Playbook helps us understand the topics we should address when managing and developing products. For example, we cannot do product discovery and delivery if we do not know what objectives we want to achieve and what key results (KRs) indicate that we are achieving these objectives.

• Vision & Purpose: this is always the first topic to be addressed; without it, all the others are pretty challenging. The product vision is what the product will be in the future, 3 to 5 years from now, and the purpose is the motivation for the vision. Why do we want the product to be that way in 3 to 5 years? It should not always change, but it is essential to review it annually or when some event (external or internal) happens, such as an economic crisis or your company is acquired. When you are a startup, pre-PMF, it is likely that the vision will change as often as the startup pivots until it finds its PMF. The vision and purpose should be communicated whenever it is important to remember them, at least once a month in all-hands meetings.
• Strategy: this is the path we define that will help us make our vision a reality. It is the opportunities we will explore and our weaknesses that we will improve. How can we define the path if we do not know where we are going? Therefore, to define strategy, we need to define the vision. The strategy is reviewed and can change yearly as we learn how to make the vision a reality. Or it should be reviewed when some relevant internal or external event occurs. For example, when the Coronavirus pandemic happened, everyone was prepared with their 2020 strategies and had to review them. Strategy should also be communicated whenever it is important to remind them in all-hands meetings at least once a month.
• Team Structure: This is who we need to make our vision a reality. How many people will we need? How organized? Depending on the theme of our product, will we need people with specific knowledge? This derives directly from the vision and is designed simultaneously as the strategy. Team structure is an essential part of the strategy. Once defined, we should also review them annually whenever a relevant external or internal event occurs. Although they are reviewed annually, they should not change annually unless significant changes in the strategy exist. They should also be communicated whenever it is important to remember them, at least once a month, in all-hands meetings.
• OKRs: These are the objectives we want to achieve to execute our strategy and the key results (KRs) that show us that we are achieving these objectives. They are defined by the teams collaboratively, with the vision and strategy as a context. They should be defined quarterly, about two weeks before the start of each quarter. We should monitor them weekly to see if we are moving our key results in the right direction and to catch any impediments while they are still small.
• Discovery and Delivery: we do this to achieve our OKRs and, consequently, execute our strategy to make our vision a reality. These are initiatives, hypotheses, tests, and experiments that we do continuously to deliver the product or functionality that will help us achieve the key results that help us achieve our goals. As mentioned, it must be done continuously; we must continually work on figuring out what product or functionality we should build, and we must constantly work on delivering that product or functionality. We should aim to deliver software at least once a week, ideally every day, ideally multiple times a day. We must communicate (internally and externally) about these developments frequently to ensure alignment and facilitate expectation management.

Okay, now with the updated playbook, I can also present the updated version of the table where I explain when we define, revise, and communicate the playbook elements:

When to define, revise and communicate?

Important: This is NOT a process; it is a playbook. Even though a sequence must be followed, this does not mean there are phases or steps in a sequential process. For example, we cannot define OKRs if we do not have a vision, strategy, and team structure. However, we do not define OKRs once and start working on initiatives. OKRs are defined and reviewed quarterly, and every week, we check how they are progressing and whether any impediments need to be removed.

Gyaco’s areas of operation

With the playbook update and my full-time dedication to Gyaco, my training and consulting company in product management and digital transformation, it has become increasingly clear where Gyaco operates.

• Training: From a training perspective, I work with clients on all topics in the playbook. In my training sessions, both in-company and public, I work on product vision and strategy, team structure, OKRs, and discovery. Training means educating and training the client in the concepts, principles, and tools necessary for developing products with a chance of success. This training is usually done through talks, training, and mentoring, which can be individual or in a group.
• Consulting: Consulting means doing things for the client, that is, the client specifically asks me to work with them, or in some cases do it for them, to build the product vision and strategy, define the team structure, and guide the team in creating OKRs and discovery hypotheses. As an interim CPO (or CPTO), I provide this type of consulting service covering the five themes of the playbook, but I can only serve one client at a time, as it is a very intensive job. In addition to being an interim CPO, I have provided consulting services to several of my clients on specific themes of the playbook, mainly focused on facilitating the construction of product vision and strategy, as well as defining and reviewing team structure.

A few days ago, a potential client specifically asked me to facilitate an OKR definition session, which I had done a few times, either when working at a company or acting as an interim CPO. However, some people specialize in facilitating OKR definition:

• Felipe Castro helped us implement OKRs at Locaweb in 2016 and has extensive experience helping companies define and monitor OKRs.
• Paulo Caroli did this type work for years at ThoughtWorks with clients of all types and sizes. I had the opportunity to accompany him in one of these OKR definition sessions at a common client and it was a very cool job.

In addition to OKRs, there is another theme in the playbook: discovery + delivery, i.e., definition and implementation of initiatives, hypotheses, tests, and experiments, which a discovery consultant can help with. Marty Cagan defines this type of consultant as a Discovery Coach:

Every Discovery Coach has their preferred way of engaging with a team, but usually they are with you for a week or so at a time, with one or a small number of product teams, and they help you through one or more discovery cycles of ideation, creating an MVP experiment (usually a form of prototype), validating that prototype with customers to gauge their reactions; engineers to evaluate feasibility; and stakeholders to assess whether this solution would work for your business.

Discovery Coaches are typically former product managers or product designers (or former leaders of these areas) and they have usually worked for, or with, leading product companies.  So they are able to work side-by-side with actual product managers and designers, and not just recite Agile platitudes, but actually show the team how to work effectively.

I know three people who work in this discovery coach model

• Gabrielle Bufrem: a Brazilian who has lived abroad since 2011, worked at Google, EF, Pivotal Labs, and Otter, and is now a product leadership coach and advisor.
• Paulo Caroli: during his many years at ThoughtWorks, he has helped countless clients discover which product or feature makes the most sense to experiment with to help achieve their goals. His experience has become the book and the Lean Inception method, a product creation methodology that allows collaboration, with the goal of making the construction of the Minimum Viable Product (MVP) faster and leaner.
• Sheila Chang has worked with digital products for over 20 years and, since May 2021, has been managing iFood’s platform products, including a product common to over 100 applications. Sheila recently launched the book “Platform and API Management: Strategy and Discovery for non-technical Product Management” (only in Portuguese).

Some other people I know who work with both themes:

• Arthur Castro:  founder of Product Arena, and led product management at Docket, Loft, Tembici, among others.
• Bernard de Luna: was product director at ThoughWorks Brazil and author of the book “INCREDIBLE: The truth behind extraordinary product people” (only in Portuguese).
• Tiago Rosa: we worked together at Locaweb. He was head of design at GetNinjas and Leroy Merlin (in Brazil and France).

In conclusion

I have used this Playbook with my clients since mid-2022 and have always received positive feedback. Now, with the update that includes discovery and delivery as part of the Playbook, it becomes even clearer which tools to use to increase the chances of success of the products we create, solve the problems of the product’s users, and achieve the goals that the company that owns the product wants to achieve.

Workshops, coaching, and advisory services

I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.

Digital Product Management Books

Do you work with digital products? Do you want to know more about managing a digital product to increase its chances of success, solve its user’s problems, and achieve the company objectives? Check out my Digital Product Management books, where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Digital transformation and product culture: How to put technology at the center of your company’s strategy
• Leading Product Development: The art and science of managing product teams
• Product Management: How to increase the chances of success of your digital product
• Startup Guide: How startups and established companies can create profitable digital products