‘A Bigger Button’ – The story of a feature request.

The head sales guy, or maybe the CEO just came back from a meeting. You can tell he is pumped up about something. A tinge of sweat is showing through his button-down but it’s really the crazy eyes that are the dead giveaway. You look back at the screen hoping that the server error that just came up will provide the needed distraction to signal him that now is not a good time. Maybe he is respectful and shoots you a message asking to talk later, but more likely he taps on your shoulder. *Tap* *Tap*. Putting down your headphones you swivel your chair around slowly. It could be that he found a bug, but this is worse. A feature request.

You’ve done this before. You check the server error once more. Nothing important just the junior developer trying to kill the Vertica server.

“How’d the meeting go?” you ask.

“It went really well. I think they could be our largest client.”

You’ve heard that before, but where would a startup be without larger and larger clients. You know this is the pudding before the vegetables.

“Oh excellent! Did you get a signed contract?”

“Next time. It will be easy, they love our product and can see the many use cases, but they want the login button to be a bigger. Is this possible?”

“Of course it’s possible, it just might take a while and we are still slogging through the model for client Y.”

You’ve never made a login button bigger, but on IRC (internet relay chat) people are talking about using HTML9 and a new javascript library that should make it possible.

“Oh yeah client Y can wait on the model. They still aren’t signing the contact, their legal team is slowing the whole process down. I mean the bigger button can’t be that hard, you guys managed to reinvent the wheel in two weeks when you said it would take three.”

Damn ‘wheel’ timeline. It was much easier than originally expected because someone had already invented it. Ron, the senior developer, just had to adjust the machine code to work with the new javascript framework that had a minor glitch.

“Yeah, Ron did a really good job with the wheel, but this larger button is something I’ve never seen before. I’ll have to go through the documentation. In fact I’m not even sure it’s possible.”

“Wait. I thought this was only going to take three months?”

“Well, we have another week or so finishing up the model, like I said, and then this button will take some time.”

“Ok, I’ll tell them it’s in the pipeline and expected to be done by the end of January.”

The sweat had subsided and his eyes are coming back down. Time to get all the details out so that we don’t have another ‘big data’ situation where the request was not properly defined and we ended up building a Google competitor, when all biz-dev wanted was a Snapchat.

“Did they tell you why they want a bigger button?”

“No, but after talking with a couple other clients it seems that everyone is accessing the site on their mobile phones, using IE6…  Do we even support that?”

“Not right now, but I don’t think that will change our timeline and it’s good to hear that other clients are talking about this. Nobody mentioned it to me in my last meeting with client Z when I was going over implementation.”


After working on both the business and the engineering side of the feature request ‘story’, I have grown to appreciate the balance needed to make these conversations go smoothly. It’s easy to forget the context that fuels the business drive for features and the engineer’s propensity to say no. It’s trite, but you have to put yourself in their shoes. Try to remember where your teammates are coming from, be patient, and always ask clarifying questions. As an engineer, I’ve learned not to say ‘no’ as much and I now remind the business folks to count to 20 before they take a feature idea from a client meeting and hand it over to the engineering team to evaluate because, once that meeting energy subsides, they can and need to be an idea filter. As my role at SimpleReach grows to involve more of these discussions, I only hope that I can continue to use this balanced approach so the both sides feel like they are on the same team because in a startup- that could be make or break.


About Nick

A business guy turned developer. Now building cool things at SimpleReach.

View all posts by Nick »
  • 122 W. 27th St, 7th Floor
  • New York, NY 10001

Privacy Policy