How to Build a Product Engineering Culture 🪴
A practical handbook about how to run some of your most common product engineering processes.
Hey, Luca here, welcome to a weekly edition of Refactoring! To access all our articles, library, and community, subscribe to the paid version:
Resources: 🏛️ Library • 💬 Community • 🎙️ Podcast • ❓ About
Last week I had a coffee with the CTO of an early stage startup here in Rome.
He told me he feels they are not working at their full potential: bottlenecks are everywhere and features go out 1) slowly, and 2) without the level of polish he would like.
I know what you are thinking — no CTO is ever happy with these things. But John (not his real name) is an experienced guy. We have known each other for a long time, he has 10+ years of experience in product startups, and his instincts are usually right.
So we tried to debug this together. We talked about many things, including, crucially, product engineering — that is, can we remove some bottlenecks and increase velocity by empowering engineers to do more?
If you have been following Refactoring or the tech industry at large over the past two years, you know product engineering is a growing trend (or buzzword). When you look at fast moving startups and ask them how they do it, they often mention a combination of: engineers owning features from top to bottom, shipping every day, PMs only doing strategy, and so on.
But this is easier said than done. In this utopian world, how should you run the various stages of the SDLC? Who writes requirements? Who does QA? What goes in the backlog and how? What about bugs?
There are extremely few companies documenting this journey, explaining exactly how their engineers own more work without compromising quality and while still collaborating well with product, design, or QA.
One of these is Atono.
Atono is a peculiar company: it’s a small team of industry veterans who are building a software development tool backed by their strong opinions about how software should be made — and they are doing so completely in the open.
They maintain a thorough, public handbook about how they work, from principles to internal processes, and a Substack newsletter where they share their learnings about making software, which readily implement in the tool they build.
So, this week I sat down with Doug Peete, CPO, and went through some of their best ideas for running a high-performing product team.
Here's what we'll cover:
📋 Product managers ≠ backlog managers — how to keep backlogs short and focused.
📝 User stories are about problems, not solutions — how to write requirements that unlock creativity and create long-term learning.
🚦 Feature flags are a product tool — the secret workflow to shipping without bottlenecks.
🐛 Bug management should be easy — why most teams get quality backwards.
Let's dive in!
Disclaimer: I am a fan of what Atono is building and I am grateful to them for partnering on this piece! However, I will only write my unbiased opinion about the practices and tools covered here, Atono included.
You can learn more about Atono below 👇
📋 Product managers ≠ backlog managers
When we say “PMs should not spend most of their time writing specs and grooming backlogs!” we all applaud and nod in agreement, but then who should do it, and how?
Without a clear process, you may end up in one of these familiar scenarios:
🎨 PMs do most of the work — neglecting strategy, customer research, and their higher-value duties.
🔨 Engineers do most of the work — leading to suboptimal quality in case they miss some context or in case they don’t have the product chops to do things right.
🔄 Endless back & forth — PM, design, and engineering all work together on tickets for prioritization, specs, and review, without clear rules. This leads to decision paralysis, bottlenecks, and frustration.
So, rather than focusing on who does what, start with a few principles about how things should happen:
1) Separate capture from commitment 📥
Last week I published a long article about how I take notes. In there, I wrote that one of the biggest improvements in my note-taking process has come from separating the moment where I capture an initial note, to when I refine it and put it in the proper bucket.
I even have a dedicated personal ceremony — my weekly review — where I go through all my captured notes and organize them one by one.
I can’t overstate the importance of 1) separating organizing from capturing, and 2) going through everything at once. When I do this, interesting things happen:
Many ideas that seemed interesting a few days before don’t seem all that interesting anymore, and I can safely delete them. I delete >60% of the stuff I capture.
Also, when I am in “organization” mode, I feel I just do it better vs doing it hastily on the spot. I find more connections and I believe I am also faster overall.
I believe the same is true for backlogs.
Ideas for new features, improvements, or bug reports, can (and should) come from anywhere: product people, engineers, customer success, sales, or the CEO — and you should be able to capture them properly.
This doesn’t mean though, they need to immediately get into the same backlog from which engineers commit on work to be done:
Put new ideas in a parking lot — captured with minimal structure (problem, suggester, one-line context).
Refine them regularly — turning them into proper stories, or tasks, for the backlog. How this happens largely depends on your team’s context. Cadence depends on your dev cycle and how many ideas you regularly capture. Who does it and how you split work between PMs and engineers depends on your people’s skills and how much there is on their plate already.
Ideally, you want to trend in a direction where:
PMs constantly give good context to engineers
Engineers gradually learn how to make tactical product decisions, so that
Engineers own more work and PMs shift towards strategy
But it’s a journey, and it takes time.
2) Keep backlogs radically short 🗳️
This journey, however, can only happen if you don’t allow your backlog to balloon. Long backlogs are an anti-pattern for many reasons:
They demoralize the team — by removing the feeling of progress.
They are ineffective at capturing priorities — because items stay there for a long time, becoming sneakily obsolete.
They lead you to say yes to everything — this is my favorite: counterintuitively, it is harder to reject feature requests when the backlog is already long, because “it’s just one more thing”. So you put it there, people get pissed when you assign “P3” to it, then you don’t touch it for six months, then it’s completely obsolete, then you delete it and piss the requester a second time.
Mary Poppendieck, Agile legend with 30+ years of experience, says “burn your backlog” every time she can, and that you should rather focus on flow:
Once you’ve established your current output rate, then you have to stop accepting anything beyond that rate. No backlog. If you can only do ten a month, you only accept ten a month. And you don’t accept work beyond a month or two.
— Mary Poppendieck
The Atono team only keeps 2-4 weeks of committed work, which means PMs and engineers reject work all the time. Small feature with unclear impact? Reject. Hard to reproduce bug on niche device? Reject.
So what should PMs actually do? 🎯
The most value PMs can bring is, obviously, through strategic work:
Strategy and vision — where the product is going and why.
Customer research — understanding problems behind requests, not simply collecting them.
Success metrics — defining outcomes, not implementations.
Cross-functional alignment — keeping teams rowing together.
What’s missing? Implementation details. The key idea in product engineering is that engineers own the how, but you have to get there.
Engineers get to own the how when they are given the right context about the why; when they have developed, over time, a good product taste; and when they have good building blocks (design and product-wise) that make it easy to make the right choices.
Without the above, it’s chaos, and PMs need to stay more hands-on.
So how do you get there? Let’s start from an unlikely place: good stories 👇
🎯 User stories are about problems, not solutions
These days there is a lot of pushback against user stories, as there is against Scrum and many formalisms that we have cargo-culted for decades.
Are user stories useful? Well, when I started working as a developer, a lot of our stories looked like this:
"As a user, I want a button that says 'Export' in the top right corner of the dashboard, so that when I click it, a dropdown appears with options for CSV, PDF, and Excel formats."
As a junior dev, I loved these. Zero ambiguity. I know exactly what to build. Ship it, move on.
Now compare it to this other one: