Venture Capital and Future Tech - a Reading List

Reinventing the Past

In a prior post, I wrote about my experience with a food startup.  It was a small window into venture capital, a small, but vital part of new economic growth.

I was reading a Harvard Business article about how venture capital works.  Among other things, I learned that being a good VC is about knowing how to take only those risks you can control and in the right industries (read, growing industries).

I shared the thought with an industry veteran, and his reply was that a lot of VC success is just "luck."   For instance, food delivery business only became a growth industry because VCs were pumping so much money into it.  He said:

"Anything looks good if you pump enough money into it."

Sounds plausible.  The disparity between skill and luck, and the dynamics involved in outcomes made me want to learn more.

In many ways, it's an old story about the force of technology driving businesses to become more efficient.  It's about the good enough solutions dislodging the best, because it's cheaper and easier.  Simply, consumers want it.  Yes, it's an old story, a la Innovator's Dilemma.

Tidal Forces of the Web

In Paul Ford's: What is Code? Ford notes how the profession of programming is very adaptable to change.  Languages written to solve one set of problems is often (inevitably) adopted to solve a problem in another.  For example, with V8, JavaScript could run outside of the browsers for which it was designed.  Now, it could read files, send emails, erase your data, and made the client a server.

In this "flow" of the river of software, we often observe trends toward:

• abstraction (of information and processes)
• adaptation (one solution applied to different use case)
• universality (good patterns can be repeated anywhere)
• acceleration (solutions enable other solutions)

These trends have resulted in pretty drastic power law outcomes, where you have few big winners, and then everyone else.  How should the modern professional adapt to this reality?

How You Can Keep Up - Great Books About Tech

Perhaps the easiest and the best thing you can do is to read good books.

Great books.  I was particularly interested to read more into the VC world, because it's a bridge to the traditional world of finance.  And importantly, I think it also sheds light to the financial incentives so key to driving change.

In a way, this is a contrast to the craftsman's focus on just building something great for the sake of building.  There are those whose reward is simply to build something great.  There are those whose reward is to get rich.  In our tech world, both must work together.

Tech, Future, Building

Bold: How to Go Big ... Impact the World.  By Peter Diamandis.

Tomorrowland: ... Science Fiction to Science Fact.  By Steven Kotler.

Hackers and Painters: Big Ideas from the Computer Age.  By Paul Graham.

Zero to One: How to Build the Future.  Peter Thiel.

More Strictly VC

The Startup Game: Inside ... VC and Entrepreneurs.  By Bill Draper.

Mastering the VC Game.  By Jeff Bussgang.

Venture Deals: Be Smarter than ... Your VC.  By Brad Feld and Jason Mendelson.

Taking Assembly for a Test Drive

I have been taking the web product Assembly for a test drive.

Assembly is a platform for crowd-sourced web-based products.  A product for product development online.  Sounds like recursion!

It's got to be a dream for programmers and web geeks!

Product Description and Traction

Assembly is really interesting, just because you get to see what other people are thinking about, in a transparent way.  The product seems to have solid traction based on cosmetic review of the activity.  Here are some key observations about this product.

Coderwall Project bounties and contributors (from Assembly)

• Virtual - The projects are mostly virtual from around the world.  The landing page is filled with many approved and pending projects.  A large product like Coderwall has 100 contributors, although contribution follows a steep power law distribution (probably even more than 80/20 rule - meaning 5% do 95% of the work ... the nice thing is, they are paid accordingly). 
• Platform - The diversity of products is as wide as people's imagination.  Of course, what Assembly provides are the building blocks (see below) of a web product building.
• Revenue Positive - As far as I could tell, Coderwall is its most profitable product; based on 2014 payouts, it seems to have about $24K MRR with 86% profit margin.  Wow!
• Engineer Heavy - I've joined a few products and started one to test the default experience.  I don't have hard figures, but based on new people who sign-up to a project, the site is engineer heavy, followed by designers, followed by non-technical people.

What Are the Building Blocks of a Web Product?

One of the reasons Assembly interested me was that the product makes you think about what the building blocks of a web product development are.

https://assembly.com/discover

In essence, Team Assembly would have had to deconstruct the core elements of software development, and so doing, virtualized and abstracted a traditional coming together of a team.  Abstraction and virtualization are both long-term trends in the software-centric world.

