Does the shoemaker’s son always go barefoot?

This is an expression that we normally say when the family of a skilled or knowledgeable person is often the last to benefit from her expertise.

One of the topics I talk about most with my clients, to the point that I launched a workshop on the subject (link in Portuguese), is the importance of having a clearly defined vision and strategy so that I can define OKRs.

Although I now work alone, I decided early on to use vision, strategy, and OKRs tools to help me daily. To show that here the shoemaker’s family does benefit from his experience, here are the vision and strategic objectives of Gyaco, my consultancy and training company on product management and digital transformation:

Gyaco Vision
Gyaco strategic objectives

OKRs

As the company is just me, that is, I’m responsible for doing everything in my company (marketing, sales, finance, billing, operations, customer service, and providing the service to my customers), I figured I wouldn’t need OKRs.

However, while helping a client build their OKRs, I decided to try building my own OKR spreadsheet, which is the one below.

Gyaco’s OKRs for 2023
Chart with the evolution of Gyaco’s OKRs

I built this spreadsheet during the week of January 23rd, and it was eye-opening. I started the year well, with almost all OKRs in green. The ones that weren’t in green were in yellow, meaning they were close to where I wanted them to be. However, the following week the scenario changed, with yellows increasing and some reds appearing. The following week, between Jan 7th and Jan 15th, was a week off that I took. When I got back from my week off and decided to do the OKRs spreadsheet, I saw that things weren’t the way I wanted, and I put energy into improving that, which we can see in the following week.

Even if you are a one-person company or a few people, OKRs derived from your vision and your strategic objectives are a very useful tool to help you get where you want to be.

Summing up

  • It is common to happen as in that phrase that says that at the shoemaker’s house, his family always goes barefoot”; that is, the family of a skilled or knowledgeable person is often the last to benefit from her expertise.
  • At my company, Gyaco, I tried to ensure that the family had shoes; that is, I designed the vision and strategic objectives as soon as I decided to follow this path of being a full-time product coach and advisor.
  • However, I still wasn’t using one of my favorite tools, OKRs, because I didn’t think a one-person company needed them. After a conversation with a client about this tool, I decided to apply it in my one-person company, which proved to be very useful!

Digital product training, coaching, and advisory

I’ve been helping companies bridge the gap between business and technology through training, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage 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 bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Downsizing and layoffs

During my 30+ years leading teams in technology companies, I have seen and felt the effects of some crises and recessions. According to Wikipedia, since 1990, there have been 4 US recessions, the most recent being COVID-19 in early 2020. According to the Recession Probability Model by The Conference Board, a global non-profit research organization about future scenarios, we are on the verge of another recession:

US Recession Probability Model by The Conference Board

Downsizing and layoffs are commonly used tools in times of crisis and recession. They seem to be used more in technology companies, as these types of companies tend to move and adapt faster. Tech companies seek capital from investment funds to accelerate their growth, but when a crisis strikes, they need to readjust very quickly. However, downsizing and layoffs are not exclusive to technology companies. Tyson Foods, one of the largest US meat companies, and Goldman Sachs, a global financial market company, also announced layoffs at the turn of the year.

Even in favorable economic scenarios, crises can happen due to internal reasons. It’s possible that some decisions did not prove right, which can cause a company crisis without any influence from the economic scenario. A well-known example is Enron Corporation, one of the world’s leading energy distribution and communications companies, which earned US$ 101B in 2000 and, in 2001, filed for bankruptcy due to accounting and tax fraud and a debt of US$ 13B. More recently, we have the case of Americanas. This large Brazilian retail company started 2023 in crisis for failing to record a BRL 20B debt in its audited balance sheets.

As I explained in the article “Product Management in a Crisis“, companies must analyze two perspectives when they realize that they are entering a crisis:

  • preserve cash;
  • identify and adapt to changes in customer problems and needs.

To preserve cash, we should look at the most common causes. We should aim to preserve or even advance revenue streams while looking at all costs with a magnifying glass. In this cost analysis, the downsizing and layoff tools that we see being applied in many technology companies and non-technology companies, such as the examples I mentioned above (Tyson Foods and Goldman Sachs), come into play.

How to analyze and plan a layoff in a product development team

Throughout my career, I’ve been through some crises and had to make decisions to reduce the team. More recently, as an advisor, I have also been helping some product heads and CEOs with their layoff decisions and planning.

I will not go into the people management aspect of this process here, as there are many good articles on this topic, giving details of what to do and what not to do. In this regard, my recommendation is to use empathy to define the best way to act. If I were fired, how would I want to be treated? If I wasn’t fired and stayed at the company that went through a layoff, how would I react to the layoffs and how would I like to be treated? Always work very closely with the people management team. It is not uncommon to have people on this team with a background in psychology, which can help a lot in this planning.

