Why New Features Win Out Over Fixes
Back when I worked for The Startup, my job also included some Q/A testing. I took this aspect very seriously, since as the Community Lead, I saw myself as the public face of our product. When our users—or would-be users—ran into technical trouble, I’d lobby for a fix. The on-boarding process was a particular sticking point. It was a multi-step, multi-page mess, and people often abandoned it halfway through. They’d still be registered, and we could count them in our user numbers, but they never came back.
Our CTO was more interested in rolling out new features than fixing core functionality. When nobody used the new features, he blamed me for not promoting them enough. When they did, and they broke—which happened a lot—I took responsibility, falling on the sword for our users. If you paid $99 to post a job, and ended up with no listing, but a charge on your credit card, swooping in and making it better with a free upgraded listing is bound to make you feel better.
The CTO disagreed. Vehemently. He’d grudgingly get around to a fix, while conspiring with the Founder to propose and built out another quarter-baked feature at the next Scrum. Meanwhile bugs and issues languished, despite piles of tickets in Jira—which the CTO administered and used to set priorities. When I pushed back against shifting the focus of development away from the core product, yet again, towards the new job board feature… well, that’s when I knew I was on the way out.
This isn’t a problem exclusive to my former employer, or even to startups. It’s prevalent enough that there’s multiple names for it: “Shiny Object Syndrome” and “Featuritis” for example. New features look cool. You can write a press release or a blog post. It looks like progress, and can even be a driver of user growth. Whether you’re a venture-backed startup who needs to get the numbers up for your next round, or a publicly traded company who needs bigger returns this quarter, new features provide the illusion of progress. Plus new features are more fun to build for the development team.
So when Twitter ignores fixing long-standing bugs that allow bad actors to ruin the experience, or adds and proposes new features like Moments, Polls, and 10,000 character Tweets, they’re focusing on the illusion of progress for their investors. The product team isn’t loyal to the users, they’re loyal to the investors who keep the ship afloat. Worst of all, this is by necessity. Otherwise, how do they keep the lights on and cover the catered lunches for the staff?
There’s only two ways out of this conundrum. The first is never to get into it: to have “a thousand no’s for every yes” as part of the culture from the beginning. A brief look at the technology sector will confirm the rarity of this approach, however. Companies with a culture like this are rarely rewarded, and consequently rare on the ground. This leaves the other approach of having leadership stand up to investors for the good of the product—which rarely ends well.
In the case of Twitter, I can’t see Jack Dorsey having the temerity to stand up to public shareholders to put an emphasis on the tools users need to deal with harassment on the platform. If he wants to keep his gig, he’d be better off proposing new features to grow the company’s audience, get more advertisers, and improve the company’s finances. That’s all the investors care about, which really sucks for the rest of us.