Does the desire to build cool new things override the customer needs? In other words, a programmer’s itch and urge to scratch it is crucial to retain them.
Claim: Good technologists leave if they’re not constantly building cool stuff, even if that new stuff is not relevant to the customers. (see tweet below)
It resonates with me, but …
That’s a compelling claim coming from Paul Graham. I understand where he is coming from, and can resonate with my engineering and managerial background. But, on the flip side, I also cringe at that claim in my current role — as a product manager. It’s not a pretty place to be between retaining top talent vis-a-vis focusing on customers’ Jobs-to-be-done.
I left at least one job in the past for a craving to work on a more modern tech stack. But I also wasted my share of time building cool new things underutilized by the customers.
As a Manager, I have had my share of pain in losing good programmers. Nevertheless, our tech stack was competitive, even if it doesn’t count as a bleeding edge.
So, I understand the phenomena. But, at the same time, it’s troubling because it’s painful to spend time, energy, and capital to sustain resume-driven development. You deliver stuff because your engineering thinks it’s cool. But, then, are you on the path to becoming a feature factory?
Our customer needs are fuzzy.
Some argue by citing examples like, “Hey, look at what Steve Jobs did. He never asked customers what they wanted.” Had they asked their customers what they needed, they would not have built the modern innovation. Undoubtedly that’s a compelling argument. There are also many other famous figures, from Ford to Musk. You get the point.
These kinds of arguments are not against finding customer needs. It’s more about “our customers don’t know what they need.” So keep on building the cool new stuff. Indeed, customers will embrace it.
How well do you know your customers’ needs?
In a direct-to-consumer business, you have many ways to use the solution as a software builder. Eating your dog food is much easier in that D2C setting than in a business-to-business (B2B) one. For example, if you’re creating an email client, chat app, or maps app, you can impersonate a user significantly. Another example is you’re building a next-gen car with incredible new Artificial Intelligence. In all these cases, employees are also end-users.
However, in many B2B settings — healthcare, fintech, et al. — you may have some instincts, but you need to walk in your customer’s shoes to get deep and meaningful insights. For example, think of claims processing systems or commercial loan origination workflow.
As you can see, there’s no universal right or wrong. Instead, your knowledge of customer needs depends on the context of the product you’re building and your target customer segments.
Make your developers part of customer needs discovery.
Regardless of D2C or B2B, build a culture where your programmers are part of the discovery process. When they’re an integral part of the process, they have skin in the game. That’s critical. It helps move the mountains. From my own experience, the attitude shifts by taking this approach are refreshing and welcome. But, of course
Just by this cultural shift alone, you may see more programmers shifting their lens to customer needs than myopically focusing on the cool new things. But, please do note a modern tech stack is essential. Once we baseline the tech stack, it works best to stay focused on the customer.
Without good programmers, there’s no path to success. Period. I’m talking about 10x programmers and not the 10 percent incremental kind. The former can singlehandedly change the trajectory (assuming they have interpersonal skills with their technical chops). It’s essential to center around the customer’s needs as much as possible. Making your programmers part of the problem definition may get to a good place. A place where they think of — “scratching a technical itch is nice, and it’s even better if I can align my success with that of customers.”
As always, I’d love to hear about your experiences.