As An Introduction

We all do something for a reason. I have decided to write this article to share what I have seen and experienced while being a product person for various technology companies, from small startups to large enterprises. It took me seven consecutive years to master the art of product management. Mastering product management was not something I learned from reading books or watching online courses about entrepreneurial discipline.

My quest to mastery was not easy. I have encountered many failures, and from them, I have learned the most prominent lessons. My failures as a startup founder and product manager have allowed me to understand what we should NOT do when developing technology products. Thereafter, the valuable lessons I learned as a product manager and a startup founder helped me discover what’s necessary to create products that customers value.

Product people fail sometimes. It is a myth to assume there are product managers who have never failed in their product journey. However, it is crucial to measure how expensive was their failure. How much effort, energy, and organizational costs did the company and its product team invest before they realized that their “innovative” and “revolutionary” idea is not something that their customers care about? Unfortunately, nowadays there are many technology businesses that are still choosing the most costly ways to build their products, and after each failure, they have a huge price to pay.

I am not the first person who has noticed this anomaly. Many people have addressed that companies take expensive journeys before realizing whether or not their product or feature will succeed. However, you might find it surprising that a majority of technology companies nowadays are still following the traditional and old-fashioned approach of product development; hence, losing their competitiveness in the market due to the lack of consistent innovation and execution. It is essential to analyze and comprehend what the primary causes of their failure were, and how to turn the concept of product failures into product lessons.

My Story

I have been coding since I was thirteen years old and I started working with product teams since I was sixteen. I always state that one of my biggest advantages as a product manager is that I had the privilege to work and interact with many product teams across the globe. This allowed me to gather various insights about their product culture and discipline. And the most interesting thing that caught my attention was the fact that the best product teams I have had a chance to work with had very efficient work patterns when creating successful products for their customers. While companies that are in the “mediocre positions” in terms of market acquisition sizes or the ones that have already lost their capabilities to innovate are developing their products using old-fashioned and cost-ineffective approaches.

After working for a couple of Silicon Valley-based companies in my early 20s, I decided to move back to Armenia to see what the tech landscape looked like there. Previously, I never had an opportunity to work with Armenian technology companies — this was a pivotal experience that allowed me to explore Armenia’s unique technology culture. So, I got an offer to join one of the biggest product companies in Armenia, and I accepted it. This was a life-changing experience and also one of the many reasons why I decided to write this article. Many things in this company worked differently from what I have seen and experienced earlier. I could identify the wrong things in the company right away, but I had little opportunity to improve the company’s dynamics.

The Approach

The company I was working for, I would call it a request or a CEO-centric business. The reason is that there was a weak product culture there. What does this even mean? Imagine, nearly 90% of all ideas, feature requests, product changes come directly from the customers or the CEO himself. You may ask, “What is wrong with that?” The answer is simple. Even though the company had a role that was responsible for the success of its products, none of the employees who were holding that role were able to control the success of their product efforts. Let’s look at the whole process in greater detail.

Ideation

Everything started from the Ideation process. Note that, those terms were not specifically used in that company; I have introduced them to describe the cascading process of product discovery and delivery, and the general flow of the organizational work. As I have already mentioned, most of the ideas were either from the CEO of the company or from the B2B customers, who were aggressively requesting new functionalities day after day. And the company’s goal was to implement all those ideas, no matter how promising they were. The end result of this stage was to gather all the requirements and feature requests from the CEO and the customers.

Business Analysis

The next step that I like to call Business Analysis involves the CEO and C-level executives, who would gather a meetup of so-called project managers and discuss with them what it takes to implement those features or build a product that customers or the CEO had asked for. Meetings usually happen on a weekly basis and would last for a couple of hours and would usually involve conversations about prioritization and the resources that should be allocated for the implementation of the requested feature or the product. The aim of these meetings was to create an output-based roadmap, which later on would be put into a task management platform such as Jira.

The idea behind the concept of output-based roadmaps was this — there is a feature, and this feature should be implemented. The success of the team is the implementation of the feature. Nothing more than that. For example, if the customer requested to have the Skrill payment method to be implemented, that request would be put into a roadmap. Then a deadline would be set, and the definition of success would be actually implementing that feature by the deadline. That’s it.

Documentation

Once everything is set up and decided, the work would be passed on to the product owner. Note that, if the company is using the term product owner to describe the role of its product managers, then there is already something alerting there. Due to the misunderstanding that many people have from agile and its corresponding methodologies and frameworks, people conceptualize the role of a product manager (in their case as product owner) as someone who leads the execution of the product. Don’t get me wrong. Product delivery is one of the responsibilities of the product manager, but only 30% of their responsibilities — not more than that. And if the company needs product managers who are just there to lead the product delivery process, then they are not real product managers, and the company doesn’t have a real product culture. They are essentially project managers who are leading the delivery process having in mind the time constraints and the requirements from the business.

The company was viewing product managers as people who would document everything based on the product roadmap and would lead the product delivery process. Here essentially comes the third process, which we can call Documentation. The product owner in this company had to take the roadmap (already set up on a company level) and just document it. Hypothetically, if the implementation of Skrill as a supported payment method was part of the roadmap, the product owner would write down a user story about the new feature and its acceptance criteria. The end goal of this phase was to have a somewhat defined list of requirements that other product team members could follow during the development process.

