The Secret to Better Products? Let Engineers Drive the Vision

Halfway through my 5 1/2 years at SpaceX, management decided to change the way we were developing software by giving the product vision to the engineering team. They felt that the traditional way of giving product management responsibility for the product roadmap was creating a layer of abstraction. So they decided to eliminate the game of telephone between the people on the factory floor building the rocket and the people who were actually writing the software for the rocket.

While change was difficult, having engineers responsible for the product vision ultimately led to better product designs. So this approach has influenced the way countless startups founded by former SpaceX engineers have structured their engineering departments—including ours.

Are there challenges in setting up software development this way? Sometimes. Does every software engineer want to be responsible for the product vision? Probably not. It’s important that the product vision is in the hands of the engineers – and changes in the industry and in the software development tools themselves are forcing engineers to upskill in ways that lead to better products and, in my opinion, better careers.

From Ticketmaster to Extreme Owner

At Sift, we don’t have product managers, so we’re hoping to attract software engineers who want to have complete control over how we design our software and what features are in it. SpaceX has a culture of extreme accountability, where people are given more responsibility and are expected to grow into that role, rather than being given a little box to work in. When you put people in boxes, you don’t allow them to reach their full potential. I think that’s why SpaceX has done some really amazing things. In our efforts to build similarly amazing technology, we’re also trying to instill a culture of extreme accountability. How do we do that?

Many engineers are motivated by the desire to solve their customers’ problems – the question is, how much do they experience that through the abstraction of a requirements document, and how much do they actually observe how their customer uses the software? We believe in the latter, which is why our engineers work directly with customers as often as possible.

This way of working is really what drives the original DNA of our product. When we started Sift, our small team subleased space from a company in our network that we knew could benefit from the product we were trying to build. They gave us their data, and we started building software that we knew could help them and countless other startups struggling to build cutting-edge hardware in a growing sea of ​​data. We spent three months in their space, iterating our product. We put together two engineering teams to show them their data in our tool, and had them use their existing solution and the one we were building in parallel. By the end of that time, we had a product they were willing to pay for, and it’s now helping many other startups solve similar problems.

While we don’t set up shop in our customers’ offices, our engineers are directly involved in new customer onboarding sessions—we meet face-to-face to see how customers work in their current tool and watch them work in ours. This helps ensure that our solution is configured in a way that will give them the most benefit—and informs important product development decisions for future iterations of our product. Engineers spend a lot of time in the tools they develop, so it’s not always easy to identify things that are missing from the product or areas where the product is more clunky than it needs to be—spending a day or two with a new or existing customer, actually watching them use it, is the perfect antidote to that. This direct line of communication between our customers and our engineers continues long after the initial onboarding session via direct Slack channels we’ve set up and quarterly meetings with members of our engineering team.

Engineering in the World Post Chat GPT

While this may sound like a “nice to have,” I believe that in a world where more and more software will be written by low-code applications and AI copilots, engineers need to step up. AI will take over more software development and will start doing the simple stuff first. Engineers can do one of two things: focus on work that is deeply technical, or develop a really deep understanding of how the tool is being used, the industry it is being developed for, and the problem it is trying to solve.

We want our engineers to be part of the future, not stuck in an endless loop of taking tickets. Despite what old stereotypes about engineers say, we find legions of engineers excited to welcome a new way of doing things – and that will benefit customers and the engineering profession at the same time.

---

You might like…

Developers and Leaders Disconnect on Productivity and Satisfaction

Report: Software engineers increasingly seen as strategic business partners