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

 

Product Management에 대한 오래된, 좋지 않은 접근법

 

소개

우리가 하는 모든 행위에는 이유가 있다. 이 글은 규모가 작은 스타트업부터 규모가 큰 기업의 다양한 IT업계에서 Product Manager로 일하며 보고 경험한 것을 공유하기 위해 작성합니다. Product Management를 마스터하기 위해 7년이나 걸렸습니다. Product Management를 마스터하는 것은 기업가 정신에 대한 책을 읽거나 온라인 강의를 듣는 것을 의미하지 않습니다.
전문성을 탐구하는 것은 쉽지 않습니다. 저는 많은 실패를 겪었고, 실패로부터 가장 중요한 배움을 얻었습니다. 스타트업 설립자와 프로덕트 매니저로의 실패는 IT 프로덕트를 개발할 때 무엇을 하지 말아야 하는지를 가르쳐주었습니다. 그 후에, 스타트업 설립자와 프로덕트 매니저로서 배운 귀중한 배움은 고객들이 소중하게 여기는 제품을 만드는데 무엇이 필수적인지 알려줬습니다.

프로덕트 매니저들은 때때로 실패합니다. 프로덕트가 세상에 나오기까지 한번도 실패한 적이 없는 프로덕트 매니저가 있을 것이라고 생각하는 것은 근거없는 소리입니다. 그러나, 그 실패가 얼마나 귀중한 것인지 알아보는 것은 매우 중요합니다. 혁신적이고 혁명적인 아이디어는 고객들이 신경써야할 부분이 아니라는 것을 깨닫기 전까지 기업과 프로덕트 팀이 얼마나 많은 노력, 에너지, 조직비용을 쏟아부었을까요? 불행히도 현재 프로덕트를 빌드하기 위해 가장 비용이 많이드는 방법을 선택하고있는 많은 IT비즈니스가 있습니다. 그리고 실패를 하면 엄청난 비용을 지불해야합니다.
저는 이 비정상을 알아차린 첫번 째 사람은 아닙니다. 많은 사람들은 기업이 제품 또는 기능이 성공할지 못할지를 깨닫기 전에 높은 비용의 과정을 겪는다고 말합니다. 그러나 대다수의 IT기업들이 여전히 제품을 개발하는데 전통적이고 오래된 접근법을 따르고 있다는 것을 알면 놀랄 것입니다. 따라서 지속적인 혁신과 이행의 부족으로 시장에서 경쟁력을 잃고 있습니다. 실패의 주요 원인과 프로덕트 실패를 교훈으로 바꾸는 방법이 무엇인지 이해하고 분석하는 것이 필수적입니다.

 

내 이야기

저는 13살 때부터 코딩을 해왔고 16살 때부터 프로덕트 팀과 함께 일하기 시작했습니다. 저는 항상 프로덕트 매니저로서 가장 큰 장점 중 하나는 전 세계에 걸쳐 많은 프로덕트 팀들과 협업할 수 있는 특권을 갖고 있는 것이라고 말해왔습니다. 이 특권은 전 세계 프로덕트 팀의 문화와 정신에 대한 다양한 인사이트를 모을 수 있게해줍니다. 그리고 제 이목을 끌었던 가장 흥미로운 점은 함께 일할 기회가 있던 최고의 프로덕트 팀이 유저를 성공적으로 유치하는 프로덕트를 만들 때 효율적인 업무 패턴을 가지고 있었다는 사실입니다. 반면 시장규모를 보면 "평범한 위치"에 있던 또는 혁신하기에는 이미 능력이 없던 기업들은 오래되고 비효율적인 접근법을 사용해 프로덕트를 개발하고 있었습니다.

20대 초반 몇몇의 실리콘 밸리 출신 기업들과 일한 후 Armenia의 테크수준이 어떤지 확인하기 위해 Armenia로 다시 돌아가기로 결정했습니다. 이전에 저는 아르메니아 IT 기업들과 일할 기회가 전혀 없었습니다. 이건 제가 Armenia의 유니크한 IT문화를 경험할 수 있는 중요한 기회였습니다. 그래서 Armenia의 가장 큰 프로덕트 기업 중 하나인 곳에서 함께하자는 제안을 받아드렸습니다. 이게 제 인생을 바꾼 순간이었고 지금 이 글을 쓰기로 결정한 이유이기도 합니다. 이 기업에서는 많은 것들이 제가 이전에 경험하고 봐왔던 것과는 매우 다르게 적용됐습니다. 저는 이 기업에서 잘못된 것들을 바로 파악할 수 있었지만 이 기업의 역동성을 향상시키기 위한 기회는 거의 없었습니다. 

접근법

