[미디엄 번역] Product Management에 대한 오래된, 좋지 않은 접근법 #2

이전 글 참고해주세요.
#2로 이어서 작성합니다.

 

이 접근법의 문제는?

위에서 설명한 접근법이 비효율적으로 여겨지는 수많은 이유가 있습니다. 이 접근법은 수많은 능력있는 프로덕트 팀들이 어떻게 일하는지 IT프로덕트는 어떻게 생산되는지를 설명하는 것이 아닙니다. 어떤 프로덕트의 성공이든 프로덕트 팀이 얼마나 효율적인지, 고위 경영진들이 얼마나 팀과 협업하는지에 달려있습니다. 위에서 말한 접근법은 이상적인 목표와는 정 반대입니다. 그 이유를 알아보겠습니다. 위에서 캐스캐이딩 주문에 따른 프로세스를 언급했기 때문에 단계별로 개별 프로세스의 문제들을 해결해나갈 것입니다. 그전에 위에서 논의한 모델이 폭포수(Waterfall)라 불리는 프레임워크와 상당히 닮았다는 것을 유의하세요. 비록 조직이 애자일 원칙을 따른다고 주장하더라도, 애자일의 개념은 앤지니어링 팀이 프로덕트 또는 그 기능을 개발하는 단계인 딜리버리 단계에서만 사용됩니다. 그러나 기업은 폭포수(Waterfall) 방법에서 운영됩니다. 매 단계는 서로 연관돼있으며 프로덕트 팀은 고위 경영진에 매우 의존합니다. 고위경영진은 무엇을 빌드해야하는지와 어떻게 빌드해야하는지를 결정했다고 합니다. 프로덕트 팀은 아이디어와 요구들을 구현하는 것을 의미하는 비즈니스를 지원하고자 존재합니다.

 

Ideation의 문제점

Ideation 단계에서 고객의 기능요청은 프로덕트 팀이 무조건 따라야만 한다는 것을 의미할까? 만약 인스타그램이 사람들이 요구하는 모든 기능들이 구현돼있다면 어떨지 상상해봐라. 첫번 째로 만약 모든 것이 구현된다면 고객의 고통을 해결해주기 보다는 혼돈을 만들어낼 것이다. 무엇을 왜 하는 것인지 고려해보는 것은 매우 중요하다. 이미 이 글의 시작 부분에서 말했듯이 모든 것은 이유가 있기 때문에 일어난다. 기능을 추가하거나 제품을 처음부터 구현해내는 것은 투자하는 시간과 연구가 필수적이다. 자신감있게 밀고나가는 것 뿐만 아니라 고객의 요청을 만족시켜야 한다는 것을 의미한다.
게다가 이건 C레벨 기업들에 의해서만 정해지는 것이 아니다. C레벨의 기업이 시장, 산업, 비즈니스, 고객들에 대해 꽤나 잘 이해하고 있다고 가정해보자. 그들 중 대부분은 데이터 중심적이고 지속적으로 시장의 트렌드와 고객들에 대해 학습한다. 아주 대단하다. 그러나 경험에 따르면 대부분 가장 성공한 아이디어들은 기업의 CEO로부터 오지 않는다. CEO는 비즈니스의 다양한 측면에 대한 이해가 가장 높은 사람들일 뿐이다. CEO들의 바쁜 일정을 고려해보면 대부분의 CEO들은 프로덕트에 대한 전략적인 결정을 내릴 수 있는 충분한 정보와 인사이트를 가지고 있지 않은게 당연하다. CEO의 역할은 모든 시간을 헌신하는 것이고 프로덕트 매니저 또한 그렇다.
고객과 시장의 니즈를 충분히 이해하는 것은 풀타임 job과 같다. 엄청나게 빡센 일정을 소화하고 있는 CEO가 모든 디테일들을 배우기 위해 시간을 낼 수 있을 것 같냐? 불행히도 아니다. 경영진들은 대개 큰 그림을 매우 잘 이해하고 많은 경우 비즈니스가 직면하고 있는 문제에 대해 명확하게 이해하고 있다. 문제들에 대해 커뮤니케이션 할 수 있지만 대개 문제에 대해 가장 효과적인 솔루션을 제안하기 위한 배경지식이 충분하진 않다. 
많은 경우 CEO는 직원들에게 직감을 믿으라고 합니다. CEO가 하는 말들은 주로 "나를 믿어봐. 이 일은 해결될거야" 입니다. 그런데 이걸 CEO는 어떻게 알 수 있을까요? 증거, 통계, 예측이라도 있는걸까요? 불행히도 많은 경우 CEO들은 데이터기반 의사결정보다는 전략, 이행, 판매, 마케팅에 시간을 할애하느라 매우 바쁘다. 그러니 프로덕트 결정은 프로덕트 팀들에게 넘기는게 더 나을 것이다.

 

