Technical Risk vs Market Risk, Part II

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.

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.

About brendansterne

Director of Innovation Labs, Indeed.com
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s