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!