In this article I will talk about the part of the layoff process related to planning to reduce the product development team. How to decrease the team? Should I just reduce the amount of people in all squads and keep the same amount of squads? Or should I think about dismantling some squads? Here are my recommendations:

  • If you are the main leader of the product development team, or if you share that leadership with a CTO person, I recommend that you do not design the plan alone. Call your direct reports, share with them the need for a team reduction, and start working together on this plan. It is important that your direct reports participate, as they have more knowledge and, consequently, the ability to go into greater detail in the planning. You may wonder if you have leaders with this degree of maturity, which is a relevant concern. It is usually situations like this that help a professional to mature. So if any of them aren’t mature enough, this may be a good maturing opportunity.
  • Instead of just making a single reduction plan, design scenarios. If the need is to reduce by 40%, try drawing scenarios with less and more reduction, for example, 10%, 20%, 30%, 40%, and 50%. In these designed scenarios, it is important to make the impacts clear in addition to the reduction achieved. A good way to make impacts clear is with OKRs. In each scenario, which objectives will not be achieved and results will not be reached?
  • Start by planning reductions of the vacancies. It is common to have open vacancies of two types, new vacancies for new teams that we plan to set up to run new initiatives or to reinforce existing teams and replacement vacancies to replace people who have left. Plan to reduce new vacancies first. Then the replacement ones.
  • If the reduction or elimination of open positions is not enough for the necessary reduction, you should start thinking about reducing the current teams. A very common mistake that I see some people make is to reduce the size of the teams but maintain the number of teams, hoping to be able to continue running all the current initiatives, to reach all defined OKRs, but with fewer people and, consequently, at a slower pace. This is not a good idea. As we say in Portuguese, this is the famous “short blanket problem”. If you cover your head, you uncover your feet. This is the time to prioritize. Which squads can we not dismantle because they are critical to the product’s operation? Which squads were betting on new initiatives, features, and products that we can pause? Is there any initiative, functionality, or product that is not giving the expected results and does not show that it will generate the expected results?
  • Design the various reduction scenarios and analyze how many new initiatives are cut in each one that, in times of crisis, can be suspended and how many vital needs for the operation of your product are cut. How do these scenarios impact achieving the product vision and executing the product strategy? Which OKRs will be impacted? Which objectives will not be reached and which key results will not be achieved? This is an important prioritization exercise that, along with the different scenarios, will not only allow you and your direct leaders to see the impact of the reductions on the team, but it is also a great tool for you to present to the CEO and other leaders of the company, showing what different levels of reduction can impact on the company as a whole. In this conversation with the CEO and other leaders of the company, you can decide which is the best – or the least bad – scenario to follow.

Example of analysis and planning of a layoff in a product development team

I will use a hypothetical case to illustrate this example, where I will show the scenery design tool.

The crisis arrived and, after careful analysis of the numbers, you, as the leader of your company’s product development area, reached the conclusion, or received a request from the CEO, that a layoff will be necessary, that is, you will have to reduce the size of the team and will have to make some layoffs. The reduction will need to be 40% of your budget.

You lead a team of 200 people, with a current team of 180 people plus 20 vacancies. Of these 20 vacancies, 10 are new vacancies and 10 are replacement vacancies. The 180 people are divided into 4 product tribes plus 2 structural team tribes as shown below. The 10 new vacancies are to form 2 new squads, the Worf squad in the Star Trek tribe, and the Integrations squad in the Central Systems tribe.

Example of a team with 200 people in 4 product tribes and 2 structural tribes

This team of 200 people is focused on achieving 20 objectives and their key results (OKRs). After conversations with your direct reports, and following the steps described above, you can create the following scenarios.

Example of team reduction scenarios and impact of reductions

I’ve used this scenario table in a few situations in my career, and I’ve recommended it to product heads, engineering heads, and CEOs who do advisory sessions with me. With these scenarios in hand, you can now talk to the CEO and other company leaders to show the impact of the reduction, as well as alternatives for smaller reductions with also smaller impacts on the productivity of the product development team, so that you can evaluate the options.

Having fewer people will cause the team to drop some balls, meaning you have to make a decision on what to stop doing. Some objectives and expected key results should be deprioritized, as we will have to lay off some people and we will have a smaller team. It’s that simple. Less money implies a smaller team, which implies less things that this team can do and, consequently, less objetives can be achieved and key results can be achieved.

Summing up

  • Crises happen with some frequency. In 2020 we experienced the COVID-19 crisis. By early 2023 we may be heading into a recession. And even without an external crisis, companies may have made decisions that were not right.
  • When a crisis happens, we have to preserve cash.
  • One of the ways to preserve cash is to reduce the size of the product development team, that is, to downsize and layoff.
  • When analyzing and planning the layoff, we must design scenarios that allow us to understand the impact of each scenario on achieving the product vision and executing the product strategy. A good way to make impacts clear is with OKRs. In each scenario, make it clear which OKRs will be impacted.

Digital product training, coaching, and advisory

I’ve been helping companies bridge the gap between business and technology through training, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage 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 bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Happy 2023!!!

First of all, I wish you a happy 2023!!!

I hope that this year we continue to advance in our learning about how to make digital products and that, with this learning, we manage to make even better products!

To help with this goal, nothing like a retrospective! \o/

I used the FunRetrospectives app, one of the companies I act as a board member, to help me. The app comes with many ready-to-use retrospective templates. And if you still want to adjust it to your needs, it lets you do that. That’s what I did when I created my retrospective with “Learnings & Facts” on one side and “Questions & Concerns” on the other.

2022 was the year I decided to become a full-time product leadership coach. It has been a very fun journey. Some interesting facts and learnings:

  • I jumped into full-time coaching six months ago. Until Jun/2022, I was doing part-time coaching, a half-day per week time commitment.
  • My average monthly net income doubled in the six months I’ve been coaching full-time.
  • I’m also paid with shares by some clients.
  • Building my brand with articles, talks, classes, and books while I was a full-time exec was very helpful in generating demand. Despite my ugly site (I’m working on a revamp!), I’m already fully booked until Mar/2023.
  • I’m engaged with small startups, growth-stage companies, and enterprises.
  • I’m doing discovery coaching, product leadership coaching, and transformation coaching.

