Customer-centric product development

The days of waterfall product development planning are over (unless you work at Microsoft).  Meaning that formal product requirement planning documents, formal specs, development plans etc. all packaged in a linear planning sequence (which make for 12-18 month shipping cycles) are gone the way of the Dodo bird.  However, that doesn’t mean that you don’t do strategic planning around what you develop and why you are spending effort on a feature.  Resource allocation in startups is typically a lot easier than in established, large organizations.  Of course, deciding on what to build in startups doesn’t give your organization a lot of room for error.  One wrong step or a series of wrong bets can cost you the fast mover advantage which is so key when growing market share. 

As long as you have specific priorities, then your functionality requirements are generally very clear.  Instead of laying out every feature by work effort (how many developer days is takes for each feature) and then defining what a release looks like, I like to layer product releases around customer value. 
On the x axis of the grid you lay out the customer pain points while the y axis details the different levers that you can apply to those pain points.  Order the buckets on the y axis from low development investment/low impact to high development cost/high impact (left-to-right).  That will force you to consider (and decide to develop) against big bets versus always making the little bets.  A series of little bets means yet another "me-too" product and no market adoption.  Layering your product development planning around customer proposition wants and needs will enviably force you to build better, more customer centric products.