우리는 가장 어려운 프로덕트 문제를 해결하고 명확한 가치를 고객과 비즈니스에 가져올 프로덕트를 만들어내기 위해 "똑똑"하고 "창의"적인 프로덕트 매니저들과 프로덕트 디자이너들을 고용합니다. 그러니 그들이 일을 잘 해내도록 하는 것이 중요합니다.

 

비즈니스 분석 단계의 문제점

비즈니스 분석 단계에는 많은 문제점들이 있다. 가장 큰 문제는 "No"라는 답이 없다는 것이다. 많은 회사들은 고객으로 부터 온 요청은 어떤 것이든지 그냥 받아드린다. 비즈니스 단계에서 주로 하는 것은 아이디어의 우선순위를 매기는 것이다. 우선순위화는 중요한 목표인데 주요 고위 경영진들이 가장 먼저 해결하고 싶어하는 아이디어들을 가장 상단에 두어야하는 것이다. 기본적으로 프로덕트 팀들이 비즈니스에서 가장 중요시 생각하는 아이디어들이 진행되어야한다. 회사는 아이디어들의 잠재성, 구현해야하는 리소스들과 같은 몇몇의 요소들을 고려하며 계획의 중요도를 평가해야한다.
그런데 이 단계에서 자신있게 아이디어의 잠재성을 평가할 수 있나? 더 중요한 것은 어떻게 우리가 이러한 아이디어들이 성공적일지 아닐지 확신할 수 있냐는 것이다. 그 증거는? 비즈니스 미팅에서 선보였던 이 아이디어들이 실제로 성공적이고 큰 수익을 가져올 것이라는 것을 뒷받침하는 요인들은 무엇인가? 불운하게도 우리는 이 단계에서 아이디어가 유망할지 아닐지 타당한 증거 없이는 확신할 수 없다는 것이다. 몇몇 고위 경영진들에게는 유망하게 들릴진 몰라도 전체 시장에서도 가치있을 것이라고 확신할 수 없다. 이것이 프로덕트의 추한 민낯 중 하나다.
또한 비즈니스는 고객으로부터 온 모든 아이디어들을 구현하려고 하기에 리소스의 부족함을 느끼게 될 것이다. 우리 앞에 놓여진 모든 아이디어들이 구현된다고 상상해봐라.
대부분 우리는 우리 앞에 랜덤으로 놓여진 아이디어들을 실현시키기 보다는 더 적은 더 적은 리소스들을 가질 것이다. 이는 실력이 보장된 팀원들이 지속적으로 필요하다는 버블을 만들어낼 것이다. 그리고 이는 많은 경우 조직이 직면한 문제의 원인이다. 조직은 그들이 효율적인 프로덕트 개발을 위해 실제로 필요한 것보다 더 많은 리소스들을 가진다. 이는 조직 자원의 비효율적인 활동의 또다른 원인이기도 하다.
데드라인은 종종 파트너의 요청과 시장의 과한 경쟁으로부터 정해진다. 그러나 실제로는 데드라인은 불쾌하고 때때로 프로덕트 팀의 평가없이 정해지기도 한다. 엔지니어들은 기능들을 구현해내는 사람들이고 불행히도 이게 미팅에서는 티나지 않는다. 엔지니어들은 비즈니스와 데드라인으로부터 요구사항을 받는다. 결정을 내리기 전까지는 엔지니어들의 의견들을 들을 수 없기 때문에 타당하지 않게 들릴 수도 있다. 미팅에서 엔지니어 CTO나 VP의 존재는 부족하다. 그들이 회사의 높은 수준의 기술적 인프라를 이해하고 있는 사람들이지만 많은 경우 개발 과정의 평가를 바로잡을 수 있을만큼 정보에 빠르지도 않다. 
우리는 로드맵에 따라 전통적인 결과물에서 무엇이 잘못됐는지 말할 수 있지만 이러한 접근법은 상당히 문제가 많다고 얘기하고 싶다. 우리는 결과물을 프로덕트의 최종 결과라고 생각하는 경향이 있다. 그래서 로드맵들은 주로 기능이 구현된 후의 프로덕트의 최종 결과를 설명한다. 이러한 로드맵들은 기능만 요구대로 제시간에 구현되면 비즈니스는 만족스러울 것이라는 환상을 만들어낸다. 이는 데드라인이 끝나기 전의 프로덕트나 기능을 구현하는 것이 성공이라는 생각으로 이어진다. 그러나 구현됐지만 절대 고객들은 사용할 수 없다면 무슨 일이 일어날까? 또는 수입을 전혀 벌어들일 수 없다면? 이게 성공이라고 할 수 있을까? 그 답은 아니다. 이 방법은 많은 리소스들, 에너지, 고객들에게 유용하지 않은 어떤 것을 만들어내는 기회비용이 사용된다.
충분한 증거없이 우리가 만들고자하는 솔루션이 고객들에게 잘 먹힐 것이라고 생각하지 못한다. 그렇다면 우리는 어떻게 고객으로부터 증거를 얻을 수 있을까? 고객들을 위한 무언가를 3개월만에 만들 수 있는 간단한 프로토타입 없이 만들어 내는 것을 상상해봐라. 그리고 솔루션을 이행했는데 이것이 문제를 해결해줄 수 없다고 상상해봐라. 다시 조직적 리소스를 엄청나게 낭비하는 것이다.

