No, they won’t.
They already came and left, but you were too busy making a temple.
Engineers have this notion of building this wonderful, amazing software designed by the gods with no technical debt, and at the end of it, this masterpiece of mental reasoning will amaze all who see with its self-evident prowess, and as the masses flock to it, the tired and exhausted engineer will finally lay back and sigh, contented. “Thank god for JIRA,” some equally exhausted PM in the background will murmur as the final ticket is dutifully marked Resolved, linked to the appropriate epic, and adequately labeled.
And while subscribers to this philosophy are busy masturbating over their perfectly built temple, the market has already adopted the slightly imperfect but rapidly iterating solution that’s receptive to customer feedback and constantly validating their market hypotheses.
The fact is, in most situations, you don’t know if people want what you’re about to build. And most people who set out to start a company don’t do the necessary sales work to prove that it’s a good idea. Do you immediately set out to build your awesome product, or do you go around with mocks of your product and validate whether people would pay for it?
The real reason most engineers don’t do any sales is because they all envision themselves as some sort of revolutionary:
If I had asked people what they wanted, they would have said faster horses.
Possibly Henry Ford
Anyone who is willing to face the astronomical odds that all startups go through must believe that they are fundamentally revolutionary, or why would they ever bother with such an endeavor? So it’s no surprise that many don’t bother to validate their ideas with customers.
But this attitude isn’t just seen in startups - it’s prevalent in big companies, too.
Empire builders don’t care about how much work there actually is to do; their agenda is to build a mini fort within the company staffed with loyal coworkers and establish an entire department. These are people who are upset when other teams touch their code base or take the initiative to make impact by doing extra work. Empire builders need to be viciously pruned out of any company.
The fundamental question you have to ask is how often can you get a product to market?
If you say once a quarter, that means you have four shots in a year to do something meaningful, and realistically, far fewer than that. Once you get to market you need to iterate at least two or three times on the feedback received. So if you get to market only once a quarter, with all the experimentation and UI changes, you’re actually looking at a new product every six months.
Process for the sake of process - be it JIRA, ungodly engineering rigor, or any other process - costs the company in very real ways. In the software world, iteration speed directly translates into the number of lives you get. If your team only ships once every six or eight months, management will be extremely hesitant to give your team another chance should a particular product not work out. Six months is a long time.
But if your team has a proven track record of shipping quickly and efficiently, giving another month suddenly seems far more palatable. The only reason processes exist is to make iteration faster. If the processes you or your company follows isn’t leading to faster results, something fundamental is broken.
I can’t stress this enough. Validating product hypotheses with actual market fit is the most important factor for success, and fast iteration is at the core of that. A large company is like a large ship, and getting past the inertia of such a large organization is crucial. Even if you’re going in the wrong direction, if your company has a quick cadence, you can turn yourself around.
But all of this starts at building it, and building it quickly.
Because most of them have already left.
By then you’re grasping at straws.