Haters gonna hate.  Engineers gonna build.  Unsurprisingly, engineers are drawn to the challenges that interest them: reliability, scalability, and reduced technical risk.  In a product space where Market Risk dominates (see Part I), these are the wrong priorities.

A lot of startup advice makes sense when you realize it’s designed to address market risk not technical risk.  YCombinator basically exists to beat entrepreneurs over the head with this lesson – same thing with the Lean Startup methodology.

• Get out of the building and spend time with potential customers.  In other words, stop coding (addressing technical risk) and start validating your market hypothesis.
• Do things that don’t scale.  Because who cares how scalable it is if there’s no market?  And by the way, there’s probably no market for your Airbnb-for-garden-tools startup.
• Build, Measure, Learn.  If you do have to build something, build just enough to start testing whether there’s a market for your product.

Even if you have a large amount of technical risk that needs to be addressed, don’t forget the market risk.

Consider the agile software development movement.  It began more than 20 years ago in the contract software development community, and was designed to address the high percentage of failed projects.  Since a lot of contract software development is for internal systems, there was an assumption of product-market fit embodied in the requirements.  However, all too often the resulting product failed to properly address the needs of the contracting organization.  It wasn’t that there was some technical invention missing – but rather that existing technology was shaped into a solution that failed to solve the problem.  The first principle behind the Agile Manifesto is:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This addresses technical risk – ensuring subsystems work together as early as possible.  It also addresses market risk by providing regular checkpoints to validate product-market fit (even when there is someone writing a check who says they know what their organization needs).

But be careful!  Agile approaches don’t necessarily address product-market fit.  In a product company, building something in sprints doesn’t protect you from building the wrong thing in the right way.  If you aren’t validating the market as you go along (or better yet before), you’re just addressing technical risk (which is good, but not sufficient).

I was delighted the other day by an engineering manager who really demonstrated an understanding of technical risk vs market risk.  When discussing whether to put together an engineering team to start building a product – or use a more lightweight rapid-prototyping and piloting approach (that may need to be replaced if the product succeeds), the engineer manager said:

“I know we can build something that scales, what I don’t know is if the product will succeed”

That pretty much sums up most startups these days.  So spend more time finding out if the product will succeed and trust in your ability to scale.