(중요 포인트만 정리해서 적었습니다. 실제 웨비나를 들어보면 내용이 더 다채롭습니다.)
프로덕트 팀, 프로덕트 매니지먼트의 정의는?
프로덕트 팀과 프로덕트 매니지먼트의 정의는 회사마다 극적으로 다름. 특히 최고의 회사와 그렇지 않은 회사 사이에서 더욱 두드러짐.
프로덕트 팀에는 세 종류가 있음. 첫째, 딜리버리 팀(delivery team). 둘째, 피쳐 팀(feature team), 셋째, 프로덕트 팀(empowered product team).
딜리버리 팀에서는 애자일 매니저가 백로그를 관리하고, 프로덕트 디자이너나 프로덕트 매니저 없이 엔지니어로만 구성되어서 코드를 찍어냄. 안정적이지만 혁신은 전혀 일어날 수 없고, 좋은 회사라면 이런 형태로 일하지 않음.
피쳐 팀과 프로덕트 팀은 겉보기에는 매우 유사하지만 문화, 업무 방식, 직원 가치 평가에 근본적인 차이가 있음.
피쳐 팀은 경영진이 내려준 피쳐 및 프로덕트 개발 로드맵을 실행함. 피쳐 팀의 PM은 직책명과는 달리 실질적으로 프로젝트 매니저임. 로드맵을 외부에서 받았기 때문에 이런 팀은 비지니스 결과에 책임을 지지 않고, 팀의 업무 결과물인 피쳐가 비지니스 가치에 기여하지 않을 수도 있음.
프로덕트 팀은 개발할 피쳐가 아니라 해결할 문제를 받으며, 이를 고객을 만족시키는 동시에 사업적으로도 성공적인 방법으로 해결해야 함. 디자이너와 엔지니어가 수행할 역할도 크게 바뀌지만, 가장 크게 바뀌는 것은 PM의 역할임. 프로덕트 팀의 PM은 가치, 사업성, 사용성, 실현가능성의 네 가지 리스크 중 가치 리스크와 사업성 리스크에 대한 책임을 가지고 결과를 만들어내야함. 어떤 기능이 주어진 문제를 해결해주지 못했다면 문제를 해결할 때까지 다른 기능을 시도해봐야함. 인스파이어드는 이런 문제를 해결하기 위한 기법을 다룬 책이었음.
문제 영역과 솔루션 영역의 구분에 대해서?
문제 영역과 솔루션 영역을 구분하는 것은 옛 워터폴 방식의 잔재임. PM이 문제 영역을 담당하고 다른 직군이 솔루션 영역을 담당하는 방식은 90년대에나 하던 방식으로 결코 혁신이 나타날 수 없는 방식임. 뛰어난 제품은 실제 고객의 고통을 현재 실행 가능한 방식으로 해결해냄으로써 만들어지는만큼 고객의 문제와 사업적 문제를 동시에 고려하고 해결해야 함.
피쳐 팀에서 프로덕트 팀으로 전환하기 위한 가이드가 있는가? 어떻게 하면 CEO를 설득할 수 있는가?
피쳐 팀에서 프로덕트 팀 형태로 전환하는 가장 흔한 동기는 경영진의 두려움임. 예를 들어 아마존이 우리 회사의 시장이나 인접 시장으로 진입을 고려하고 있다고 하면 CEO가 큰 두려움을 느끼고 전환을 진지하게 고려하게 됨. 팀 형태의 전환은 기업 문화의 근본적인 변화를 포함하기 때문에 CEO의 뒷받침이 없으면 전환이 불가능하고, SVPG에서도 기업 컨설팅 전에 이 부분을 반드시 철저히 확인함. 경영진의 지원은 시작점에 불과함. 그것조차 없으면 반드시 실패하니 시도할 필요도 없음.
- 자신의 직무를 잘 알고 팀을 조직할 수 있는 프로덕트 리더가 회사에 필요함. 채용이 최선이지만 어려움.대안으로 경영진 코칭을 통해 어떤 일이 일어날지, 무슨 일을 해야할지 가르칠 수 있음. 이 단계에서 CEO가 진심으로 회사를 바꾸고 싶은지 알 수 있는데, 이는 근본적인 정치적, 권력적 변화를 의미하기 때문임. 피쳐 팀은 경영진에 종속되지만, 프로덕트 팀은 경영진과 파트너로써 협업함. 이는 정치적 변화고, CEO의 지원이 없으면 실현할 수 없음.
- 새로운 책임에 관해 팀을 교육함. 엔지니어와 디자이너의 경우 어렵지 않은데, 이들의 원래 업무 방식이기 때문임. 하지만 프로덕트 쪽 사람의 경우, 이전에 비해 지식과 책임을 비롯해 더 많은 능력이 필요하기 때문에 새로운 업무 방식을 받아들일 능력이 없거나 의지가 없을 수 있음.
- 실제로 책임을 줌. 각 팀이 비지니스의 주체라는 것을 인지시킴.
새로운 방식이 잘 돌아가는지 어떻게 확인할 수 있는가?
결과물(output)이 아니라 결과(outcome)를 보면 됨. 프로덕트 팀에게 로드맵을 주는 대신 문제와 성공 지표를 주면 됨. 예를 들어 고객 이탈률이 심각하니 해결책을 찾아오라고 하면, 팀 내에서 논의한 뒤, 다음 분기에 이탈률을 5% 낮추겠다고 말하고, 이를 책임지고 실행할 것임.
프로덕트 팀이 자체적으로 해결할 수 없는 문제에 대해서도 책임을 져야하는가?
이탈률의 원인을 분석한 결과 프로덕트 팀 내의 인원이 직접 해결할 수 없고, 컨텐츠나 인프라 팀에서 해결해야한다는 분석이 나올 수도 있음. 그래도 프로덕트 팀이 책임을 져야함. 피쳐 팀이라면 우리 책임이 아니라고 눈돌릴 수 있지만 프로덕트 팀이라면 어떻게든 나서서 다른 팀과 협업해서 문제를 해결해야함. 어렵다고 느껴지는게 맞고, 그래서 이런 추가적인 책임을 원하지 않는 사람도 있다고 말한 것임.
프로덕트 팀의 구성 및 전체 조직 내 위치는 어떻게 되는가?
일반적으로는 프로덕트 매니저, 프로덕트 디자이너, 엔지니어임. 타 직군의 도움을 받을 수도 있지만 팀에 포함시키는 것은 너무 비용이 큼.
스타트업에서는 회사 전체가 프로덕트 팀임. 회사가 커지고 프로덕트 팀이 많아질수록 어떻게 팀을 구분할지 고민하게 되는데, 이를 team topology라고 부름. 각 팀에 제품의 유의미한 일부를 주고 주인의식을 가지도록 해야함. 피쳐 팀은 직원처럼 생각하지만 프로덕트 팀은 주인처럼 생각함. 프로덕트 쪽 사람이라고 모두가 PM이 될 수 없다고 한 것은 이런 점을 포함함.
이탈률 문제를 해결해야 하는데, 예를 들어 iOS 개발자가 iOS 코드베이스를 고치는 것으로는 이를 전혀 개선할 수 없다고 느낀다면 iOS 개발자를 어떻게 도와줘야하나?
이는 제품 전략에 대한 부분부터 생각해야함. 제품 전략은 비전을 실현하기 위해 가장 중요한 문제가 무엇인지, 그리고 어떤 팀이 해당 문제를 가장 잘 해결할 수 있는지 결정함. 온보딩 문제를 네이티브 앱 팀이 해결하라고 하는 경영진이 정신나간 것임.
인스파이어드가 널리 읽히는 것은 긍정적이지만, 그렇게 일을 할 권한이 없다고 하는 팀이 많음. 이건 경영진의 문제인데, 새 책인 임파워드에서 경영진 문제를 다룰 것임. (2020년 연말 출간 예정)
(웨비나 대화 내용 - 애초에 속기가 목적이 아니라 중간에 오탈자도 꽤 있고 내용도 빈 부분이 꽤 있습니다. 참고용으로만 사용하시길)
What are you hoping to get out of this webniar?
Get tips and advice
Empower my team
Feature team vs empowered product team
The definition of product team and product management is dramatically different across the companies, especially between best companies and other companies. At first had bias that startups do innovation and big companies didn't, but I was wrong. For example, think of Amazon. it's not about size; it's about thow they work.
My focus is on product teams. I like them, and thought that's where innovation happens. My reputation is around PM. Engineering and design have well established tradition, but there was a lot of confusion around PM.
Three kinds of product team:
1. Delivery teams. Have agile product manager managing backlog, just engineers without PM or product designers developing codes, even outsourced ones. Safe and setup for that, but no good companies use such configuration. But does 0 innovation.
2. Feature teams. 2 and 3 look similar outwardly. They are cross-functional squads. But in detail there's big difference. I've been helping companies move from feature teams to product teams. Fundamental difference in culture, how you work, how you value peopel. In feature team, the defining characteristic is the roadmap of features and products to build. They serve by building those features according to the roadmap given by executives. The PM in this team is actually a project manager despite the title of PM. May do some design, some usability testing, some backlog management for developing, but if that's how it works, the team cannot be held accountable for business results - the roadmap came from others. Features are outputs in this team; they don't necessarily add values to business. In good comapnies, teams get points for solving problems, not churning out features.
3. Empowered product teams. You don't give them features, but problems to solve. What's hard is that you have to solve in a way that customers love, but still works for the business. That changes the design, engineering roles a lot, but most of all, PM role. In product team, PM is responsible. Four risks: Value, viability (will it work for our business), usability, feasibility (can we build it) risk. They exist in product team, PM is responsible for value and viability. In feature team, no one is responsible for value and viability, but implicitly the people who give them the roadmap. In product team, you're held responsible for the result. If a feature doesn't solve the problem, you gotta keep trying with other features. My focus is on those empowered product team, and how they work to solve the problems. Inspired is about techniques to tackle those problems. Solve problems collaboratively, not sequentially.
Problem space vs solution space. Solution space is more about engineering output, problem space is mroe about customer and business result.
The distinction is an old remnant of waterfall. Under this model, you'll have no true innovation. Great product comes from real customer pain combined with what's possible at this moment. In old model, PM is responsible for problem space and others the solution space, but there'll be no innovation in this model. Modern product is customer problem and business problem should be considered and solved toether.
What would be resources or tools for the organizations to move from feature team to product team? What are the first steps? Is there a quick how-to?
Great question that I want people to ask. Get out of bubble of Netflix, Spotify, Amazon, then there're a lot of feature teams. Biggest motivation of companies to move from feature to product team, it's usually Amazon puts fear into CEOs. Amazon considres moving into their or adjacent business, puts fear in CEOs. It's a fundamental cultural change. Digital transformation is similar in difficulty and failure rate. Before SVPG engages with companies, the prerequisite is leader, esp. CEO, understands the needs for that change. Everyone says they understand the need, but we try to figure out if they are serious to gauge whether this transformation can happen.
How do you convince CEO? What's in it for them?
Sometimes new CEOs who understand it come in, makes it easy. Software is eating the world - CEOs might think they are car or entertainment companies, but I tell them to realize that you're fundamentally technology company. If you don't someone else will come and disrupt you. Tesla in car industry, Pixar in industry. I'm good atscaring them into realizing it. If Amazon or Apple consider your market underdeveloped and move in, they will succeed in replacing you. It was harder to convince 10 years ago, but it's easier now.
That's just the prerequisite. Without leadership support, don't even try. It's doomed to fail.
- CEO must make sure that product leadership that knows their job and how to build the team is in place. Hire them, but it's hard to hire such VP of products. Executive coaching is an alternative to teach what to expect and what to do. A great place to see if the CEO actually has the will to go through with the change. Because this transformation politics and power. Feature teams are subserviant to business, the leadership is in control. With good product teams, it moves from subserviant model to collaborative model. Not some IT teams in basement doing some executive stuff, but a collaboration between partners to come up with workable solution. That's a political change. Without support from CEO, little change of happening.
- Raise the game team by team. From outside, feature and product teams look similar as they have same titles. But we have to make sure engineers and designers step up, which is what they were trained for so it's not hard. But not all product people are capable or willing to do so. It's a lot more knowledge, a lot more responsibility. So the leaders have to make sure that the team is ready for the responsibility that will be given.
- Give them that responsibility. Reintroduce that product team - I recommend it team by team basis. Let them understand that they are part of the business now. For example, tell PM that instead of getting directives from the Senior VP of Merchandise, you have to collaborate with her. It requires much more knowledge, responsibility, and everything. That's why it's beyond the project managing, and is coveted by top graduates from top business schools.
When the process is in place, the understanding that they are partners, how do you tell that's working? Rearrange seats? What do you look at?
That's easy. One of my argument with CEO, CFO is how well do your system work? They say it's terrible. I ask: Would you like to hold the product team accountable for the result? They of course want that. I say: You can't do it with feature teams, since the teams didn't decide to do it. Product teams, on the other hand, are measured by their results. They produce outcomes, not outputs. Reduced churn rate, better engagement. Currently good sales in US but not replicated in Korea or China, we find the measure of success. Product team works by you not giving them roadmap but the problems and the measure of success. If some leader goes to a team and tell them the problem to solve, reduce churn rate from 80% to 4%, then that's not empowerment. It's setting them up for failure. Instead say: churn rate is terrible - find a way to reduce it. The team will discuss, get back, say we'll get it down by 5% over the next quarter. OKR is a well-known tool for doing this. People tried OKR and didn't get any result - that's because they're feature teams. They have roadmaps and OKRs, then they are just gonna do roadmaps. For a proper empowered product team, you don't even need OKR. Here's your problem, tells us what you can do.
Let's get further with reduced churn rate and product team is accountable for that. Let's say The top reason for churn rate is operations, churn, or even infrastructure. Product team may feel they are accountable, but after analysis, it has to be solved by content or infra team. Not the engineer or designer in the team. Are they accountable for just based on their abilities? Is that a wrong way of thinking?
It's a common objection. I said not everyone wants that additional responsibility. If the company embraced the new model, that's exactly what they want. If a product team is accountable for problems... the product should be making money. Even if the product doesn't suck, there can be many other factors - is marketing or sales channel effective? But in product team, if there's problem, the PM should get out of office and figure out where the issues are and drive them to resolution. Most of the time, there's ... This happened to me a lot of time. Sales is the problem! It takes forever to onboard customres because everything is done manually! In feature team, they'll say it's not our responsibility. In product team, if the lack of automated onboarding is the problem, then they will go and figure out and solve that problem. We work with other team all the time. Hey we found that this is the fundamental reason for the problem, so let's solve it. Does it sound intimidating? It should.
Where do you draw the circle around the product team? Product marketing, engineer, sales, are they all part of the team? Or counterparts? How does the organization work?
You're bringing up several points. Product manager, product designer, engineer - that's the typical team. You'll get help from sales, marketing... but you don't have to have them on the team. That would be prohibitively costly. In startup, product team is the company. As you grow to have five, ten product teams, you need to divide and conquer. That topic of what's the best way to structure and draw lines around team, that's called team topology. Platform, experience teams, and so on, give each team what they own. Look at companies like Youtube, you have more than 100 teams on one product .It's important to give each team a meaningful piece of the product.
The biggest issue is the sense of ownership. Bezos emphasizes the importance of PM who think like owners and not like employees. In feature teams, it's natural for them to feel like employees. In product team, you have to think and act like owners .It's not accident for companies to give them stock options to make them actually owners. But that's the mindset. Remember that not all product people are cut out to be a PM? That is why.
There's that stay in your lane mentality. How do we move forward from that, what are the cultural and organizational aspect? Break down the barrier?
iOS engineers are skilled to do iOS work. Different engineers have different skillsets. The real point is: depending on topology, that will drive which skillset should be on that team. Which tech stack? Some teams won't do mobile, other teams will just do mobile. Some teams are heavy on data, some on search, and so on. That's normal, Structure teams in different ways. Currently machine learning is an important skill .Companies want at least one ML engineer on each team, but they can't hire that many ML engineer so put them on a few teams and make that team the platform team.
iOS engineer may think, based on my skill set, I can't do anything to solve the churn rate problem by working on iOS codebase. How do you empower such an engineer who's still constrained by output.
That's not how it happens. One huge topic that we haven't discussed, even when doing feature team, it's product strategy. It tells which problem should be solved, which are the most important problems to accomplish our vision. Product strategy drives the problems solve, and determine which team is the best to solve that problem. Don't go to native app teams to solve onboarding problem. That's crazy leadership. If an engineer finds his skill unnecesary in the team, he will move to other team.
OKR is at org and team level. Who's the owner of the outcome definition and assignment?
Owner of the strategy is the head of product. Good ones include design and tech counterpart in that process, but if one person has to be chosen, that's head of product. Leaders will determine the objective, and teams themselves will suggest key results.
Inspired has spread, but many teams are saying they're not in position to do that. I realized that leaders are the problems. Empowered deals witht his issue.