When people ask what a Product Builder is, the short version is this: I am not here to wait for a perfect spec, pick up a ticket and disappear after the merge. I am here to find worthwhile problems, validate them quickly, build the thing, ship it and stay close enough to see whether it actually helped. That is the core of the role at Mews.
More than just engineering
At Mews, the role was created as a deliberate shift away from narrow specialization and handoff-heavy delivery. Product Builders are expected to operate with more autonomy than the usual trio or duo model allows, stay aligned to tribe strategy and collaborate with PMs and designers without depending on them for day-to-day direction.
The point is simple: shorten the loop between seeing a problem and shipping a solution. Mews explicitly framed the role around faster execution, tighter problem-solution loops, end-to-end ownership and AI-native ways of building.
In a way it is a return to roots. In a small startup, one engineer usually does design, product, stakeholder conversations and code all at once. The Product Builder role brings that back at Mews scale, with the tooling and tribe structure to make it work. Full stack here means really full, not just one backend language and one frontend one. It includes discovery, design and the conversation with the customer.
📋 What I actually do
In practice, being a Product Builder means I spend part of my time in discovery and part in delivery, but I do not treat those as separate phases. The role update on our side described the pattern well: explore multiple opportunities in parallel, validate quickly with users, converge on a smaller set of high-impact bets and ship end-to-end autonomously.
Claude Code is in the loop for almost everything I do now. Specs first, code second. Small reversible slices, fresh context per slice, no automatic PRs to main.
The thing I find easiest to overstate, and try not to, is the AI part. The agents are a multiplier. They are not the work. The work is still understanding the customer problem, choosing the right slice and writing code that the team can live with in six months.
Some of the work is glamorous. Some of it is not. One week I might be shipping a new AI-assisted feature in front of customers. Another week I might be tracking down a bug that only shows up in production, or rewriting a piece of internal plumbing that the rest of the team has been politely tolerating for months.
📆 What my day-to-day looks like
There is no neat template, but most days include some mix of these:
- Talking to people close to the problem: customers, internal stakeholders, support, product, design or engineers.
- Turning vague friction into a sharper hypothesis I can test quickly.
- Prototyping or building directly, usually with heavy use of AI tooling as part of the workflow rather than as a gimmick.
- Shipping smaller pieces earlier than a normal roadmap process would usually allow.
- Watching what happens after release and deciding whether to iterate, scale or kill the idea.
A good Product Builder day is not “I wrote a lot of code.” It is “I reduced uncertainty.” Sometimes that means shipping. Sometimes it means proving an idea is weak before more people sink time into it. My own OKRs reflect that pretty directly: build strong discovery habits, run experiments with clear hypotheses, get comfortable killing my own ideas and prove the Product Builder model through measurable outcomes rather than just activity.
A very normal day can move from a customer problem, to a rough prototype, to a technical spike, to a release concern, to a Slack thread with a teammate that sends me off to research a new angle and return with something concrete.
💡 What is different from a normal squad role
The biggest difference is ownership. In a traditional setup, discovery, design, implementation, release and follow-up are often split across people and ceremonies. In this role, much more of that sits with me directly.
That does not mean Product Builders replace squads. Mews has been pretty clear on that. Squads still make sense for defined product areas, roadmap delivery, scale, reliability and long-term ownership. Product Builders are most useful in high-ambiguity, exploratory, cross-cutting spaces where speed matters more than completeness at the start.
Do you like building, experimenting, and figuring things out in the open?
Sounds very Product Builder-y to us.
That difference matters because some of the best opportunities do not arrive as tidy backlog items. They show up as messy friction, repeated questions, weird gaps between teams, or ideas that are too early for a squad to commit to but too valuable to ignore.
❗The hard part
The role sounds great on paper, but it also exposes every place where the rest of the system is still optimized for squads. Our role learnings called this out clearly: slow PR turnaround, release delays, ownership ambiguity and visibility gaps all create friction for Product Builders.
That is the less glamorous reality of the job: moving fast yourself is not enough if the surrounding system still assumes slower loops.
There is also a scaling question. If a Product Builder owns everything they ship forever, eventually they stop building and become a maintenance team of one. So part of the role right now is not just shipping work, but helping define what sustainable handover, visibility and operating patterns should look like as more Product Builders join.
❤️ Why I like the role
I like it because it matches how I think good product work should happen. Stay close to the problem. Build enough to learn. Use AI and automation to compress the boring parts. Own the result, not just the implementation. Repeat.
And honestly, I like that the role is still being defined in the open. Part of my job is to help make the Product Builder model undeniable at Mews. That means the work is not only shipping features. It is also documenting what works, exposing what does not and helping shape a better way of building products here.
📝 The simple version
If I had to explain the role in one line, I would say this:
A Product Builder at Mews is someone who owns the path from problem to outcome. Not just the code. Not just the idea. The whole thing.
And if you want to see what that looks like in practice, we also put together a LinkedIn carousel breaking down the role — including two real Product Builder case studies from inside Mews.
➕ If this sounds like you
Product Builder is now an always-open role at Mews. We hire for it on a rolling basis, not just when a specific seat opens up. If anything in this post matches how you want to build, take a look at our careers page and come find us.
