Product-minded engineers는 제품 자체에 관심이 많은 개발자다. 왜 그런 결정이 내려지는지, 사람들이 제품을 어떻게 쓰는지 이해하려 하고, 제품 관련 의사결정에 참여하는 것을 좋아한다. 엔지니어링의 즐거움을 포기한다면 좋은 PM이 될 법한 사람들이다. 세계적 수준의 제품을 만드는 회사에서는 이런 엔지니어들이 팀의 임팩트를 새로운 수준으로 끌어올린다.
Atlassian PM인 Sherif Mansour는 product engineers에 대한 글에서 “product engineers are a critical ingredient to helping you build a successful product, scale yourself and become a better product manager”라고 적었다. Shopify 엔지니어링 헤드 Jean-Michel Lemieux는 product engineer를 “제품의 기초가 갖춰진 뒤, ’why’에 적극적으로 관여하는 개발자, 인간/사용자 문제를 뛰어넘기 위해 기술을 활용하려는 욕구를 가진 엔지니어”로 정의하며, “great product engineers know that minimum lovable products need the right depth to be considered during the build phase”라고 덧붙였다.
사용자 대면 기능을 다루며 PM과 협업하는 팀에서 product-minded engineer는 큰 임팩트를 낼 수 있고, 핵심 기여자, PM의 goto person이 되며 팀 리드로 승진하는 경우가 많다.
1. Proactive with product ideas/opinions
스펙을 받아 그대로 구현하는 데 만족하지 않고, 다른 아이디어를 생각하며 PM에게 제안한다. 더 나은 대안적 제품 접근이 있으면 기존 스펙에 이의를 제기하기도 한다.
2. Interest in the business, user behavior and data on this
아이디어는 비즈니스가 어떻게 작동하는지, 제품이 어디에 맞아들어가는지, 목표가 무엇인지 이해한 데서 나온다. 사용자가 제품으로 어떤 느낌을 받는지, 어떤 이득을 얻는지에도 공감한다. 비즈니스·사용자 지표 데이터를 직접 접근하거나 PM/데이터 사이언티스트를 통해서라도 얻으려 한다. 이는 그들의 호기심 많은 성향에서 비롯된다.
3. Curiosity and a keen interest in “why?”
왜 이 기능을 만드는지, 왜 다른 기능이 아닌지, 왜 더 간단한 다른 마일스톤이 아니라 이 첫 마일스톤을 출시하는지, 측정 방식이 왜 더 철저하지 않은지 등을 알고 싶어한다. 스스로 찾을 수 있는 답은 자율적으로 찾고, 제품 관련 질문은 PM 등에게 묻는다. 자주 질문해도 사람들과 이미 강한 관계를 쌓아두었기 때문에 상대를 귀찮게 하지 않는다.
4. Strong communicators and great relationships with non-engineers
엔지니어링 밖 사람들과 이야기하며 그들이 무엇을, 왜 하는지 배우는 것을 좋아한다. 다른 분야가 어떻게 작동하는지 더 배우고 싶다는 관심을 명확히 전달하는 원활한 커뮤니케이터이며, 비엔지니어와 커피/점심/복도 대화를 자주 한다.
5. Offering product/engineering tradeoffs upfront
제품의 “why”와 엔지니어링 양쪽을 모두 강하게 이해하기 때문에 다른 사람이 하지 못하는 제안을 할 수 있다. 예를 들어 핵심 기능 구현에 필요한 엔지니어링 노력이 상당할 때, 대부분의 엔지니어는 노력을 줄일 방법을 찾고 그로 인한 기능 임팩트를 파악하려 한다. Product-minded engineer는 양방향에서 문제에 접근한다: 엔지니어링 트레이드오프뿐 아니라 제품 임팩트도 함께 평가하고, 반대로 제품 트레이드오프를 만들며 엔지니어링 임팩트를 평가한다. 이들은 종종 비슷한 제품 임팩트를 내면서 엔지니어링 노력은 훨씬 작은, 완전히 다른 기능을 PM에게 제안하기도 한다.
제품 임팩트와 엔지니어링 노력이라는 같은 동전의 양면을 머릿속에서 빠르게 오가며, 엔지니어링과 제품 인사이트를 동시에 활용해 결론에 신속히 도달하는 것이 이들의 독특한 강점이다.
6. Pragmatic handling of edge cases
한쪽 극단에서는 엔지니어들이 많은 엣지 케이스를 잊고 있다가 테스트/실사용자 피드백을 받은 뒤 다시 처리하러 돌아온다. 다른 극단에서는 새 제품/기능에서 가능한 모든 엣지 케이스를 처리하는 데 많은 시간이 든다.
Product-minded engineer는 엣지 케이스를 빠르게 파악하고, 종종 엔지니어링 작업이 필요 없는 해결책을 찾아 작업을 줄인다. “minimum lovable product” 개념에 집중해 엣지 케이스의 임팩트와 처리 비용을 함께 평가하며, 초기 버전 출시 전 어떤 엣지 케이스를 처리해야 하는지에 대한 중간 지점의 제안을 내놓는다.
예: 1000명 중 1명이 에러를 겪는다면, 수정 비용과 방치 시 결과를 함께 고려한다. 검증 단계에서 고객지원이 도와줄 수 있는가? 사용자가 재시도하면 성공하는가? 제품을 약간 수정해 이 엣지 케이스 자체를 없앨 수 있는가?
7. Quick product validation cycles
기능이 프로덕션 준비가 되기 전에도 초기 피드백을 얻을 창의적인 방법을 찾는다. 동료와의 hallway testing, PM에게 작업 중인 기능 보여주기, 베타 빌드에 대한 팀 버그 배시 조직 등이 그 예다. “사람들이 우리가 생각한 방식대로 이 기능을 쓸지 어떻게 검증할 수 있을까?“를 지속적으로 고민한다.
8. End-to-end product feature ownership
대부분의 경험 있는 엔지니어는 스펙 수령부터 구현, 출시와 검증까지 end-to-end로 자신의 작업을 소유한다. Product-minded engineer는 여기서 한 걸음 더 나간다.
출시 후 사용자 행동·비즈니스 지표 결과를 확인한 뒤에야 작업이 끝났다고 여긴다. PM, 데이터 사이언티스트, 고객지원 채널과 계속 소통하며 실제 사용 방식을 파악한다. 신뢰할 만한 데이터를 얻는 데 수 주가 걸릴 수 있는데, 새 프로젝트를 하면서도 결과 확인을 우선순위로 둔다. 기능이 예상보다 저조하면, 코드베이스의 재현하기 힘든 버그를 디버깅하는 것만큼 진지하게 제품 계획과 실제 결과 사이의 불일치 원인을 찾는다. PM, 데이터 사이언티스트와 가설과 학습 내용을 오래 논의하기도 한다.
9. Strong product instincts through repeated cycles of learning
일반적인 프로젝트 진행 방식:
- 기능이 왜 만들어지는지 정확히 이해하기 위해 많은 질문을 한다.
- 제안과 트레이드오프를 테이블에 올리고, 일부는 수정된 스펙에 반영된다.
- 빠르게 기능을 만들며 초기 피드백을 얻는다.
- 출시 후 기능이 기대에 부합하는지 적극적으로 팔로업한다.
- 그렇지 않을 경우 깊이 파고들어 이유를 이해하고 실제 사용에 대해 새로운 것을 배운다.
프로젝트마다 제품 이해가 깊어지고 더 나은 제품 직관이 발달한다. 다음번에는 더 관련성 높은 제안을 내놓는다. 시간이 지나며 PM들이 프로젝트 시작 전부터 조언을 구하는 goto person이 되고, 팀 밖에서도 강한 명성을 쌓아 커리어 성장의 문을 더 많이 연다.
Tips to become a more product-minded engineer
사용자 대면 제품을 다루는 경우 도움이 되는 팁:
- 회사가 어떻게, 왜 성공하는지 이해한다: 비즈니스 모델은 무엇인가, 어떻게 돈을 버는가, 어느 부분이 가장 이익이 나고 가장 확장 중인가, 왜인가, 우리 팀은 이 전체 그림에 어떻게 맞아들어가는가.
- PM과 강한 관계를 구축한다. 대부분의 PM은 엔지니어를 멘토링할 기회에 적극적이다. 제품 질문을 많이 하기 전에 관계를 쌓고, 제품 주제에 더 관여하고 싶다는 것을 PM에게 명확히 전달한다.
- 사용자 리서치, 고객지원 등 활동에 참여해 제품이 어떻게 작동하는지 배운다. 디자이너, UX, 데이터 사이언티스트, 오퍼레이션 담당자 등 사용자와 자주 접촉하는 사람들과 페어링한다.
- 근거가 뒷받침된 제품 제안을 테이블에 올린다. 비즈니스·제품·스테이커홀더에 대한 이해가 갖춰지면 주도적으로 나선다. 작업 중인 프로젝트에 작은 제안을 하거나, 엔지니어링 노력과 제품 효과를 함께 정리해 백로그에서 우선순위를 정하기 쉽게 만든 큰 제안을 할 수 있다.
- 제품/엔지니어링 트레이드오프를 제시한다. 팀이 만드는 기능에 대한 엔지니어링 트레이드오프뿐 아니라, 엔지니어링 노력을 줄이는 제품 트레이드오프도 제안한다. 이에 대한 피드백에 열려 있어야 한다.
- PM에게 자주 피드백을 요청한다. 좋은 product-minded engineer가 된다는 것은 기존 엔지니어링 역량 위에 제품 역량을 쌓았다는 뜻이다. 제품 제안이 얼마나 가치 있는지, 어떤 부분을 더 성장시켜야 하는지는 PM에게서 가장 잘 피드백받을 수 있다.