So, apart from that interesting academic question, here's my hypothesis about what Assembly believes are core building blocks.

• Software engineers - Which is great, because a platform like this would be self-selecting to software engineers who are used to working "in the web."  Remote working is a norm in this community.
• Comprehensive communication - Communication is key in product management.  Many good vs. bad outcome can be traced back to good vs. bad communication.  Assembly uses Slack threads for each project you join.  Seems like a good solution.
• Project management - This seems to be a missing piece of the platform.  Teams likely will use a Trello board or Google docs outside of Assembly.  The communication threads are nice, but not sufficient for serious collaboration. 
• Version control - Assembly-built products are linked to Github repositories.  There is no separate bug tracking here, but can be managed through communication threads and pull requests.
• Incentives - I think Assembly's solution is particularly novel and effective.  I think it is very meritocratic, because coins are awarded based on contribution.  The overall model is very Silicon-Valley-esque. The founder holds the lion's share of initial coins, and if everyone maxes out the contribution efforts, the founder's holdings can be diluted down to 50%, and everyone else holding 50% ... unless founder herself is doing a lot of work and awards herself.  Apart from monetary incentive, the product also leverage's people's sense of curiosity and personal value. You can say, "hey, I'm only a designer, but I can add this little piece to the overall effort!"  And so on.  For many, I would say, money is a distant second or third incentive.
• Team Trust - This is another challenge.  Trust is really hard.  Most startup teams at least, fail because of bad founder selection.  Here, the process is just left up to the wind.

What else is important to building a good product?  Really, it is customers, and a good process to deliver what those customers want.  That's it.  If you don't have customers, things like project management, engineers, and everything else doesn't matter.  Only thing is, some startups start out with a hypothesis they can get customers, and start building.  But, in the end, you need customers.  Communication, version control ... don't get lost in the details.  

It's just tools and processes to serve the customer.

Assembly's mix of light-weight and mostly off the shelf tools is an interesting approach to discovering better ways to build for the customer.

You Might Also Like ...

Are you a product manager?  What's your philosophy and approach to building great products?

You might also like the following teardowns and meta talks on products:

• Hierarchy of product love
• Hotel Tonight room price triggers
• Prosper 1 Click - Not Really and 404 

Never give in. Never? What's your dream?

Repetition => Pattern Recognition

A friend, who is studying to be a dermato-pathologist related the following story to me.  Paraphrasing:

"As a skin/cell doctor, you basically look at cells under a microscope all day.  And they all look the same (it is frustrating day in and day out).  Then, six/seven months in, something happens.  You begin to see the differences with confidence.  You can tell apart a sick cell from a healthy one, one cancerous type from another ..."

So it goes.  It reminded me of learning English as a second language when I was 10.  At first, everything sounded like the gibberish in a Charlie Brown cartoon.  Wawawa - wawa.  Then, one day (or phase of days), it falls into place.  "And there was light. And it was good."

I wonder what happens if the resident gets discouraged and gives up at month five.  Or what if it takes longer than six months to begin to have the patterns fall into place?  What if it takes longer than a year to learn a foreign language, and you still find yourself among foreigners?

Most patterns in life don't stand out quite so easily

