Entrepreneurship for Engineers: Building for Customers’ Love
Engineers build things. But just because an engineer can turn incredible ideas into reality doesn’t mean that the products made by the best engineers out there will be a success. Perhaps they’ll be bug-free, scalable, reliable and secure. But building great products is not the same as having the engineering know-how to make product ideas a reality.
“I’ll never forget, I worked on this great product called OpDemand,” said Gabe Monroy, chief product officer at the cloud infrastructure provider DigitalOcean and a former startup founder. “And it had all the bells and whistles, was super cool, the UI was spectacular. I was very proud of the team, very proud of the product. And the product failed miserably.”
If being a great engineer is about knowing how to build functionality, having a great product mind means knowing what functionality to build. And there’s only one way to go from great engineer to great product leader. You have to talk to your customers.
Empathy for Your Customers
Counterintuitively, sometimes cultivating customer empathy — and really understanding what your customer needs — gets harder when you see yourself as part of the target market.
Often engineers will start a company to solve a problem that they’ve personally experienced. This is an excellent starting point for building a product, but can also lead engineers-turned-founders to erroneously think they understand more about their customers than they actually do.
“There is a failure mode, when you’re building products for developers and engineers,” Monroy said. “When you come from an engineering background, you can sometimes convince yourself that you are the customer, because you are a developer, you are an engineer. That can sometimes send you in the wrong direction. You need to be mindful of your biases.”
Particularly as the company scales, it’s important to understand the limitations of drawing on your own experiences for product decisions. And even when you’re relying on your instincts, it’s important to test those instincts just as you would test code.
In working with his engineering team, Rob Faraj, founder of Stackwatch, creators of the open source tool Kubecost, which tracks Kubernetes spending, said that he asks engineers to think about testing in two ways: One, where you test your code to make sure it works. But the second is product-oriented testing to make sure that the feature you’re trying to build is valuable to customers.
Part of that validation is talking to customers and understanding their needs before you even have a product for them to try. It also requires getting the product into their hands and talking with them after they’ve used it — watching how people interact with the product, through screen captures.
“When you watch a customer just banging their head against the keyboard, failing to use your product, you think about the world very differently,” said Monroy.
And once you’ve seen how they use your product — or spoken with them about it — you may find that reality doesn’t align with your instincts. When that happens, “you have a big decision to make,” Faraj said. “Are you going to eat a piece of humble pie?”
Because that’s exactly how it can feel to realize that an assumption you had made, based on your own experiences as an engineer, did not actually reflect what your customers want.
What Makes a Great Product Leader?
A great product leader is also asking themselves and their team different questions than an engineering leader. “The great engineer is really focused on how to make this thing work,” said Eitan Joffe, founder and chief technology officer at Inigo, a GraphQL security platform. “The guys who are focused on making a great product focus on the value it brings to the end user.”
This subtle but important shift means asking and understanding why — or if— users care about a particular feature before thinking about how to implement it. In many cases, great engineers are also very careful to ship high-quality code — which is good in many situations, but can slow down the process of iterating on a product and getting good feedback from users.
As a result, product leaders generally push to move faster, and they have to find a balance between quality and frequent iteration.
None of this is to imply that the pure engineering perspective that wants to get rid of technical debt and ensure high-quality standards is important — just that it needs to be balanced with the needs of the customer and building new features.
“I see the prioritization of tech debt as a major friction point,” between product and engineering, Faraj said. At the same time, often product leaders are frustrated by engineering teams’ lack of enthusiasm for building new features.
Asking the Right Questions
Communication with users and customers is the key to being more product-focused than pure engineering-focused. This often comes naturally at startups, where even pure engineers have to wear more than one hat and are expected to interact with users and customers.
In contrast, at many big companies individual engineers could have very little idea how the projects they’re working on are used by customers, or why those customers care.
But just talking isn’t really enough — you have to ask the right kinds of questions. Monroy likes the “Jobs to Be Done” approach, where you try to understand what job your customer is hiring your product to do and how else they could get the same outcomes. The key is to keep the discussion centered on desired outcomes and needs, not about the product itself.
“If you ask them, ‘What feature are you looking for?’ or ‘What would make you excited about my product?’ it’s a big challenge to get a useful answer,” Monroy said.
Making the leap from thinking about just engineering to thinking about why people care about your product can make or break a startup. When Monroy was creating his first startup, he spent roughly $1 million on research and development, he said, “building super cool products.”
“I was very proud of them,” he said. “Only to realize it didn’t meet customer needs. They were confused about the marketing of the product and why it existed.”
Monroy added that if he’d just created some slides to show a mock-up of the product, then talked to five or 10 customers, he would have saved all that money, de-risked the entire company — and the company would have been more successful overall.
