Priority Determines Product

We all want to build useful products.

But each year, 95% of new products fail, in part because they don’t help people solve a real problem (a job-to-be-done). They’re not useful enough.

Priority determines product. When we get overly attached to our initial vision, or race to launch before running out of venture capital, or try to satisfy every customer request, we often jeopardize our own success.

In Running Lean, Ash Maurya advocates balancing the priorities of focus, feedback and learning. Let’s look at how those priorities interact with each other and impact product.

A Venn diagram showing three overlapping circles labelled 'speed', 'feedback' and 'focus', with the intersecting areas demonstrating various risks of product development

Speed

Why we need it: Other things being equal, launching next week is better than next quarter, since it’s cheaper and entails less faith in the future.

How overemphasis causes failure: The pressure to move fast leads to arbitrary features built to keep developers busy. Discovering what will most empower users often requires research, testing, analytics and other non-code tasks that can be seen as ‘slowing’ engineers down.

Focus

Why we need it: A single, shared product vision helps the team to decide which features to include and exclude, avoiding complexity.

How overemphasis causes failure: Companies usually don’t find product-market fit right away. Listening only to founders (or other ‘focus’ leaders) can create products tailored to their needs, and no one else’s.

Feedback

Why we need it: Given an infinite number of potential improvements, feedback from actual or potential users acts as a homing beacon towards utility.

How overemphasis causes failure: Trying to satisfy every customer leads to feature bloat and increases the risk of being undercut by simpler competitors.