I still have a lot of questions:

  • Am I pricing and charging correctly?
  • Will I be able to continue to generate good net income, or did I have “beginner’s luck”?
  • Am I offering the right services?
  • Am I engaging with the right customers?
  • Will I miss hands-on experience?
  • Will I miss having a team?
  • Will I continue to have learnings that can be useful to other people?

I know the answers and learnings will come over time.

To answer the last question (will I continue to have learnings that can be useful to other people?), this year’s most-read articles list has many new articles that I wrote after starting my full-time coaching career.

The most-read articles can be grouped into three main topics – digital transformation, product leadership, and product discovery:

Digital Transformation

Product Leadership

Discovery

I’m very happy with my first few months in my new career. Looking forward to building an amazing 2023 with lots of learnings, some answers to my questions above, and more opportunities to help people and companies bridge the gap between business and technology through education, coaching, and advisory services on digital product development and management.

Digital product training, coaching, and advisory

I’ve been helping companies bridge the gap between business and technology through training, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage 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 bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Defining Responsibilities

In the chapter What is the difference between product marketing and product management? I commented on how marketing 4Ps (Product, Price, Promotion, and Place) are distributed between product marketing and product managers. This is a macro view of the division of responsibilities. In it, I also talked about how these teams (marketing and product management) should work closely together for the success of the products they develop and manage, as do the Engineering and UX teams, which, despite being distinct roles, should also work closely with product management. Another role that may overlap with the product manager is the project manager. Project managers in product development teams with agile culture are called the Scrum Masters, Agile Coaches, or Delivery Managers.

This proximity often raises some questions such as: “Who is responsible for this task?”, “Whom do I need to consult before moving this other task forward?” and “Who needs to be with me so I can complete this other task successfully?” Often, these situations become jump balls: one thinks she is responsible for a particular task, and the other thinks the same. Or worse, one thinks the other is responsible, the other thinks the first one was, and no one does anything.

RASCI

RASCI is a very useful tool to help define and understand the roles and responsibilities of each person and function. It is the abbreviation of the first letters of the possible roles that a person, area, or function can have in a task:

  • Responsible: the person responsible for executing the task, that is, who has to lead the effort to plan, do and complete the task. There cannot be more than one responsible. Remember the saying that a dog with two owners dies of hunger.
  • Accountable: the person responsible for the task and who has the power to delegate the task to be done to the responsible. Responsible and accountable can be the same person. The rule also applies that there cannot be more than one accountable per task. If responsible and accountable are two different people, the accountable can be seen as the sponsor.
  • Support: are the people or teams that work together and under the coordination of the responsible for the execution of the task.
  • Consulted: the people or teams who do not participate in the execution of the task but who need to be consulted before or while the task is being performed, as they can provide relevant inputs for its execution.
  • Informed: the people or teams who do not participate in the execution of the task, nor need to be consulted before or while the task is being performed, but who need to be informed when the task is completed.

The following is an example of a RASCI responsibility matrix between engineering, UX, product marketing, and product management that we used at Locaweb:

Locaweb’s RASCI responsibility matrix

HOW TO USE

The first step is to build the responsibility matrix. My recommendation is to fill this table by bringing together all the people involved in a room, so you can discuss whether the division of responsibility is ok for everyone and if a task is missing. Most likely, some “shared responsibilities” will appear, but this is a great time to discuss them and define who is responsible. There can be only one person responsible for any task.

Then, the team should try to do the tasks following the responsibility matrix for some time, like one or two months. Then, it is important to do a retrospective to see if everything is ok, or if any adjustment is needed.

From then on, the use becomes automatic, and people will no longer need to refer to the responsibility matrix. Every year, when a question arises, or even when a new task arises, it is good to revisit it.

Power-Interest Grid

There are other areas that don’t work so closely with product management in building the product. For these areas, a good tool to use is the Power-interest Grig.

The Power-Interest Grid is a concept first developed in the 90s by Aubrey L. Mendelow and later explained in the book “Making Strategy: Mapping Out Strategic Success”, by Fran Ackermann and Colin Eden. Based on the power and interest a person or team has in your product, you can classify them into four main categories.

Power-interest grid
  • The players are those who have great power and interest in your product. You need to collaborate with them often. The users and customers of your product are players, and you need to collaborate with them to build the best product that solves their problems and meets their needs. In some companies, the closest founder to the product is probably a player. You should invite these people to any meeting where strategic decisions are made. Schedule individually to present the decisions and ask for their comments and contributions.
  • The subjects are those with little power but high interest in your product. They do not have the power to veto or change decisions, but they have a deep interest in your product. In some companies, we can think of customer support, sales, and marketing as examples of areas that play the role of subjects. They have great interest but do not have the power to change the product. You can communicate with them via weekly status emails and product demos. It is important to collect their opinions, but remember that they do not have the power to change your decisions.
  • The context setters are those with the power to change your product but little interest in your product. Examples of areas that can play the role of context setters are HR and Legal. If HR doesn’t help you build the team, you won’t have a team to build your product. If Legal is not aware of and aligned with the legal aspects of your product, it has the power to block or delay its launch. A CFO and a controller are also two functions that have the power to change decisions that affect your product. It is important to keep context setters well-informed about product decisions. Consult with them before making important decisions. Keep them informed weekly.
  • The crowd is the one with low power and little interest. Even if they have little power and interest, it is important to keep them informed. Usually, a monthly update on the progress of the product is sufficient. It can be by email or in a monthly general meeting with product demos – I’ll talk about this and other meetings in another chapter. Usually, people in the HR, Legal, Administrative and Financial areas are not in the context-setting group.

It is important to note that each company has its own dynamics. Therefore, an area or person that plays a specific role in the power-interest grid of a given company may have another role in a different company.

