We aren’t building features, we’re solving problems

“Maybe this feature sucked because we got too focused on shipping a solution vs. solving a problem.”

I recently heard an engineer pontificate the above as the rationale for a half-assed feature still living in our product. And he was probably right …

In the midst of shipping a new, big feature, it’s incredibly easy to lose focus on why we decided to undertake this effort in the first place. Every product we build should be in service of meeting some customer need. However, somewhere along path between conception and shipping, it can be too easy to veer off course and fixate on the tactic (i.e. the feature).

This can lead to poor outcomes for a few notable reasons:

(1) The tactic is probably wrong. 
Solving problems is really hard. It’s unlikely we’ll nail the solution on the first try.

(2) Shipping becomes success. 
Shipping alone doesn’t help anyone.

(3) The team isn’t empowered to course correct. 
As PMs we want the whole team (from engineers to designers and marketers) focused on solving user needs — this won’t happen if they’re fixated on getting one feature out the door. And after that feature is shipped, it makes improvement difficult as people are lacking the right context to find problems / offer solutions.

(4) Encourages optimizing vanity metrics (i.e. usage). 
It encourages driving up things like usage, which may actually create more problems than they solve … have you seen LinkedIn recently? 
So, as a team moves into implementation, keep them focused on why they’re here and what problem they’re solving. The features we build along the way are just tactics implemented to bring closer to filling a user need.