No PMs, Just Builders

Building an AI operating system to transform how work gets done requires a unique approach to product development. At Dust, we've chosen a path that might seem unconventional at first: we don't have product managers. Instead, we've built a culture where engineers are directly responsible for the product's success from inception to delivery.

The problem with traditional product management

At many companies, product management creates an artificial translation layer between customers and engineers. The pattern is familiar:

• Product managers gather feature requests from founders or sales
• They distill requirements to the bare minimum for engineering
• Engineers build as many features as possible
• Repeat

This creates a disconnect where engineers work with incomplete context, missing the crucial information needed to make the best decisions locally. The common belief that engineers need to be "shielded" from business and product concerns to focus on coding actually hinders their ability to build the right things. At Dust, we believe engineers need to be at the heart of product decisions, with full context and ownership.

The engineer at Dust

At Dust, we build our engineering team differently. Each engineer acts as a Directly Responsible Individual (DRI) for product initiatives, owning them from conception to delivery. This isn't just about writing code – it's about shaping what we build, why we build it and communicating it to the world.

Our engineers don't wait for product requirements to be handed down. They dive deep into user problems, working closely with the design and user operations teams from day one to shape solutions. When they write code, it's with full context of the business challenges and user needs they're addressing. This direct connection to the problem space leads to better decisions and more impactful solutions.

For example, when building our Spaces feature, the engineering DRI led user discovery sessions, worked with design on information architecture, and made crucial decisions about the permission model. This deep involvement meant technical constraints and user needs were balanced from the start, not retroactively reconciled.

The DRI model: Clear ownership from start to finish

Every product initiative at Dust has a Directly Responsible Individual (DRI) – typically an engineer who owns the project's success end-to-end. From user discovery through implementation to launch and monitoring, the DRI ensures the project delivers real value to users.

This doesn't mean DRIs do everything themselves. Instead, they orchestrate the effort, ensure context is shared, and drive effective decisions throughout the project's lifecycle. They work closely with design on user experience, coordinate with marketing for launches, and ensure proper documentation and support are in place.

How it works in practice

When starting a new initiative, DRIs begin by immersing themselves in the problem space. They collect feedback, conduct user interviews with the ops team, and synthesize common themes. Working closely with design, they shape the initial direction and write concise specifications that help everyone understand not just what we're building, but why it matters.

During implementation, DRIs coordinate with design and engineering teams, making trade-offs and adjusting scope as needed. They identify early users for beta testing, gather feedback, and work with marketing to plan the rollout. Throughout the process, they maintain a clear view of success and monitor adoption after launch.

Why this works for us

We're still a small team, with 60% engineers. This structure allows us to move faster by reducing communication overhead and keeping the whole team close to the product and our customers. When engineers have true ownership of what they build, they make better decisions and maintain higher standards through direct responsibility.

Will we always work this way? Maybe not. But for now, this approach enables us to be leaner and more effective in our mission to transform how work gets done. It's common at Dust not to be a PM, but to PM projects – and this flexibility lets us adapt and evolve as we grow.

If you're excited about having true ownership of what you build and being close to users, we'd love to hear from you. Check our open roles.