# How Mews Turned Its R&D Org Into Product Builders > Mews moved around 350 people to product builders in a single day. Here is why they did it, how it works day to day and what they learned. --- [Skip to main content](#main-content)Strategy # How Mews Turned Its R&D Org Into Product Builders Mews moved around 350 people to product builders in a single day. Here is why they did it, how it works day to day and what they learned. **Matej Stefanik**Nov 6, 2026 · 10 min read [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fclosedloop.sh%2Fblog%2Fhow-mews-turned-rd-into-product-builders)Copy link On this page - [How it started](#how-it-started) - [From trial to rollout](#from-trial-to-rollout) - [What changed](#what-changed) - [The role](#the-role) - [The organization](#the-organization) - [The daily work](#the-daily-work) - [What holds it together](#what-holds-it-together) - [Lessons learned](#lessons-learned) - [Where this is heading](#where-this-is-heading) [Product Builders](https://closedloop.sh/tag/product+builders)[Product Management](https://closedloop.sh/tag/product+management)[Mews](https://closedloop.sh/tag/mews)Key takeaways - Mews moved its entire R&D organization of around 350 people to product builders in a single day, after two smaller experiments - Every builder owns a metric, and the job description is short: go and move the metric - The whole team now has five job descriptions, with over 200 product builders and about 20 staff specialists - The hard parts are loneliness, product cohesion and how much change customers can absorb, and some of that is still unsolved On 4 November I had a great conversation with Josef Starychfojtu, CPTO at Mews, about how his team moved to a new way of working. This year, Mews moved its entire R&D organization of around 350 people to one model: [product builders](https://closedloop.sh/blog/what-is-a-product-builder), people who own a problem from deciding what to build through to shipping it. Mews is "Shopify for hotels". It runs everything from booking to payment for around 15,000 hotels, with roughly 1,200 people across 85 countries. Here are the highlights: why they did it, how it rolled out, how it works day to day and what they learned, including the parts that are still unsolved. If you'd rather watch, here's [the full recording](https://www.youtube.com/watch?v=8MTN6Hg7Aks). [![Watch the full recording: How Mews turned its R&D org into product builders, with Josef Starychfojtu and Matej Stefanik](/assets/images/blog/mews-product-builders-recording.png)](https://www.youtube.com/watch?v=8MTN6Hg7Aks) 15,000 Hotels 85 Countries 200+ Product builders ## How it started Josef wanted this long before AI made it possible. “I always felt that people who are closest to problems are the best ones to solve that problem.” What stood in the way was functional silos. Product managers complained that engineering was slow. Engineering complained that nobody considered technical debt. The usual fix, a trio of product, design and engineering, can work well, but Josef describes it as people who sit on calls together all day. That is an expensive way to stay aligned. His core belief is that **everyone behaves according to their incentives**, and that most incentives come from the org structure and your role. So he changed the structure step by step: When What changed When he became CPTO Product and engineering came together under one leader Two years later His managers became combined directors and VPs of product and engineering This year Individual contributors followed, and the product manager, designer and engineer roles merged into one AI is what made the last step possible. Mews kept testing the tools first-hand, and for a long time opinion was split between skeptics and believers. Then a new generation of models arrived, and the debate ended. "You can actually delegate a huge part of your job to an agent." Josef sees this as a natural continuation. Front-end and back-end developers became full-stack developers when technology allowed it. Now the same thing is happening one level up. And once writing code stopped being the constraint, the question became **which organizational constraints could go with it**. ## From trial to rollout Mews didn't start with the whole organization. It ran two experiments first. **A few hires with hard problems.**About a year ago, Mews hired its first product builders, gave them hairy problems and treated each person like a full team. It worked well. The team's hypothesis was that this would suit greenfield work but struggle with ownership and long-term maintenance. **That turned out to be wrong.** **40 engineers with unlimited tokens.**Mews then gave a group of 40 engineers unlimited tokens and met them every week with one question. 40 engineers “What was limiting you last week?” The early answers were small things like access and tooling. Then the answers changed, and engineers started working on other teams' backlogs. The real bottleneck Engineers ran out of backlog while their PM was still in discovery. **Building was no longer the limit.** That showed Mews where the real bottlenecks were. A few months later, after three to four months of planning, **Mews moved every team in a single day**. Josef chose this over slow enablement because it is too easy to fall back into the old way of working, while a sudden change makes people rethink how they work. It was a shock for many, and some people loved it while others didn't. ## What changed The simplest way to picture a product builder is as a squad of one. What you would normally give to a PM, a designer, an engineering manager and a few engineers, **you give to one person**. Functional trios Product, design and engineering each own a piece Each function looks at its own success Staying aligned means calls all day No single accountable owner Product builders One person owns the problem from start to finish Success is an outcome metric and a scorecard Builders can move on their own The person closest to the problem decides Here is how that works in practice. ## The role ### What does a product builder do? Every builder has an outcome metric plus a scorecard of supporting metrics. The job description is short. “Go and move the metric.” How they do that is up to them. They speak to customers, look at data, do discovery, test prototypes, build, go to market, and then do it again. A builder typically looks six to twelve weeks ahead. ### Where do the metrics come from? Metrics come from company strategy and cascade down. Josef sets them with his VPs at the top, teams agree theirs, and managers set them for individual builders. His example is the booking engine: Level Metric Product builder Booking engine conversion Their manager Optimizing distribution for hotels Above that Something bigger still Every quarter, Mews looks back at how the metrics moved and whether they are still the right ones. ## The organization ### What does the org look like? The whole team has five job descriptions: Role What they own Reports to Product builder A tactical metric, on a 6 to 12 week horizon Director Lead product builder A strategic initiative, on a 6 to 12 month horizon Director Staff specialist (engineer, designer or PM) Looking after their function Director Director of product and engineering A team, its North Star metric and scorecard VP VP of product and engineering A group of teams CPTO ### Does every team have specialists? No. Mews has over 200 product builders and only about 20 staff specialists. Most teams don't have all three types. Some have a staff engineer, some a staff PM, some a staff designer, depending on the domain and the people in the team. 200+ Product builders ~20 Staff specialists 5 Job descriptions Josef calls the staff PM version a U-shaped role. Builders now do their own discovery, so it is fair for a PM to ask where they fit. But a big, transformative change, like a shift in the company's value proposition, is not something a builder will take on. That still needs a PM, who also helps with pricing, packaging and go-to-market. So the PM comes in at the beginning and at the end. **The middle belongs to the builders**, and as they take on more, that middle keeps growing. ![The U-shaped staff PM role: the PM is involved at the beginning and at the end, while the growing middle belongs to product builders](/assets/images/blog/u-shaped-pm-role.svg) The surprise **The happiest builders are former PMs.**Every one Josef has spoken to loves no longer having to depend on anyone. ### How do builders work together? Teams own a domain, in the traditional sense, as well as a metric. Within a team, two builders often share a metric, though too many creates a too-many-chefs problem. If teams disagree, or a decision is bigger than one team, it bubbles up to someone like Josef. On autonomy versus speed, Josef mostly cares about the team's North Star, and there is one meeting he encourages everywhere. Try this **A weekly two-hour session where everyone shares what they are working on and what they have learned.**People try each other's prototypes and challenge each other. ## The daily work ### How does discovery work without a PM? Builders draw on several sources: - **Company strategy**, which reaches them through the cascading metrics and the context around them. - **Sales calls and support conversations**, which they can query through the internal AI platform. _(ClosedLoop AI helps here, surfacing what customers keep raising in a builder's domain.)_ - **Customers themselves**, who at Mews are very willing to talk. - **Product analytics and feature flags**for testing ideas. - **Their manager**, and any staff PM nearby. ### How do people learn the job? The main central effort was a two-day offsite for all 350 people, run as a masterclass in product building. It covered product, design, finance and speaking to customers, with outside speakers and internal teams. Beyond that, Mews supports whatever training people ask for. The bigger shift is that good practice now spreads through tooling. When someone learns something, they can add it to the shared AI platform. In Josef's words, "everyone learns it at the same time". ### How does shipping work? Mews has never had release synchronization, and everyone still releases when they want to. Marketing is decoupled from deployment. Josef compared it to Airbnb's seasonal releases: features ship continuously, then you tell the story of the last three or four months in one go-to-market moment. ## What holds it together ### What about code quality? Mews took some of its best staff and principal engineers and made them a team of product builders, the modernization team. They make the biggest architectural changes, such as decoupling the monolith, and they own the architecture rules in the shared agent harness. That makes change simpler than before: instead of training everyone on a new way of testing, you tell the agent. A scorecard tracks bugs, incidents and security issues, and the platform team is adding self-healing on top. Decoupling has sped up too, and only about 8% of work now goes into the monolith. ### Do you need special tooling to start? Josef says no. **Out-of-the-box tools are good enough**, and waiting for something better can become an excuse. But Mews has invested heavily over the past four months in a custom internal AI platform, because AI work otherwise stays siloed on each person's laptop. It is a central cloud harness with a knowledge graph underneath, and it also gives builders hints about what to explore in their domain. _(ClosedLoop AI is part of this as well.)_ ## Lessons learned Josef says there are hundreds of lessons, and that the list will look different in six months. These are the ones he would pass on today. ### 1. Watch for loneliness When nobody depends on anyone, "people will become very lonely". Builders can feel they are sitting on an island, so managers have to work actively on bringing the team together. ### 2. Give staff roles clarity early Builders can see what to do from their metrics. Staff specialists can't always see where they fit, and they need much more guidance from their managers on where the biggest impact is. ### 3. Expect cohesion to get harder Faster, more independent teams make a consistent product experience harder to keep. A shared harness helps, but Josef is open about this one: "I would love to speak to someone who has a solution." ### 4. Invest in platform teams Josef calls them the stars of the show. The internal AI platform also won over people who were unsure, once they saw how it helped their daily work. ### 5. Expect other things to break The beta program stopped working, because there was suddenly so much more to test and not enough beta customers. ### 6. Plan for the new bottleneck: everyone around you At the latest roadmap commit, the document was so long that for the first time "no one even read it". Customers were already saying Mews launched too often before AI. Josef's answer to that last one is parallelization. You can't launch seven products to one customer, but you can launch seven products to seven customers. It also raises the question every company will have to answer: what do you do with the extra capacity? **Unless AI reaches your top line, it is just a cost-saving exercise.** Mews hasn't mastered this yet, and Josef says so. But you can now fight on multiple fronts. ## Where this is heading I've spent about 20 years in debates about how product teams should be organized and who should decide what. The Mews story is the clearest sign I've seen of where this is going: fewer handoffs, fewer roles, and more people who own a customer problem from start to finish. Josef doesn't think it stops here. Every year he feels Mews has reached the state of the art, and every next year he finds it can go further. Following the same line from full-stack developers to product builders, he wonders whether one day the same person could sell, support and build. Solution architects are the closest thing today, and some of Mews's best product people started in that role. I've seen the same thing in my own career. Nobody knows exactly how far this goes, and few organizations have made this move so far. But the direction looks clear to me. The people closest to the problem are getting the tools to solve it themselves, and that is good news for them and for their customers. If you'd like to hear it from Josef directly, [watch the full recording](https://www.youtube.com/watch?v=8MTN6Hg7Aks). Matej Stefanik CPO and co-founder of ClosedLoop AI. 20 years building and bringing products to market, from development and management to marketing. [More about ClosedLoop AI →](https://closedloop.sh/) ### Get insights like this in your inbox Product insights delivered weekly. No spam. Unsubscribe anytime. Leave this field blank Subscribe Related ## More you might find useful [Strategy Oct 29, 2026 ### Product Engineer vs Product Manager vs Product Builder: Who Owns the Outcome? What a product engineer does, how the role differs from a product manager, and why both are merging into the product builder, who owns one m… 11 min read →](https://closedloop.sh/blog/product-engineer-vs-product-manager-vs-product-builder)[Strategy Nov 6, 2026 ### The Product Operating Model When Everyone Builds What a product operating model is, how it differs from a project model, and how it changes when AI lets one person decide, build and ship on… 6 min read →](https://closedloop.sh/blog/product-operating-model)[Strategy Oct 21, 2026 ### What Is a Product Builder? The Role, the Loop, and the New Bottleneck A product builder owns a metric from problem to outcome: they decide what to build, build it with AI and ship it. Here's the role and the lo… 8 min read →](https://closedloop.sh/blog/what-is-a-product-builder)[Browse all articles →](https://closedloop.sh/blog) --- ## More Information - Website: https://closedloop.sh - Documentation: /docs - Pricing: https://closedloop.sh/pricing - Contact: https://closedloop.sh/contact