When product management rules are broken – A day in the life of a startup

Ask, ask and keep asking – you just might get it!

Any product manager knows the importance of building new product features based on  user requests.

A common dilemma that exists among product managers is whether or not to implement a particular feature (that is not on the product road map) based solely on the request from a customer.

Why does this dilemma exist?

1. Limited number of hands-on-deck (more like no hands on deck)
2. The said feature may only be useful for the small set of users who made the request
3. Not knowing the market impact of the feature

Through the initial iterations of your product, most feature requests will fall into the category of “immediate”. But as your product matures (like fine wine), and you have a fair idea of where the product is headed, you go on to streamline your development process and product road map.

Then comes a time (quite often too soon), when your engineering team is working a 150% building planned features. And you  get a customer with a particular feature request that has not been planned at all, but you decide to take it up anyway! It is against conventional wisdom that gets repeated over & over again that you can’t take up a feature request immediately just because a single user requested it. Now, it’s a well known rule (well at least according to some popular blogs) or rather conventional wisdom not to take up a feature request just because one person asked for it. And we broke this rule (twice this month!).

On a (blue) Monday, a customer reached out to us asking for a feature (top-secret for now), and they needed it live by EOD Friday! Why? They were doing a nationwide campaign over the weekend and they couldn’t do it without the feature.

Why did we agree to doing it?

Well, because we love our customers. And our guts said so!

Frankly, we were just getting really tired of quite too often using the phrases “we’re working on this already” and “this is a great idea, we’ll add this to our feature list” even though these were sincere responses. In this particular case, this was the first time someone asked for this feature and we could have waited for others to ask to know if the ‘market’ needs it before doing it. But we didn’t.

What did we do?

Roped in our top 3 product ninjas developers, had a quick discussion (more like 2 and a half hours) about the requirements and implementation tasks involved.

Started building the feature early Tuesday morning, with just the bare essentials. We stripped out the UI frills (which usually takes about 70% of your time to plan, design and implement), and it was just pure modeling & API. We had the feature ready for testing by Friday afternoon.

Had our customers try it out late Friday evening and they were all set for the campaign Saturday morning.

What did we learn from this?

The entire activity went on to emphasize the one message we want everyone in our team to internalize – that is we will do everything within our powers to keep our customers happy! And we are super proud of it.

Well, it was certainly worth it. Our customer was extremely happy to have us as their billing partner and we were proud of what we could do to help them succeed.

So should you just stop doing what you’re doing and take on a new feature request?

If that’s what your gut says, do it. Because in the end it’s up to YOU to decide which ones and when to implement them.* And going by your guts is one of the true perks of being in a startup!*