Empathy

These two tools are very useful for the product manager to better understand how to relate to the other areas of the company and how to manage their expectations.

However, those tools are more useful when combined with empathy, a fundamental tool for the product manager to manage her stakeholders. Empathy is the ability of one person to put himself in the place of another to understand his expectations. Their desires, motivations, needs, and problems.

This characteristic is important for the product manager to understand the customers and users of the product, to know how they relate to it, and what problems they expect to solve or what needs they want to be met. It also helps to understand the impact of your product on your team and people in other areas. Last but not least, the product manager also needs to put herself in the shoes of the owner of the product to understand their expectations of the results the product will bring to the company.

Summing up

  • RASCI is a very useful tool to help define and understand the roles and responsibilities of each person and function.
  • The Power-Interest Grid and RASCI are great tools to help you better understand and interact with your stakeholders.
  • But don’t forget, the main tool that a product manager needs to master and, consequently, have improved and fruitful interactions with its stakeholders is empathy.

In the next chapter, we will start a new book section to discuss product portfolio management. Stay tuned!

Digital product training, coaching, and advisory

I’ve been helping companies bridge the gap between business and technology through training, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage 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 bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

The main reason why products fail

If we search on Google for reasons why tech products fail, we will find many articles with many possible reasons explaining product failures. From 3 of these articles, I was able to compile a list of 26 reasons:

  1. Lack of market focus (a.k.a. segmentation).
  2. Excessive pace of product improvement.
  3. Incomplete products.
  4. Too much capital.
  5. Channel mismanagement.
  6. Failure to establish the right competitive barriers.
  7. Using price alone to attract mainstream buyers.
  8. Improper use of advertising.
  9. Misinterpretation of the innovation-adoption process.
  10. Irrelevant market research.
  11. The company can’t support fast growth.
  12. The product falls short of claims and gets bashed.
  13. The new item exists in “product limbo”.
  14. The product defines a new category and requires substantial consumer education.
  15. The product is revolutionary, but there’s no market for it.
  16. No product-market fit.
  17. Solving the wrong problem.
  18. Aiming for “perfect” instead of “done”.
  19. Not gathering regular feedback from customers.
  20. Iterating too slowly.
  21. Using incorrect assumptions about your customers.
  22. Pricing your product wrong.
  23. Not enough market or industry research.
  24. Investing in the wrong areas of your business.
  25. Problems with your competition.
  26. Poor execution.

And the list can certainly grow bigger. The Verge put together a list of 84 biggest flops, fails, and dead dreams of the decade (2010-2019) in tech, including big failures from Amazon, Google, Apple, Netflix, and Microsoft.

The most common reason for product failure

Behind many of the reasons and failures above, we can certainly find a common behavior, going straight from problem discovery to solution delivery with little to no solution discovery. When talking with my clients about their product discovery, they normally describe situations like:

We did deep user research, and we found problem X, which users want to get solved to the point that they will pay for a good solution, so we decided to build solution Y, but now that we delievered solution Y we are seeing very low adoption…

This happened because they skipped the solution discovery, going from problem discovery straight to solution delivery. Let me repeat this because this is really, really important:

The most common reason for product failure is going straight from problem discovery to solution delivery.

As I mentioned in a previous article, discovery is a set of tools to help us mitigate product development risks. Discovering a problem is easy. Discovering a solution is hard and requires product managers, designers, and engineers to develop possible solutions. Then they need to assess the solutions to determine if at least one works and, if yes, and more than one works, which one has the greatest chance of success.

Sometimes the solution discovery confirms which product or feature we need to deliver, and the product – or feature – delivery is a success. However, there are other times when the solution discovery shows us that we cannot come up with a solution that has a chance of success, which is good. It is good because it will spare us a lot of time and energy from working on delivering a solution that will fail. We need to invest in solution discovery to avoid product failures.

Solution discovery can be a prototype, but it can also be other things like a landing page, where we draw traffic to understand if there’s demand, or a spreadsheet, where we assess the business viability of a certain solution. As I mentioned earlier, discovery is a set of tools to help us mitigate product development risks. There are many tools for the many types of risks in the product development process.

Last week I was talking to a client who had a very interesting solution idea to a certain problem that she discovered that the majority of her customers had. Still, when she decided to run some numbers, she understood that the solution was not financially viable, i.e., the amount of money she would receive from customers would not be enough to pay all the costs to serve the product. And this was good because she was able to spare all the time and money she would invest in building a solution that would become a failure.

A real-life example – a Locaweb product that never came to life

When I was at Locaweb, the biggest web hosting and internet company in Brazil, around 2010, we discovered that some potential customers didn’t want to use the existing website builders and were looking for web design professionals, but without enough knowledge about how to manage the work with this type of professional. As we had experience building websites, we thought we could manage this relationship with web design professionals for the customer.

We were very excited about the opportunity, and we designed a solution. We were already having some discussions on how to deliver it. However, before delivering, i.e., building the solution, we decided to build a prototype to present it to some potential customers and learn from their reactions and feedback.

When we presented the solution prototype to potential customers, it put a dumper on our excitement. We wanted to be the middle person, making it clear that we would do our best to help the customer get a good website, but we didn’t want to be responsible for any misconduct from web design professionals. We wanted that the system became self-regulated through the common 1 to 5 stars rating. When we built our prototype – a one-week effort – and then presented it to potential customers, almost all wanted us to pay some fine for non-delivery or late fees in case things didn’t go as expected.

We made changes to the prototype to present the product in alternative ways to clarify Locaweb’s and the web designers’ roles and responsibilities, but without success. That’s when we decided to cancel the product development. We were very glad we did it, and we then learned how important it is to make solution discovery before putting energy and resources into delivering a full product.

