An anti-pattern is a common but ineffective and counterproductive response to a problem. This term was coined by Andrew Koenig in 1995, inspired by the 1994 book Design Patterns: Elements of Reusable Object-Oriented Software by Gamma Erich, Helm Richard, Johnson Ralph, and Vlissides John, who lists a series of software development design patterns that their authors found simple, succinct and effective for the most common problems.
The term was popularized by the book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by Raphael Malveau, William Brown, Hays McCormick, and Thomas Mowbray, which extended its use beyond the software design field to refer informally to any bad solution to a problem.
Wikipedia anti-pattern page lists over 70 antipatterns. I will list below the anti-patterns that I have encountered most often in my career. These anti-patterns that I quote below happen when the company’s leadership does not have enough experience in digital product development and is advised by people who have been successful in managing software development in the past, but who have not updated themselves.
As I explained in the introduction, software development is a very new science, especially when compared to other sciences like astronomy, medicine, mathematics, chemistry, civil engineering, etc. The first time a computer stored software in memory and successfully ran it was at 11 am on June 21, 1948, at the University of Manchester, on the Manchester Baby computer. This means that software product development is in its infancy. If a professional does not keep up to date, the knowledge and experience that has made him successful in the past may not be the most suitable to make him successful in the future.
Excessive use of documentation will undoubtedly slow down the product development team. It is not for nothing that in the Agile Manifesto, written in 2001, we say that we value “Software in operation more than comprehensive documentation”. Unfortunately, for some leaders documentation is even more important than the product itself. Nothing can go into production if it is not properly documented.
The last time I wrote a PRD (Product Requirement Document or Product Requirements Document) was in 2005 right when I joined Locaweb. A very time-consuming job, where I documented in detail everything we needed to implement in the product. I passed to engineering and sometime later the implementation was made with many errors because the engineers ended up not understanding what was written in some parts and decided to implement it as they saw fit. From that, we started to decrease the use of extensive documentation and increased the interaction between product managers, product designers, and engineers.
Marty Cagan has a very cool article called How to write a good PRD where he comments at the beginning:
I provide this document here mainly for historical purposes. It was written in 2005 to reflect best practices from previous decades.
I have not advocated the use of PRDs for many years, starting around 2007. It is not that PRDs are so bad. However, if the product manager is spending his time writing the PRD, then it is unlikely that he or she is doing the actual product discovery work.
Recommended pattern: just follow the agile manifest, product in the hands of customers brings more value to customers and the company than comprehensive and detailed documentation.
It happens when the head of product and other leaders only make decisions if there is an abundance of data, reports, charts. There are two dangers with this anti-pattern:
Recommended standard: make decisions based on data, but always understanding that the data is incomplete, and always take into account qualitative information, previous experience, and intuition.
Every company has legacy systems. Even a startup that was just created, in a few months will be able to look at its code base as a legacy and something that needs to be improved. At that moment we start to hear phrases like:
And at that moment, the great solution of rewriting was born. And this major rewrite will, at some point, cause a product evolution freeze. Why write something for the legacy, if the new system will replace it? And there is also migration or transition. How will we go from the legacy system to the new one?
Normally, in the initial estimates, the rewriting will take about 2 or 3 months and when we move forward we realize that it will be a little longer, and may take years. At Locaweb we made the decision to rewrite the central system that managed customer data and collection. The original project was forecast to take 9 months and ended up taking more than two years. In addition, when the new system came in, our customer billing did not work for about 2 months and stayed for another 6 months running incorrectly until we finished all the necessary adjustments. That is, the rewriting that originally would take 9 months ended up taking 3 years.
Recommended pattern: avoid major rewrites at all costs. Most of the time, there will be ways to replace the legacy system gradually and progressively, without causing disruption to the company and customers.
When a new head of product joins a new company, it is common during the onboarding process, during the numerous conversations with people from various areas of the company, to hear a series of requests and complaints regarding the product that this new head will take care. To “score points” with these people, who will eventually give feedback on the head of product’s work, he may be tempted to build his list of what to do based on these reported requests and problems. It is the company’s “wish list”. Then, this product head will prioritize this list or even outsource this prioritization to a leader in the company’s sales or business area. I’ve seen situations where the product head collects the “wish list” and presents it at a meeting with leaders from various areas of the company and says “now I need you to prioritize what you want the product development team to do first “.
Although it is somewhat tempting because the “wish list” will actually help the head of product to score points with the leaders of other areas, this behavior will make the product development team become a mere order taker and feature factory, inhibiting the innovation potential that this team can bring to the business. When the head of product focuses the team on delivering the “wish list”, it ends up focusing the team on being an implementer of solutions that are given by other people, taking the team’s focus on the problems to be solved. It is the difference between the team that implements solutions that are already envisioned by other areas of the company versus a team focused on deeply understanding the company problems and then finding the best solutions to solve these problems. I’ll talk more about this in the part about principles.
Recommended standard: product development team works to understand problems and then evaluate possible solutions. So go find the list of problems to work on, not the list of things that other areas want the product development team to do.
With this chapter, we finish part 1 on the Concepts needed to understand the roles and responsibilities of a product head. In the next part, we will see which Principles should guide the work of a head of product and his team.
So, did you miss something in this chapter? What else would you like me to cover?
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? While you wait for my new book, check out my Digital Product Management bundle with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.