Design

After the documentation phase, the product owner would pass the work to the product designer who would work on creating the product or feature design. We can call this process the Designprocess. In this step, the product designer would go through the given documentation and try to create the interaction and visual design based on the requirements coming from the “unknown sources” and for “unknown reasons.” Many times, product designers would sit in a totally different department, far away from the product owner and engineers and their only communication was mostly via user stories and Slack. The end goal of this phase was to provide engineers with necessary design mockups so that they could start the development.

Development

As soon as the design mockups were ready, engineers would start the Development process. They would then take the mockups and the documentation and start implementing them according to some agile methodology usually Scrum or Kanban or something in between called Scrumban. Sometimes the delivery process could take several months — several months of consistent implementation without value or usability testing. And since oftentimes the execution deadlines were pretty strict the team had to implement the feature just to meet the deadlines. The final goal of this phase was to provide a shippable product.

Testing

In the last step, which we can call the Testing process, the quality testing engineers will join the process to test the created software before shipping it to the market. Based on their feedback the product team would determine if the product is ready to be shipped or not. Since many times the quality testing engineers were sitting far away from the product team, this would make the communication process chaotic. The end goal of this process was to guarantee that the product meets the minimum quality requirements. Once the team reaches this step, the product or the feature gets shipped to the market.

As you have noticed, the mere implementation of a feature would thus define the team’s and product’s success. Success would be defined as releasing a new feature or building a minimum viable product (MVP). This was shocking. At least to me. Over 80% of the product efforts of this company became complete failures, as many times they were not solving meaningful customer problems. The company was basically wasting most of its product development budget on things that were eventually failing. And this was a very expensive strategy to run a business.

Originally, I was thinking that this was something peculiar to companies that were far from Silicon Valley — companies that haven’t had a chance to experience better product development tactics. However, after returning to Silicon Valley in my mid-twenties, I was even more shocked to see that this was something that a lot of Silicon Valley companies do as well. So, this was not something regional or cultural. This was not something domain-specific or technology-specific. This was just the consequence of the fact that many companies nowadays are not aware of more efficient ways of building their products.

What’s Wrong With This Approach?

There are many reasons why the approach I have discussed above is considered non-efficient. This is not how great product teams work and create technology products. The success of any product hugely depends on how your product team works and how the top management collaborates with that team. The approach discussed above is the opposite of the ideal goal, and we are going to see why. Since I have discussed the process above in cascading order, we will go through the problems of each process step by step.

Before that, note that the model we have discussed above significantly resembles the framework called Waterfall. Even though the organization claimed that they follow the principles of agile, the ideology of agile was only used in the delivery part — when the engineering team was developing the product or the feature. However, the company itself was functioning in a Waterfall manner. Each step was dependent on one another, and the product team was hugely dependent on top management. We say that top management was deciding not only what to build, but also how to build it. The product team was there to serve the business, meaning that they were there to implement their ideas and needs.

Problems in Ideation

In the Ideation stage, when the customer makes feature requests, does it mean the product team should always follow them blindly? Imagine if Instagram implemented all the features people are asking for. First things first, if you implement everything, you are going to create chaos instead of curing the customer pain. It is critical to consider why you are doing something. As I have already said at the beginning of this article, we all do something for some reason. Adding a feature or building a product from scratch should take time and research. It’s not only about gut feeling or satisfying customer requests.

Moreover, it’s not something to be decided by the C-level guys only. We assume that the C-level person has a pretty good understanding of the market, industry, business, and their customers. Many of them can also be data-driven and continuously learn about their customers and the trends in the market. That is fantastic. However, the experience demonstrates that most of the time the most successful ideas are not coming from the CEO of the company. We trust the CEO as the one who has a great understanding of various aspects of the business. However, taking into account their busy schedule we can guarantee that most of the time they don’t have enough information and insights to make tactical decisions about their products.

The role of a CEO takes a full-time commitment, and the role of a product manager is also full-time. Understanding the customers and the market needs well enough is like a full-time job. Can we expect the CEO with a super heavy schedule to have time to learn about all those details to make decisions about the products? Unfortunately, no. Executives usually understand the big picture very well, and many times they have a clear understanding of the problems their business faces. They can communicate about the issues, but most of the time they don’t have enough background knowledge to suggest the most effective solutions to those problems.

Many times, a CEO asks their people to believe in their gut feeling — “Trust me; this is going to work” is what they say. But how do they know this? Do they have the evidence, the numbers, the predictions? Unfortunately, a lot of the time, CEOs are busy with strategy, operations, sales, and marketing rather than data-driven decision-making. So maybe it’s better to leave product decisions to product teams?

We hire those “smart” and “creative” product managers, engineers, and product designers to tackle the hardest product challenges and create products that bring tangible value to the customers and the business, so let’s allow them to do their job.

Problems in Business Analysis