제가 다니던 기업은 리퀘스트나 CEO중심의 비즈니스였습니다. 그 이유는 부족한 프로덕트 문화 때문입니다. 거의 모든 아이디어, 기능 요청, 프로덕트 변화의 90%는 고객 또는 CEO로 부터 바로 온다고 상상해보세요. 아마 "이게 뭔 문제예요?"라고 묻겠죠? 답은 간단합니다. 기업이 프로덕트 성공에 대한 책임지는 역할을 하고 있다고 해도 그 역할을 쥐고 있는 직원들 중 아무도 프로덕트 작업을 성공으로 이끄는 일을 할 수 없습니다. 전체 과정을 더 자세히 봐봅시다.

Ideation

모든 것은 Ideation 과정으로부터 시작됩니다. 이 용어들은 어떤 기업에서 구체적으로 사용되는 것이 아니란 걸 유념하세요. 이 용어들을 프로덕트를 발견, 이행하고 조직적 업무의 전반적인 플로우를 진행하는데 필요한 캐스캐이딩 프로세스를 설명하기 위해 소개하겠습니다.

Cascading Process 예시

제가 이전에 언급했던 것과 같이 대부분의 아이디어들은 기업의 CEO로부터 오거나 매일같이 공격적으로 새로운 기능들을 요청하는 B2B 고객사들로부터 옵니다. 그리고 아무리 그 기업이 유망하다 하더라도 기업의 목표는 이러한 아이디어들을 이행하는 것입니다. 이 과정의 마지막 결과는 CEO와 고객사들로부터 모든 요구사항과 기능 요청사항들을 모으는 것입니다.

 

비즈니스 분석

비즈니스 분석으로 부르고 싶은 다음 스텝은 소위 프로젝트 매니저라고 불리는 사람들과 밋업하고 고객들과 CEO가 요구한 프로덕트를 빌드하거나 기능을 구현하는데 무엇을 감수해야하는지에 대해 토론할 CEO와 C레벨 경영진들에 의해 이뤄집니다. 미팅들은 주로 매주, 몇 시간동안 진행됩니다. 주로 프로덕트 및 기능을 구현하는데 필요한 리소스들을 우선순위화 하기위한 대화들로 이뤄집니다. 이러한 미팅들의 목표는 추후 Jira와 같은 업무관리플랫폼에 투입할 결과기반 로드맵을 만들어내는 것입니다.
결과기반 로드맵 이면에 있는 아이디어는 기능이 구현되어야한다는 것입니다. 팀의 성공은 기능 구현입니다. 이보다 더 필요한 것은 없습니다. 예를들어, 만약 고객이 Skrill 결제방식을 구현하라고 요청했다면 그 요구는 로드맵에 포함될 것입니다. 그 다음 데드라인이 정해지고 성공여부는 데드라인에 맞춰 기능이 제대로 구현됐는지에 의해 정해질 것입니다. 그것이 다입니다.

 

문서화

일단 모든게 셋업되고 결정되면 업무는 프로덕트 오너에게 전해진다. 명심해라. 만약 기업이 프로덕트 오너라는 용어를 프로덕트 매니저들의 역할을 설명하기위해 사용하고 있다면 이미 문제가 있는거다. 많은 사람들이 애자일과 그에 해당하는 방법론 및 프레임워크로 인해 생긴 오해 때문에 사람들은 프로덕트 매니저 역할을 (프로덕트 오너의 경우) 프로덕트 구현을 이끄는 사람이라고 개념화하고있다. 저를 오해하진 마시구요. 프로덕트 딜리버리는 프로덕트 매니저의 책임들 중 하나다. 그러나 그 책임은 고작 30% 정도고 그 이상은 아니다. 그리고 만약 기업이 프로덕트 딜리버리 과정을 이행하기 위해서만 프로덕트 매니저를 필요로 한다면 그건 진짜 프로덕트 매니저들이 아니다. 그리고 그 기업은 실제 프로덕트 문화를 갖고있다고 할 수 없다. 본질적으로 그들은 프로젝트 매니저들인데 그들은 시간제약 및 비즈니스 요구사항을 염두에 두고 전달 과정을 주도한다.

기업은 프로덕트 매니저들을 프로덕트 로드맵을 기반으로 문서화하고 프로덕트 딜리버리 과정을 이끄는 사람으로 여긴다. 여기에는 근본적으로 문서화라고 불리는 3번째 과정이 필수다. 기업의 프로덕트 오너는 기업 수준에 맞게 정한 로드맵을 따라 문서화해야한다. 예를들어 만약 지불방식을 지원하는 Skrill의 구현이 로드맵의 한 부분이라면 프로덕트 오너는 새로운 기능과 유저 스토리*와 허용기준을 작성해야한다. 이 과정의 최종 목표는 다른 프로덕트 팀 멤버들이 개발 과정에서 따를 수 있는 다소 정리된 요구사항 리스트를 완성시키는 것이다.  