문서화 단계의 문제점

프로덕트 팀들이 무엇을 구현해야할지 강제하는 것은 많은 리스크가 수반한다. 프로덕트 팀들은 그들만의 매력과 가치를 잃는 리스크를 겪을 것이다. 그들의 수 많은 똑똑한 생각들을 빌리더라도 그들의 의견은 묻지 않을 것이다. 이러한 시나리오에서 프로덕트 매니저는 백로그를 우선순위화하고 문서를 작성하고 프로덕트 디자이너는 (커뮤니케이션이나 브레인스토밍에 많은 노력이 들어가지않은)제공받은 문서에 따라 디자인을 만들어낸다. 그리고 소프트웨어 엔지니어들은 코드를 작성하고 프로덕트를 만들어내 세상에 알린다. 이게 프로덕트 팀들이 하는 일이다.
그러나 대단한 프로덕트 회사들의 프로덕트 팀은 세상에 선보이는 것 외에도 프로덕트의 발견을 가장 중요하게 여긴다. 로드맵을 백로그에 맞게 분배하는 것은 프로덕트 매니저의 업무 중 아주 작은 부분일 뿐이다. 프로덕트 팀은 그들이 무엇을 만들어낼지, 누가 이것을 생각해냈는지, 왜 이것을 만들어야만 하는지 완전히 이해해야한다. 그렇지않으면 프로덕트 팀은 고객들 보다는 비즈니스를 이행하는 것에만 신경쓰는 그룹이 될 것이다.
우리는 이런 스타일의 회사에는 강력한 프로덕트 문화가 있을 수 없다고 자신있게 말할 수 있다. 프로덕트 오너와 프로덕트 매니저라고 불리우는 사람들은 본질적으로 비즈니스와 고객들로 부터 제공받은 요구사항을 리스트화하는 백로그 매니저들이다. 또한 그들은 인수 기준(acceptance criteria)을 구체화하고 프로덕트나 기능을 제시간에 빌드할 수 있도록 해야한다. 이것이 회사에 프로덕트 매니저들이 필요한 이유인가? 이 경우에 우리는 프로젝트 매니저들이 필요한 것이고 그들은 이 모든 것들을 성공적으로 처리할 것이다.

 

디자인, 개발, 검증 단계에서의 문제점

디자인과 엔지니어링 업무의 조직화하는 것에는 많은 문제점이 있다. 다시말해 C레벨의 회사들은 디자인과 엔지니어링 팀 대표자 없이 프로덕트 결정을 내린다. 그러나 이러한 프로덕트 결정들은 사용자 경험과 프로덕트 설계에 영향을 미친다. 우리는 적어도 로드맵에 새로운 기능에 대해 업데이트하기 전까지 의견들을 들어야한다. 의견에 대한 어떠한 요구사항없이 사람들이 상당한 수준의 디자인과 설계적인 변화들을 만들어내야한다면 얼마나 혼란스러울지 상상해봐라. 이런 것들은 직원들의 불만족과 높은 이직률의 원인이 될 수 있다.

대다수 중요하게도 프로덕트나 기능들이 계속해서 살거나 죽을 때 무슨 일이 일어날까? 이건 누구의 잘못일까?

 

프로덕트 매니저와 전체 프로덕트 팀이 프로덕트의 성공을 만들어낼 권리를 주지 않고서 프로덕트 성공에 대한 책임이 있다고 생각하는 것은 불공평해요.

 

비즈니스로 부터 온 프로덕트 팀들이 아이디어들을 구현하겠다는 이 접근법은 관리자가 잘못된 결정을 내렸단 이유로 책임을 묻게될 것이다. 현재 회사 내부에 일어나고 있는 것과 이러한 접근법이 비슷하다고 생각하면? 얘기해보자.

저자에 대해

Rafayel Mkrtchyan은 프로덕트 매니지먼트 어드바이저로 기업의 프로덕트 개발 및 구현하는 과정을 향상하는 것을 돕고 있습니다. 그는 팀에게 성공적인 프로덕트 전략과 지속적인 성장 모델을 정하는 방법 및 고객과 프로덕트 개발 과정, 개발 산출물, 검증, 데이터기반 마인드셋, 강력한 린, 애자일, 디자인사고방식을 이행하는 방법을 가르칩니다.

 

 

 

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 and sustainable growth model, run customer and product development processes, develop outcome-, experiment-, and data-driven mindset, as well as robust their lean, agile, and design thinking skills.