I can see a lot of problems in the Business Analysis phase, too. The biggest problem here is that there was no answer “No” (pun intended). Many companies merely accept any request that comes from the customer’s side. Thus, the main thing they do at the Business Analysis phase is prioritization of the ideas, i.e., which one to do after what. And the prioritization has one major goal — to put the ideas the top management wants to have first at the top, basically to ensure that the product teams are working on the idea that the business deems most important. And the company evaluates the importance of a plan based on several factors such as the potential of the idea, and the resources that are needed to implement it.

But can we confidently evaluate the potential of an idea at that stage? More importantly, how can we be so sure if those ideas are going to work? What’s our evidence? What are the supporting factors that give us the confidence that the ideas presented in those business meetings are going to actually work and return high revenue? Well, the unfortunate reality is that at that stage, without having reasonable evidence, we can never say the idea is promising or not. It might sound promising to one or a couple of executives, but we can’t indeed conclude that it will be valuable for the entire market. This is one of the ugly truths about products.

Additionally, as the business is trying to implement all those ideas coming from all of their customers, there might be a feeling of a shortage of resources. Imagine that we try to implement all the ideas presented to us. Most of the time, we will have fewer resources than we actually need to implement the ideas that are randomly thrown at us. This will create an artificial bubble for a constant need for qualified labor. And this is the root cause of the problem that many times organizations face — they have way more resources than they actually need for the efficient development of their products. Yet, another reason for the non-efficient utilization of organizational resources.

It is understandable that the deadlines often times come from the partnership requirements and the fierce competition in the market. However, the unpleasant reality about those deadlines is that sometimes they are being set without the estimates by the product teams. Engineers are the ones that implement these features, and unfortunately, are not present in these meetings. They receive the requirements from the business and the deadlines, which sound unfair because their opinions have never been heard before making those decisions. The presence of the CTO or VP of Engineering in those meetings is not enough. They are the people who are aware of the high-level technical infrastructure of the company but many times they are not up-to-date enough to make correct estimates about the development process.

We can talk a lot about what is wrong with traditional output-based roadmaps, but here I am just going to say that this approach has a significant flaw. We define the output as the final result of the product. So, those roadmaps are basically describing what’s the final result of the product after the feature gets implemented. Those roadmaps are creating the illusion that the business will be satisfied if the feature gets implemented as required and on time. This connects the concept of success to the proper implementation of the product or feature before the deadline. But what happens when it gets implemented but never actually used by the customers, or it never gets enough traction to raise the revenue based upon that? Do we consider this a success? And the answer is NO. This way you spend so many resources, energy, and most importantly an opportunity cost to build something that is not useful for the customers.

We can’t assume that the solution we are trying to build is actually going to work for the customer without having enough evidence. How do we gain that evidence? Of course, from the customer. Imagine building something for the customers without having them try the simple prototype of the feature that you are going to spend three months on building. Now imagine that you ship the solution and it doesn’t solve the problem you were trying to tackle. Again, a massive waste of organizational resources.

Problems in Documentation

Enforcing product teams on what to implement involves a lot of risks. The product teams this way undergo the risk of losing their charm and value. It turns out, you hire a lot of bright minds, but you never ask for their opinions, right? In such a scenario, the product manager is used just to prioritize the backlog and write the documentation, the product designer is used to create a design based on the documentation they are provided with (with not much communication or brainstorming), and the software engineers are used to writing lines of code and ship the product. Delivery. This is what product teams do here.

However, in great product companies, the product team is concerned not only with the delivery, but most importantly with the discovery of the product. Distributing the roadmap into the backlog is just a small portion of a product manager’s job. The product team should fully understand what they are building, who they are making it for, and why they are building it. Otherwise, the product team will merely be a group of people concerned with serving the business, rather than the customers.

We can confidently say that there is no strong product culture in those types of companies. So-called product owners and product managers were essentially backlog managers, who are there to list the requirements provided by the business or customers, specify the acceptance criteria and make sure that the product or feature gets built on time. Is this why we need product managers for our companies? If that’s the case, we just need project managers, and they will successfully take care of all that stuff.

Problems in Design, Development, and Testing

There are many problems with the organization of design and engineering work too. Again, the C-level people make product decisions without the presence of the design and engineering team representatives. However, those product decisions can truly affect both the user experience and the architecture of the product. We have to at least listen to their opinions before putting the new feature on the roadmap. Imagine how frustrated people will get once they learn that they have to make significant design and architectural changes without their opinions being asked. This can be a root cause of employee dissatisfaction and high turnover.

Most importantly, what happens when the product or feature goes live and fails? Whose fault is that?

It is unfair to expect the product manager and the entire product team to be accountable for the success of their product without empowering them to create the success of that product.

In this approach product teams basically implement the ideas coming from the business and then get blamed just because the management had made wrong decisions. Did you find this approach similar to what is happening inside your company right now? Let’s chat!

Feel free to comment below. If you enjoyed this list, please hit that clap button to help others find it.

About The Author

Rafayel Mkrtchyan is a product management advisor who helps companies improve their product discovery and delivery processes. He teaches teams how to set up a winning product strategy, run customer and product development processes, develop outcome- and data-driven mindset, as well as robust their lean, agile, and design thinking skills.

Follow him: Medium | Twitter | LinkedIn