*유저스토리에 대한 설명
https://engineering.linecorp.com/ko/blog/user-story-point-in-line-pay-team/

사용자 스토리 포인트로 스마트하게 프로젝트 진행하기(feat. LINE Pay 개발 팀) - LINE ENGINEERING

 

디자인

문서화 작업이 끝나면 프로덕트 오너는 업무를 프로덕트를 만들고 기능을 디자인하는 프로덕트 디자이너에게 넘겨야한다. 우리는 이 과정을 디자인 프로세스라고 부른다. 이 과정에서 프로덕트 디자이너는 주어진 문서를 보고 아직 "알수없는 소스들"과 "알수없는 이유들"로 쓰여진 요구사항에 따라 인터렉션&비쥬얼 디자인을 만들어낸다. 많은 경우 프로덕트 디자이너들은 완전히 다른 부서에 앉아 프로덕트 오너와 엔지니어들과 멀리 떨어져있는다. 디자이너들의 커뮤니케이션은 대개 유저 스토리와 슬랙을 통해 이뤄진다. 이 과정의 최종 목표는 엔지니어들에게 필수적인 디자인 목업을 제공해서 엔지니어들이 개발을 시작할 수 있도록 하는 것이다.

 

개발

디자인 목업이 준비되자마자 엔지니어들은 개발을 진행할 것입니다. 엔지니어들은 목업과 문서를 숙지하고 보통은 Scrumban이라 불리우는 것 사이에서 스크럼, Kanban과 같은 몇몇 애자일 방법론에 따라 구축작업을 시작합니다. 때때로 딜리버리 과정은 몇 개월이 걸리기도 합니다. 가치 또는 사용성 테스트 없이 일관된 구축작업을 몇개월 동안 진행하기도 합니다. 그리고 종종 이행 데드라인이 엄격하기 때문에 팀은 데드라인을 맞추기위해 기능을 구축해야하기도 합니다. 이 과정의 최종목표는 전달할 수 있는 프로덕트를 제공하는 것입니다. 

 

검증

검증 프로세스라고 불리는 최종 단계에서 높은 수준의 검증 엔지니어들은 소프트웨어를 시장에 내보내기 전에 검증프로세스에 참여합니다. 피드백에 따라 프로덕트 팀은 프로덕트를 시장에 선보일 수 있는지를 결정합니다. 많은 경우 높은 수준의 검증 엔지니어들은 프로덕트 팀과 멀리 떨어져앉아있기 때문에 커뮤니케이션 프로세스가 매우 혼란스럽습니다. 이 프로세스의 최종 목표는 당연히 최소한의 퀄리티 요구사항이 충족된 프로덕트입니다. 일단 팀이 이 단계에 도달하면 프로덕트나 기능들은 시장에 전달됩니다.

아시겠지만 기능의 단순한 구현은 팀과 프로덕트의 성공을 의미합니다. 성공은 새로운 기능을 만들어내거나 최소기능제품(MVP)을 빌드하는 것을 의미합니다. 저는 이것이 놀랍습니다. 회사가 프로덕트에 들이는 노력의 80%는 완전히 실패합니다. 많은 경우 의미있는 고객문제를 해결하지 못합니다. 회사는 프로덕트 개발 비용의 대다수를 결국 실패할 것에 쏟으며 낭비합니다. 그리고 이 전략은 비즈니스를 운영하는데 비용이 매우 많이듭니다. 
원래 실리콘밸리와 멀리 떨어진 기업 즉 프로덕트 개발 전략을 경험할 기회가 없었던 기업들만의 특징인 줄 알았습니다. 그러나 20대 중반 실리콘밸리에 돌아와 수많은 실리콘밸리 회사들 또한 이런 방식을 하고 있는 것을 보고 너무나 놀랐습니다. 즉 이 방법은 지역적이거나 문화적인 것이 아니라는 것입니다. 도메인이나 기술에따른 어떤 것도 아니란 말입니다. 이 방법은 현재 많은 기업들이 프로덕트를 빌드하는 더욱 효과적인 방법을 알지못해 일어난 결과일 뿐입니다.

The Old, Bad Approach In Product Management

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 Design process. 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.

 

 

출처: Medium Product Manger 키워드 Best의 제일 상단에 있던 글

https://uxplanet.org/the-old-bad-approach-in-product-management-e1d11a19b4bc

The Old, Bad Approach In Product Management

 

글이 길어 #1, #2로 나눴습니다.

나머지 내용은 #2로 작성하도록 하겠습니다.