Disclaimer: I’ve never been part of a truly massive software project. But I’ve been involved in several efforts where up to 40 people tried to build something useful (and occasionally succeeded!).

Over the years, my responsibilities grew, and I learned a lot - sometimes the hard way.

One day, I might write a post about all the beliefs I held early in my career that turned out to be… let’s say naive. But today, I want to focus on what I currently believe does work - three things I always pay attention to when I’m involved in a software project.

They’re not the whole recipe - but they’re definitely key ingredients. Like salt, heat, and not forgetting to turn on the oven.

1. Choose the Right Team

Give ownership and responsibility to the right people. Define their roles clearly - and give them autonomy. There’s no process, tool, or agile wizardry that can save a project if the team isn’t right.

The right people understand the goal, take responsibility for moving toward it, and collaborate well with their teammates. They don’t wait to be told what to do—they own problems. Together, they create a team atmosphere where people feel safe to speak up, share ideas, and challenge each other constructively.

So get the right people. Give them clarity. And hold them accountable.

2. Get Real Feedback

Push the product out to the customer - early and often. Real feedback only happens when real users interact with a product they care about. Everything else is a proxy.

Yes, there are plenty of UX techniques like Journey Mapping, Design Sprints, or customer personas. Some of them can be useful - especially for structuring or visualizing feedback. But none of them are a substitute for the real thing: watching a customer use your product.

It’s humbling. And sometimes painful. But it’s also the fastest way to learn.

3. Own the Result

Someone - you or someone you trust - needs to obsess over the value the product delivers. Not just the backlog. Not just the deadlines. The value.

Too many projects fall into the trap of worshiping the ticket system. But a backlog is just a list of educated guesses. It’s not the customer. It’s not the product. And it definitely doesn’t guarantee value.

That’s why you need a person who is responsible and constantly asks, “Why is this a valuable solution for our customer?”

Wrapping Up

Where does my belief in these three key ingredients come from? I’ve seen a handful of software products succeed and stand the test of time. In every one of them, the same patterns showed up:

  • A team of people who trust each other and take ownership
  • They have a healthy obsession with real-world feedback
  • There is someone who truly owns the outcome and keeps everyone honest

In mature teams, these things become second nature. People know their roles, they’re close to their users — sometimes even on a personal level — and there’s always at least one person who acts as an ambassador for the product.

Because I’ve seen these ingredients in action, I believe they form the foundation of any successful software project. Especially when you’re just getting started.