(On a side note, there is a fascinating history with a 1977 Architecture book called A Pattern Language by Christopher Alexander. Some of the patterns we needn't learn from scratch - they have been documented!)

Dream vs. Reality

Of course, one could always give up on a dream - startup dream or dream to sing or whatever.  For a new entrepreneur, there are challenges galore.  Why bother?  Why not re-apply for a comfortable six figure job with a big name company?  Don't you want that nice apartment?  Don't you want that new car? C'mon, it's not giving up - you're just taking the smarter way to success.  So it goes.

Success, however you measure it, is about persistence.  And it is about learning to be resourceful (and resourcefulness can help you sell your first "lemonade").  You start somewhere, and being resourceful, you persist and make it (make what?) better every day.  Then, one day, there was light. And it was good.

As with learning a new language, it seems that sticking around and persisting really leads to result.  And just to be clear, persisting doesn't mean inflexibility.  Truth is, you will be changing your ideas and approaches all the time.  Rather, persistence is about making progress.  And the question may become more about how to optimize progress, rather than whether there will be one. So, when you become discouraged or become tempted to take the easy way out, consider stepping forward rather than stepping back.

"Never give in. Never! Never! Never!"

I admit, I don't speak entirely out of experience. Much of it is out of faith. After all, I am still learning and growing - including how to code. And I am exploring a new venture (calling it Talent Tap for now), after failing with a previous one.

I am comforted by the words of those who had faith before me.  At the risk of being overly dramatic, I find it fun to record Churchill's words from his 1941 speech at the Harrow School:

Churchill exhorting a nation to hang in there.

Doing vs. Thinking

And hitting that tipping point, where patterns come together, where momentum builds is not just about thinking and planning. Instead, it's more about iterating by doing. Sometimes it takes a bit of an attitude shift. And with that, I'm going to try 12 days of building.

Silicon Valley's Tech Talent Hegemony Endures

How does one build a magnet for talent? It is a question equally important to cities and to teams working in cities.  One of the favorite past-times among tech people is whether Silicon Valley's glory days are over.  For example, an article recently featured on LinkedIn: "Why Silicon Valley's heyday might be over." (It stood out to me that the title suggests lack of confidence about the assertions.)  Rankings are like comfort food. They are dime a dozen (see Startup Ecosystem Report) and are like debates over religion or politics. Useless. This kind of debate misses a key point. Instead, your sole focus as an entrepreneur, a serious technologist, or political/business leader should be to focus on the attributes that produce outcomes of a successful startup hub, and decide whether you can locally produce those (or better) attributes or decide (as many do) to move to San Francisco.

Did I say San Francisco?  Well - I won't digress - it's yet another fun debate, but you can read about it in this article written by Hermione Way.

Deeper thinkers like Paul Graham get the point. In a (more confidently titled) article "Why Startup Hubs Work," PG outlines 3 factors that explain success of startup hubs: 

1) Environment,

2) Chance, and 

3) Numbers.

PG explains that #3) numbers is an underlying driver for the first two important factors. "To make a startup hub, you need alot of people interested in startups." In other words, density of right talent is a key driver for success of ideas, of innovation, of teams that capitalize on opportunities, and of successful tech companies that grow from those small teams. PG originally frames this problem in the inverse, noting that successful areas reduce the attrition rate of failure: "Somehow it's as if most places were sprayed with startupicide."

To be sure, this idea is not new. Density is a pre-requisite to ideas having sex, as elaborated in this popular TED talk by Matt Ridley.  Economist Richard Florida also studied this theme extensively and coined an entire academic sub-discipline around the Creative Class.  We, the People, have known this for millennia. When first hunter-gatherers settled into cities, all sorts of innovation happened: irrigation, plows, granary to store crops, military to protect the crops and settlements, weapons to steal neighbors' crops and settlements, rule of law to avoid such conflicts, and on and on.

What about the Internet?

Yes, internet has democratized exchange of ideas, but those outside of SF miss the simple truth. Tech people who live locally have internet AND the meetings that take offline.  Do you have that, RTP? Berlin? Vancouver?  Does your Ruby meetup group have 6,000 members and meet almost every day with dozens of organizers and hosting different events for different audience?  Do you have comparable sized communities around JavaScript, around node, visualizations, machine learning, etc?  I'm not bragging. Instead, step back and think about the causes that lead to this reality.

I'll make one more point on the effects before going back to causes. It is a cursory and high-level evidence that SF's tech hegemony will accelerate, and not slow relative to competition.

Natural phenomena generally follow a logistics curve - an exponential growth followed by inverse version flattening out to an asymptotic line:

Key question is whether we are at a turning point

Implication => If we have not reached a point where deceleration of growth has been reached, then SF will continue to outpace competition, because the growth is exponential.  If you actually live in SF, then it's not difficult to believe that we have not reached that turning point. Things are blowing up. Every day.  

Let's come back to point.  Rather than envy SF's leading position, focus on outcome and how you can also build it. Specifically, how does one build a tech talent magnet? What are the attributes that attract tech talent?  It seems at times that SF has cornered the market on this problem.

More to come

In a future post, I'll delve into what is visible and what lies underneath the visible layer.  In so doing, I will explain why features noted by critics like "high cost of living" or "fierce talent for engineers" totally miss the point.

• How SF Tech community differs (macro-analysis)
• Building a better (talent) mousetrap (micro-analysis)

There are some interesting implications.  For example, large companies that do not have a strong presence here may want to reconsider their future headcount investment.

Stay tuned!