Solution discovery is a very powerful yet simple and cheap way to increase the success rate of our product development efforts. However, many teams ignore it and go from problem discovery to solution delivery. If we had done so in this Locaweb example I just described, it would most certainly be a big failure. It would generate a lot of headaches for Locaweb, our product development team, and our customers.

Summing up

  • The most common reason for product failure is going straight from problem discovery to solution delivery.
  • Discovery is a set of tools to help us mitigate product development risks.
  • Discovering a problem is easy. Discovering a solution is hard and requires product managers, designers, and engineers to develop possible solutions. Then they need to assess the solutions to determine if at least one works and, if yes, and if more than one works, which one has the greatest chance of success.
  • Sometimes the solution discovery confirms which product or feature we need to deliver, and the product – or feature – delivery is a success.
  • Sometimes the solution discovery shows us that we cannot come up with a solution that has a chance of success. This is good since it will spare us a lot of time and energy from working on delivering a solution that will fail. We need to invest in solution discovery to avoid product failures.

Digital product training, coaching, and advisory

I’ve been helping companies bridge the gap between business and technology through training, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage 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 bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Relationship between product management and the other areas

In previous chapters, I discussed the relationship between the product manager and engineering, UX, product marketing, and project management. The question that remains is: what about the other areas of the company? How is the product manager’s relationship with operations, service, legal, sales, administrative finance, and human resources?

Operations

The operations area is responsible for maintaining the product. For online products, ops are responsible for ensuring that all the infrastructure is available and with good performance.

The operational quality of a product has to do with two operational characteristics of the product:

  1. The product must perform well: Each customer’s request for the product must respond to in less than X seconds. The definition of this X is the performance definition of this product. It is important to know that X is not an integer; it can and ideally should be a fractional number less than 1 (for example, the product must answer requests within 0.3 seconds). Different product features may have different performance expectations.
  1. The product should be available for use as long as possible: This is the SLA (Service Level Agreement), defined as a percentage number, for example, 99.9%. This number can be measured in a day, month, or year. Within a month, 99.9% availability means 43.2 minutes of unavailability, while 99.5% means 3 hours and 36 minutes of unavailability. When we look at the availability of a product, we must take into account two factors:
  • Frequency of problems: the time between each outage. Imagine that your product has 99.9% availability, which means a maximum of only 43.2 minutes per month of unavailability. If this unavailability happens on a particular day for 1 minute every 10 minutes, the product will be unstable for more than 7 hours that day. There is an operational metric that should be tracked that helps to measure the frequency of problems. This is MTBF or the mean time between failures.
  • Duration of the problem of unavailability or malfunction: here, the rationale is simple. If there is a problem with the product, the problem should last as little time as possible. There are also operational metrics that must be tracked that help you measure the duration of the problems. This is MTTR, mean time to resolve or average time to resolve.

The definition of good operational quality is a definition that has to be made by the product manager in conjunction with engineering, UX, and operations. Of course, we always want to offer the highest quality possible to our customers, but the higher the quality, the higher the cost to maintain the product.

The product manager needs to define, together with engineering, UX, and operations, what is the acceptable quality level and acceptable operating cost for the product. This is a non-functional requirement, as it is not a product feature. It is a feature that impacts its use.

For operations to operate the product, the product must be “operable”. Seems redundant what I just wrote, but it is not uncommon to see practically ready-to-release products that have to go back to development because some simple operational points were not taken into account, such as: what to monitor, how to monitor it, what to do if monitoring finds something not functioning as expected.

Ideally, this should be considered before you start developing the product. If you fail to do that and think about these points only after the product is ready, there is a good chance that you will have to redo something in the product to fit these operational standards. To discuss what operational issues should be considered before and during product development, it is a good idea to have someone from operations participate more closely in product development.

Although the operations relationship should be closer to engineering than to the product manager, it is the latter’s role to follow that relationship and to help wherever possible, especially in defining non-functional operating requirements.

Customer support

Ideally, your product does not require phone, chat, or email customer service. This is what we call a no-touch or low-touch product. However, as much as you work with UX to make this true, there will always be customers who want to talk to someone at your company for some reason related to your product. Therefore, you should prepare your customer support team to talk to your customers and solve their problems.

Before launching your product, you should prepare and deliver training to your service team so that they are prepared to answer key questions. Once it is released, you should follow up on all the calls not only to see the quality of the answers given by the customer support team but also to understand the main questions they have when using the product.

Your goal should be to minimize these contacts by resolving these questions directly in the product. This is a task that you will need to do with the UX people working on the product. Every time you launch a new feature or an improvement to an existing feature, you must communicate to the support team to get them ready so they can fully support questions about these new features.

Legal

Your business legal area can be internal, external, or even a hybrid of these two options. Regardless of the model, it is important that it has good knowledge of the digital field and is constantly updating itself, as many laws and regulations are still being created. New laws and regulations related to software products, digital products, and online products come up quite often, and it is important that your legal department monitors and knows the details of these new laws and regulations.

