AI 세계의 "제품 팀과 기능 팀"

All the way back in 2019, Marty Cagan wrote an article titled "Product vs Feature Teams". If you're building things you should read it in full but right now I want to take a look at how these ideas land as more and more teams are being encouraged to use AI in their daily workflow. The Silicon Valley Product Group (SVPG) have written many very popular books on how to run successful product teams and product focused companies. A common theme across all of their work is that Product, the capital-p function in a business, works best when it's role is to maximize problems-solved rather than product features delivered. This helps empower people and ultimately, so they claim, deliveries more value to end customers. As worthy a goal in 2026 as much as it was in 2019. The third type of team and how to avoid it. Before the article gets into full swing, Cagan points out a third type of team: The most common in terms of sheer numbers are not really product teams at all, they are delivery teams. Also referred to as “dev teams” or “scrum teams” or “engineering teams” and if your company is running something like SAFe, then unfortunately this is you. Through working with and within many engineering teams, I still think this is the most common team type by absolute numbers. I also think this style of team correlates fairly well with an initial burst of growth followed by a long stagnation. What's missing in these teams is the process of product itself. These teams, often under the direction of a non-technical leader, are asked to "just build what I tell you". Those leaders have a grand, but often blurry, vision for what they want and teams end up shipping the 60% version of that vision quite quickly. Once the initial version is shipped it becomes harder and harder to articulate what's missing. As a result, output, judged on the number of new things shipped, shifts to shipping small inconsequential tickets as fast as possible to maximize a metric. This is likely to happen even more frequently in a world where AI can get you to the 60% version very quickly. Assuming your "scrum team" remains in place, the output here is going to be an increased focus on tickets shipped per week. These teams will still end up stuck in the 60% solution because churning through a backlog of tiny ideas is rarely the path to unique and valuable product. As much as it ever was, the path to avoiding becoming one of these teams is to champion the value of Product. Someone within the organization needs to believe that there is value in the product management function and that taking the time to discover and refine ideas is worth more than hitting the maximum of tickets shipped per sprint. Assuming you have no budget for additional people and you're in one of these teams this change can be simulated with some minor changes in process. Many of the AI models available today do an okay job acting as a product manager. They're not going to go and talk to customers on your behalf but with careful prompting you can inject some product consideration into the process. As it does with Product, this process will take extra effort and intention. All the AI coding assistants I have used are biased towards action and speed to code unless you put them in a mode that slows them down. They may ask the occasional question but by default these are implementation details rather than product consideration. These changes however, will shift your team into the 'Feature Team' setup rather than the 'Product Team' described in the article. It's still an initial step worth taking as skipping from 'Delivery Team' to 'Product Team' in one change is nearly impossible. Product Teams, Feature Teams and the Four Risks When comparing the two main types of Product team, Cagan calls out four specific risks: Value risk (will people buy it, or choose to use it?) Usability risk (can users figure out how to use it?) Feasibility risk (can we build it with the time, skills, and technology we have?) Business Viability risk (will this solution work for the various dimensions of our business?) Cagan states that the product manager is most importantly in charge of Value and Viability risk. Usability sits with design and Feasibility sits with engineering. Ideally all working together to solve problems. What I like about this framework is that it aligns well with the current capabilities, and gaps, in AI tooling. Feasibility risk has been significantly lowered thanks to AI coding agents. You still need someone in the loop to help make correct decisions but the leverage a team has to maximize time, skill and technology has dramatically increased. Usability risk is also on its way down thanks to AI. Tools like Google Stitch can increase the leverage of a competent designer dramatically. The path to a viable prototype is now much shorter and design can focus on the small but high impact changes that are so often lost in the time pressures of shipping product. In the vast majority of cases where you h