The legal area has two main functions linked to your product:

  • User Agreement: In this agreement, the main product features are documented, including service level, service type, data privacy policy, and payment methods. In addition, this contract must contain the rights and duties of both your customer and your company, i.e., the rules that must be respected for the proper functioning of the product. For example, at Locaweb, we decided at a given time to provide our Website Hosting product with unlimited disk space. To be able to do this, we have contractually agreed on what can and cannot be done on our Unlimited Disk Space and Hosting Website Hosting product to ensure the product works well for all customers. We’ve created the unlimited policy explaining that “having unlimited space doesn’t mean you can use your hosting in a way that impairs the operation of the server, for unlawful purposes or otherwise violates applicable law”. In addition to writing the contract, the legal handles all claim that your clients make in the legal context, usually through lawsuits against your company; therefore, you should use empathy to understand the concerns your legal area certainly will have about your product and how it is used.
  • Vendor Agreement: In this agreement, the focus is on how your company’s relationship with the software vendors that will be part of your product will be managed. For example, at Locaweb, we have a Web Hosting product on Linux or Windows. On Linux, we have to understand the open-source software use agreements to see if the Linux Website Hosting product can be built using such software and if there are any restrictions we should consider. On the Windows platform, we must constantly check Microsoft’s software licensing agreement to ensure that we are offering the Windows Site Hosting product following Microsoft policies.

Sales

The sales team needs to be trained by you and the product marketing person about the product to be launched. After that, it is important to make training updates whenever you release news about your product.

Another important point regarding sales teams is that they can provide important feedback regarding your product. New features, adjustments to existing features, price, and business model adjustments are all topics that the sales team can certainly contribute to. But here it is worth remembering empathy again, that is, remember what the sales team’s goal is: to sell. They see your product from the perspective of “how to sell more”. You need to use your discernment and customer knowledge to judge if the sales input is valid for the product or if it may eventually hinder your goals.

For example, it is fairly common for a salesperson to say that he has enormous potential to make a big sale, but for the customer to make the deal, he needs some new feature, and if it is not implemented, that sale will be lost. It is up to the product manager to have insight into the importance of this new feature for the product and other product customers.

As seen in the Growth: how to prioritize the roadmap? chapter, when I commented on the difference between the Email Marketing Locaweb and All In Mail products, the product context makes clear this need for product manager insight. Accepting these special requests in the Email Marketing Locaweb product makes no sense. In the All In Mail product, these requests from the sales team should drive your roadmap.

Finance

Finance is the area that will allow product managers to understand if the product they manage is a good product for the company; that is if the return on the product is bigger than its costs. Of course, you and product marketing will keep track of your product revenue daily, but the costs aren’t as simple to track. Finance can help you calculate and track product costs.

You can divide your cost into two broad groups: the cost of maintaining your product and the cost of attracting customers to your product.

The cost of keeping your web product up and running is what we call operational cost. In this category, we have cost with the infrastructure and people needed to keep the product running. Here in this group, you should also consider your development team, that is, the UX people, the product engineers, and you.

Another operational cost that should also be considered here is the financial cost, i.e., the taxes you pay. Finance, along with the legal department, is best suited to define the best tax structure for your product.

Marketing and sales investments are the cost of attracting new customers. Whether you spend on AdWords or another online and offline advertisement, you will have a cost, and you must measure the return it will give you. How many $ do you need to invest in marketing to bring in a customer? How much revenue does this customer bring? Is it enough to pay the cost of attracting it, plus the operational costs, and still have a little left to pay for the investment made in developing the product?

This category also includes the cost of sales and marketing teams and the commissions given to the sales team if your company chooses to pay them sales commissions. If you use indirect sales channels, such as selling through partners, partner compensation will also come as part of the cost of attracting new customers. If the marketing team decides to run promotions, such as a first-year discount, it also comes as the cost of attracting new customers.

When you price your product, it is important to consider its cost structure, as the revenue serves to cover these costs and generate some profit. If you do not get enough revenue, your product will not succeed.

Human Resources

At first, it may seem that HR has nothing to do with the product and its management, but it’s all about it. HR is essential to product success, as it will be part of finding and attracting new professionals to work with.

In addition, HR should help with onboarding the new employee, that is, in his or her early days at the company. HR can also assist in training and evaluating people on product development teams. Hence its importance in the success of the product.

Both at ContaAzul as well as at Gympass, the product development teams have dedicated HR people working with the teams, with two main functions: talent acquisition and HR business partner. At Gympass, the dedicated HR team sits with the product development team.

Administrative

This is another team that seems far from the product and the team that develops the product, but it is not. The administrator maintains the necessary infrastructure for the business to continue to function. Office, meeting rooms, furniture, office supplies, and office services (cleaning, snacks, meals, coffee, deliveries, etc.) are all necessary for your business to function and, consequently, for the product development team to be able to do their work.

Summing up

I chose to put all of these areas in one chapter rather than devoting one to each, as I did to talk about engineering, UX, product marketing, and project management because interaction with these areas is not as intense. However, keep in mind that these areas and the product manager’s good relationship with them are essential for the success of your product.

Recalling what I said in the chapter Main characteristics of a product manager, the most important characteristic every product manager needs to have is empathy, that is, the ability to put yourself in someone else’s shoes to understand her motivations, needs, and problems. This characteristic should be used not only with the customer and users of your digital product but also with people from different areas of the company. The product manager must understand the impact his product has on their work so that they can make working together as fruitful as possible.

As we have seen in this and previous chapters, the product manager interacts with virtually every area of the company, and with many of them, roles and responsibilities may overlap. In the next chapter, we’ll look at a valuable tool to help clearly define the roles of each area in the different tasks related to a product’s life cycle.

Digital product training, coaching, and advisory

I’ve been helping companies bridge the gap between business and technology through training, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage 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 bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Discovery is not a process

It’s pretty common for people who are new to product development to think that product discovery is a process, but we need to understand that’s incorrect. The correct definition is:

Product discovery is a set of tools to help us mitigate the risks of product development.

First, we need to understand that product discovery has a very clear objective, risk mitigation of product development. Why? Because product development is a very expansive endeavor. Normally, this team is a big part of the company’s costs, so we need to be as sure as possible that we are investing their time in developing things that will help the company reach its objectives while will solve a problem or will address a need of the customers.

Risks of product development

What types of risks are we talking about? If we search for types of risks in business on Google, we will find many types of risks. Some articles are even talking about ten types of risks. Marty Cagan talks about four types of risks:

  • value risk: whether customers will buy it or users will choose to use it.
  • usability risk: whether users can figure out how to use it.
  • feasibility risk: whether our engineers can build what we need with the time, skills, and technology we have.
  • business viability risk: whether this solution also works for the various aspects of our business.

Even though I understand this need to categorize the types of risks of developing a product, the type of risk is not as crucial as it is the risk’s priority, i.e., knowing which risk has the biggest potential to be a significant obstacle to the success of the product. Remember, we want to develop a product that will help the company that owns the product reach its objectives while solving a problem or addressing a need of the customers of that company. That’s what it means to build a successful product.

Discovery as risk mitigation tools

For this reason, we need to identify and prioritize the risks. After prioritizing the risks, we use Product Discovery as the set of tools that help us mitigate these risks. I explained that Product Discovery has two sides, problem discovery, and solution discovery. Let me give you some examples.

  • Problem discovery: Back in 2011, I had an idea to create a calorie counter app that informed me not only the number of calories of each food but also the quality of the calorie with a simple red, yellow and green color system, where red calories, like candies and cakes, should be avoided, yellow calories, like rice and meat, could be eaten moderately and green calories, like lettuce and spinach, could be eaten without restrictions. The first thing I decided to test was if there was any demand for such an app. So, before building the app, I decided to create a landing page for the app and then build a Google Adwords campaign to send some traffic to this page. The page explained the product I was planning to build and how much it would cost. I tell the full story of this app in my book Startup Guide: How startups and established companies can create profitable digital products. This is a typical problem discovery risk mitigation, i.e., I was trying to mitigate the risk of knowing if it was a problem worth pursuing. For those who don’t read Portuguese, I’ll translate the page contents below the image.
Page describing the app I was planning to build

ContaCal: Simple and efficient system to control daily calories

  • There’s no magic solution: To lose weight we need to eat last calories than we use
  • ContaCal will help you: the ideal solution to control your calorie daily intake and help in your nutritional education
  • One month free: so you can test the service. After that, you will pay U$ 3,99 per month.

Please fill out the form below to receive news about this service.

Get to know more about this service in our blog.

Solution discovery: Here’s another example, now a solution discovery example. Richard and Maurice McDonald, known as the McDonald Brothers, were American entrepreneurs who founded the fast food company McDonald’s. Their story was told in the movie The Founder, and there’s a very interesting scene where the McDonald brothers explain how they figured out the best kitchen layout to speed up order processing. A very interesting solution discovery process:

As we can see, we can be very creative when it comes to discovering how we will mitigate a certain risk. The important thing is that we know the main risks and then discover how to mitigate them as fast as possible.

Summing up

  • Product discovery is not a process. It is a set of tools to help us mitigate the risks of product development.
  • There are different ways to categorize the risks of product development. More important than knowing the type of risk is prioritizing the risks so we know to which risk we should apply product discovery techniques.
  • There are many product discovery techniques available, and we can be creative and develop a new technique for the risk we want to mitigate. The important thing is to mitigate the risk as fast as possible.

Digital product training, coaching, and advisory

I’ve been helping companies bridge the gap between business and technology through training, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage 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 bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

How to turn a feature team into a product team?

After reading my last article on the differences between a feature team and a product team, one may realize how valuable a product team is and may ask herself what we need to do to turn a feature team into a product team. Well, that’s the topic of this article! \o/

Not all feature teams are ready or willing to turn into a product team

A product team is given a problem to solve and an outcome to achieve. The team has complete autonomy to decide how to solve the problem and achieve the outcome and is incentivized to do so as fast as possible. Ideally, the team has also the autonomy to define what problem to solve and what outcome to achieve.

Product teams have to achieve outcomes, not only deliver products and features. The products and features they deliver are means to generate results for the company that owns the product and to solve a problem or to address a need of the customer. This result for the company can be more revenue, lower costs, increase customer engagement, etc.

Some teams and people are not willing to be concerned about business results. They prefer to be told what to deliver and to work on delivering what was asked. In this case, they should look for places to work where being told what to do is the common practice. However, my understanding is that the number of places working this way is diminishing and soon it will be quite hard to find these places, the same way that today is very difficult to find places where Waterfall is the preferred software development process.

Some teams and people may be willing to be concerned about business results, but they are not equipped with the knowledge needed to understand the business in order to deliver business results. These people need to be educated on how the business works so they can devise ways to impact the business through technology.

The feature team is ready to turn into a product team

Ok, so you believe the feature team is ready to turn into a product team, i.e., the feature team is both willing to turn into a product team and has the necessary business understanding in order to impact it with technology, then it’s time to work on transitioning the feature team into a product team.

This transition should be considered under two perspectives:

  • business people: whenever business people bring new requests to a product team, the business people need to bring these requests in the format of problems to be solved and outcomes to be achieved. They should refrain from bringing solutions or, if bringing a solution, making it clear that it is a solution hypothesis, not a solution implementation request, and the product team has complete autonomy to come up with other solution hypotheses to be tested. It’s ok for people from business to participate in the solution discovery, but the contribution should come in the form of collaboration not mandate.
  • product team: the product team needs to be proactive in impacting the business. Whenever the team is asked to implement a certain solution, the team should ask what is the problem we are trying to solve with this requested solution and what are the outcomes expected. If the person who’s asking (business person, manager, C-level, founder) is not willing to answer, explain to her that if the product teams knows the problem to be solved and the outcome to be achieved, the team may be able to figure out solutions that may be faster to implement.

What if business people say that the team should only implement what was asked?

In some cases, it may happen that the business people are not willing to disclose the problem to be solved and the outcome to be achieved. They may simply say that they know what they are asking and the team must implement it. In this case, my strong recommendation is that the people from the product team look for another place to work unless they are willing to work as a feature team.

A product team is always given problems to solve and outcomes to achieve. The team has complete autonomy to figure out ways to solve the problem and to achieve the outcome as fast as possible. This autonomy is necessary because the product team has the necessary knowledge and experience in technology and digital product development to come up with the best solutions.

Ideally, the product team has also the autonomy to define what problem to solve and what outcome to achieve. That’s the ultimate stage of maturity of a product team. In this stage, the team understands a lot about the business in order to define with some input from business people what problems to focus on and what outcomes to achieve.

Summing up

  • Not all feature teams are ready or willing to turn into product teams. If not ready, we need to educate them on the business so they can devise ways to impact the business through technology. If not willing, probably we need to change the team to have people that want to deliver results to the business.
  • To make the transition, both business people and people in the product team have to collaborate. People from business should refrain from bringing solutions to be implemented and should instead bring problems to be solved and outcomes to be achieved. People from the product team should always ask what’s the problem to be solved and the outcome to be achieved whenever they are asked to implement something.
  • In some cases, it may happen that the business people are not willing to disclose the problem to be solved and the outcome to be achieved. They may simply say that they know what they are asking and the team must implement it. In this case, my strong recommendation is that the people from the product team look for another place to work unless they are willing to work as a feature team.
  • Ideally, the product team has also the autonomy to define what problem to solve and what outcome to achieve. That’s the ultimate stage of maturity of a product team. In this stage, the team understands a lot about the business in order to define with some input from business people what problems to focus on and what outcomes to achieve.
  • This autonomy is necessary because the product team has the necessary knowledge and experience in technology and digital product development to come up with the best solutions.

Digital product education, coaching, and advisory

I’ve been helping companies bridge the gap between business and technology through education, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage 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 bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Feature Team vs Product Team

I’ve already written about the difference between solution-implementing teams and problem-solving teams. I’ve also written about the #1 responsibility of a product manager, which is to deliver results as fast as possible.

However, as these are very important topics for any product person, for any product team, and for any company that has or wants to have product teams, I decided to prepare a table to clarify the differences between feature teams and product teams:

Differences between feature teams and product teams (click to enlarge)

So, what do you think? Is there any other feature that should be on this table?

In the article Why “business demands => technology implements” doesn’t work it is clear that Feature Teams will not generate the best results. To succeed in using technology to generate results for the company and for customers, we must have Product Teams.

What to do if you are in a company with a Feature Team? Is it possible to transition to Product Team? How to make this transition? That will be the topic of my next article!

Summing up

  • There are clear differences between a Feature Team and a Product Team. The differences are not only in the definition of what they are, but also in the role of the product manager, in the way prioritization is done, and in the main deliverables.

Digital product education, coaching and advisory

I’ve been helping companies bridge the gap between business and technology through education, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage 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 bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

We deal with people’s money, we don’t have room for errors

When I talk about the release early and often behavior of successful product companies during in-company trainings or in-company talks, some people mention that their business is too risky and they don’t have room for errors. For instance, a bank that works with customers’ money, or a hospital that takes care of its patients’ health. They say that error is not acceptable and, for this reason, they cannot launch incomplete products. They have to launch a complete product that has all the minimum required features. Some people even say

“It’s easy for a startup, with no customers, to launch the very minimum (and embarrassing) first version of its product and evolve from there. We are a big company, we have hundreds of thousands of customers, and we cannot afford to make mistakes.”

And they are right, making mistakes in front of thousands of customers is not wise behavior.

Hack: alpha, beta, and go-live terminology

For this reason, I decided to use a hack to foster a digital product culture behavior of releasing early and often. The hack is the use of the alpha, beta, and go-live terminology. I started using this terminology to explain in which stage a product or a feature is. In the alpha stage, the product may not work properly. If it’s in alpha, it should be offered only to customers who understand the issues of using a new product and can cope with these issues without a bigger burden. So this should be a handful of clients, no more than that. At the beta stage, major issues of the product are fixed, but the errors may still occur and the user experience can and will improve. In this phase, it is possible to offer the product or feature to tens of customers. Then, when all known errors are fixed, and the user experience is working properly, then its time to move the product into the go-live stage, where the product can be offered to all prospects and existing clients. This certainly helps sales and customer support teams understand the release cycle of new features and new products.

I use the above slide to present this terminology to the company. Feel free to use it in your company. This slide was created by my dear friend Luis Figueira.

Slide explaining alpha, beta and go-live terminology

Workshop to Create the Vision and Strategy of your Product

Without the clarity of your product vision and strategy, it is very difficult, if not impossible, to manage your product. How do you decide where to put your focus and energy? What to leave for later? How to show stakeholders what you intend to do with the product? How to have arguments to say no to requests for new features in your product?

That’s why I created the Workshop to Create Your Product’s Vision and Strategy. Spaces are very limited and it starts next Monday, so reserve yours now!

Digital product education, coaching and advisory

I’ve been helping companies bridge the gap between business and technology through education, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage 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 bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.