Summary

Start-up success depends on rapidly figuring out what customers will actually buy, a process that often requires quickly hacking solutions and other bad software practices for the enterprise. Unfortunately most of us get our tech skills from the enterprise - an environment where cutting corners usually causes more long-term problems than benefits. As a profession we need better practices for lean startups

Life as an Enterprise Software Engineer

I learned most of my technical skills in established (i.e. non start-up) companies doing what most engineers do every day: I solved problems. Problems like “figure out a way to speed up the data processing”, or “get the next customer feature into the release.”

I also learned that there are wrong ways to solve problems, that cutting corners on scalability, security, etc. ultimately lead to even bigger problems later.

For example, anyone who has worked in enterprise software has struggled with poorly designed databases that didn’t scale as the application grows. “Why didn’t they solve this problem the right way (TRW) the first time?”, we mutter, wasting money and time cleaning up others’ shortcuts.

Problems, problems, and more problems. A day in the life of 99% of the world’s software engineers is spent coming up with better ways to solve problems.

Problem Solving in the Enterprise

Life as a Startup Hacker

Actually some engineers do work in such an world - lean startups. In startups both the solution and the problem are unknown. Startups don’t know if they have sufficiently defined the problem and the solution until customers vote with their wallets. Eric Ries gave a great presentation on this topic at Web 2.0 Expo 2009.

From Eric's Presentation at Web Expo 2009

When developing software for a startup, you have to forget all the lessons you’ve learned when building enterprise software for large companies or the government: architecture, design, test plans, security scans, performance testing — all that goes out the window.

–Chris Bucchere, Founder of Crowd Campaign and The Social Collective

And therein lies the dilemma: Much of our engineering training in established companies can handicap us in a startup. I’ll give a recent example from my own experience.

My Experience Handicap

Applications built with Ruby on Rails can maintain relational integrity at the application layer - in other words, you don’t need foreign keys in the database. Many experienced developers argue that this is terrible software development practice.

The link above has some great comments:

We had the same argument here at work. We decided to go down the not using foreign key path in hind sight it’s caused us problems

Bugs in the application resulted in garbage in the database that wasn’t discovered until a couple years and terabytes later. One of my colleagues had the joy of spending 6 months as “data garbageman” cleaning up the database. Trust me, you don’t want to go there. Ever.

Yikes.

So how did I design the database for my most recent startup? Having been in situations where poorly managed database relationships resulted in months of rework, I used foreign keys. That was my experience, and I’m guessing the experience of the developers who made the comments above.

Unfortunately I found that foreign keys in my Rails migrations were a constant source of headaches. Moreover, I decided to migrate to Heroku during the project and had to re-write the foreign keys for Postgres instead of MySQL. What did I learn about customers in this process? Nothing.

In retrospect, I believe I followed bad practice for lean startups building working prototypes. Database integrity is an important issue when you have achieved some measure of success.

May I be so blessed to have these type of problems in my next startup.

Lean Startups are Different

Unfortunately I didn’t find great guidelines for dealing with these software development tradeoffs in the Rails community. The voices of experience advocated TRW to design databases for an established company where the problem is known. And in 99% of cases, I believe they right - just not when you don’t know if you’re solving the right problem.

Arguments like “You do/don’t need foreign keys” miss the real point:

Lean Startups need different best practices from enterprise software development

Am I advocating that we ship buggy code and hire high school students for the engineering team? Of course not. What I am suggesting is that we need new best practices like investing in agility and recognizing that the biggest risk is shipping products nobody wants.

Does test coverage allow a company to iterate faster or does the investment in test code just slow down the learning process? And if you decide to write tests, what parts of an application should be tested? Should you even bother to test the View or can you catch 90% of the problems with simple controller tests? Is Selenium really worth the hassle? (it wasn’t for me) RSPEC?

Do you even need design and color? Or can you learn faster by using a minimalist front-end that supports mobile and desktop customers like 43 Actions.

Resources for the Lean Startup Developer

I predict that this essay will be obsolete in a year. Developers are rapidly learning these lessons and beginning to share best practices. Some resources:

The Google Group Lean Startup Circle

The Lean Startup Wiki case studies.

Lean Startup Meetups are happening in DC, San Francisco, Chicago, Boston, Berkeley, New York

And of course, Eric’s blog, the single best source IMHO. At least until he writes a book, something I hope he is considering.

Summary

Vetting the opportunity - not just the market need - is critical for the lean startup. In ManyWheels we successfully used lean approaches to identify a market need and a solution that solved it. In retrospect we could have saved ourselves months of work by asking our customers for early sales commitments. The sale didn’t matter as much as the customer learning from trying to sell.

Last week I decided to move on from ManyWheels, my second start-up. I had a blast, met fantastic people, learned a ton, and can’t wait for my next startup.

(More on “what’s next for Kevin” in the future.)

What follows is a case study I made to share with the lean startup community. If you’re into lean startups, consider joining a lean startup circle meetup such as the one in DC.

Vetting the Market Need

Last year I began working with folks in the automotive market to explore an automated dispatching and routing application for shipping cars. Picture a service like Expedia that allows car dealerships, auctions, rental car agencies, etc. to automatically schedule and dispatch vehicles for transport.

We spent several months talking to everyone in the industry we could find. We learned how relationships and contracts are structured, how data flows, the motivations of different players, and the current shortcomings of existing solutions.

During this process we found a group at one of the largest corporate players in this market – I’ll call them “BigCo” – which provided us tremendous insight into the market needs. The team at BigCo had thought a lot about the problem and cobbled together technologies to find a solution. The situation read like a page out of 4 Steps:

You’re almost there: you’ve found a customer who has such a desperate problem that he has had his own homegrown solution built out of piece parts.

–Steve Blank, 4 Steps to the Epiphany, page 35.

We started proposing solutions to BigCo and screen mockups of different ideas. At first they rejected almost all of our ideas, but after a few iterations they became more interested. Eventually we got to the point where the conversation turned to “when can I get it?” They started taking the idea into new directions beyond what we had envisioned.

We expanded our conversation to other prospective customers and got similarly positive reaction. We reached the point where we felt comfortable building a working prototype.

Prototype Development and Pilot Projects

We asked BigCo if they would be a pilot customer but they advised us - and we agreed - that BigCo was too big for a first customer. We decided to go ahead the build the working prototypes and look pilot customers during development.

We found a smaller-market pilot customer - I’ll call them “SmallCo”. Our working relationship with SmallCo was even better than BigCo. Not only did SmallCo have the same problem and want the same solution, but we worked directly with the owner/operator who was in a position to make purchasing decisions. The SmallCo owner also a leader in industry groups and seemed like a classic earlyvangelist:

We need a word to describe visionary customers – those who will not only spread the good news about unfinished and untested products but also buy them. For that reason I often refer to them as earlyvangelists.

–Steve Blank, 4 Steps to the Epiphany, p. 34.

We cut all but the barest of features and got a working tool in the hands of SmallCo as fast as we could. We seemed to be firing on all cylinders and everyone started getting excited.

The Market Speaks with Real Data

Unfortunately, 2 months into our pilot projects with SmallCo we ran into some real roadblocks: SmallCo had the same needs as BigCo, but SmallCo was too small to be a first customer. We needed a much higher level of market penetration before our solution would be useful for SmallCo.

We needed to first sell to a bigger company - a company like BigCo. We began looking for candidate companies that matched our vision. Unfortunately our search lead us to the conclusion that our solution was not going to be adopted by the market in any timeframe we found acceptable.

Faced with this reality, we decided to move on.

My Key Lean Startup Lesson

In hindsight, we did a lot of things right:
we validated the need before we wrote a line of code,
we cut scope like crazy and got a solution into the market quickly,
we listened and learned and looked for evidence.

Most of all we realized all of this in months rather than years.

However, we failed to do one thing that would have saved us months of time:

We failed to vet the OPPORTUNITY in addition to the market need.

A Simple Way to Vet Opportunity

The biggest mistake I made was in failing to vet the business opportunity and not just the market need. I had a hard time getting myself to talk about pricing and sales early in the process. In my experience, pricing discussions with customers on product concepts can be a huge waste of time with enormous data variability. In retrospect I think there is a better way to approach these discussions than asking people “how much would you pay for…?”

We initially started down the right path in creating a “contract” with BigCo but didn’t continue it long enough. I recently read a great case study on the Google Group Lean Startup Circle:

We visited each potential customer a minimum of twice, if not usually, three times. Each time we would come back with a few more “screenshots” and tell them that development was progressing nicely and ask them for more input. 
We also solicited information as how they were currently solving the problem and how much they paid for their solution.

On the third visit, we pressed those who saw merit in the idea to sign a legally non-binding Letter of Intent. Namely, that they agree to use it for free, if we deliver it to them and it is capable of X, Y and Z. And not only do they use it, but that they intend to purchase if by Y date at X 
price, if it meets their needs.

This is exactly what we should have done. I actually don’t think many customers in this market would sign an LOI. But the conversation would have brought out market insights into volume, financial modeling, and demand that took us months to figure out once we started deploying solutions.

The Key Point

This is the key point of this case and worth emphasizing:

In early product phases the sale doesn’t matter as much as customer learning from trying to sell.

Fortunately we had enough experience to change paths and ask the tough questions once the real data started coming in.

[Author’s notes: I use “we” frequently in this case study to recognize the contributions of a part-time partner, consultants, and advisors who helped get ManyWheels going. I had a lot of help, but the bulk of the operational work of vetting the market, product development, and operations was done by me. I only make this point because team structures are a critical part of startups.]

The critical question isn’t ‘What do your customers want?’ It is ‘How do you KNOW what your customers want?’
–Robert Morton

A lean startup* approach is a commitment to entrepreneurial mindset, a recognition that the worst enemy of startups is the illusion of knowledge about what a market wants. In other words, a lean startup entrepreneur needs to accept and try to overcome the limitations of her mind.

In Don’t Believe Everything You Think, Thomas Kida has written a great introductory primer on the basic errors we make in thinking. While most literature on this subject uses very technical and theoretical language such as confirmation bias, Kida presents some basic, useful concepts along with examples from our every day lives.

He calls them a “Six Pack of Problems”:

Kida presents strategies for improving our critical thinking - strategies a lean startup entrepreneur can use in vetting markets.

For instance, I am prone to making the classic entrepreneurial mistake of asking prospective customers questions that serve to confirm what I already want to believe. I need strategies for getting to the truth and saving myself the pain of self delusion.

Consider for a moment, the following answers to How do you KNOW what your customers want?

The X market has a problem with Y, and the technology we’ve been building in our lab will allow them to do Z by…

I have interviewed 10 industry executives about the problem, showed them screenshots of my proposed solution, and confirmed that they are very interested.

5 prospective customers have signed an LOI to test and buy at $X

The first answer is a story - not evidence. The second answer begs for skepticism about how the interviews are conducted. The final answer is a fact.

Which do you find most convincing?

*Lean Startup is a Trademark of Eric Ries, a concept articulated in this seminal original blog post on the concept

EVERYTHING IS BETTER IN SMALLTALK!

There is a good reason why a programming debate resembles a dogmatic religious debate: both sides have invested heavily in something that achieves essentially the same goals but cannot point to a specific reason why their choice is “better”.

Of course veteran programmers find these debates tedious because they have seen so much come in and out of fashion. Their usual - and correct - answer is “it depends”.

This ambiguity presents entrepreneurs with a dilemma since ultimately a start-up has to make a decision to bet on a particular technology stack. Just today I saw the following tweet from @RemyMiralles:

Someone on aardvark is asking me “Why is Python so much better than PHP?” There are just different!! it depends on what you need!

Indeed.

But Remy’s answer highlights the dilemma of the entrepreneur committed to pursuing a lean start-up path: By definition you are trying to solve something where both the problem and the solution unknown so you don’t know what you need.

6 months ago I would have attempted to answer this question with some rambling diatribe about scalability, developer cost, frameworks, etc. I now think I have a simpler answer:

The best lean start-up language allows you to iterate your ideas the fastest with the market.

Or, as Eric Ries likes to call it, minimizing total time through the start-up feedback loop:

Eric's core feedback loop for start-ups

My assertion raises the obvious follow-on question: What programming language allows me to iterate the fastest?

Well, if you are truly following a lean approach you probably realize that the choice of dev environment isn’t your top concern. It probably isn’t even in the top 10 for most web-based start-ups these days. You can learn a lot about your customers’ needs with mockups, phone calls, and sketches before you write a line of code.

When you finally are ready to start building the product, the decision might be obvious:

1. If you are a programmer, just pick what you know the best. This isn’t the time to learn Python if you’re already a PHP stud. Get coding, start failing, start learning.

2. If your employees or partners are programmers, just ask them what they can use to iterate the fastest. 99% of the time it is whatever they already know. This isn’t the time to “build it in Erlang for future scalability”. You should be so lucky to have scaling problems some day.

If you’re a “business guy” who plans on completely outsourcing the “programming” to contractors … well … good luck to you. Hopefully you have some idea for how you’re going to pivot. My advice is to find a technical co-founder. You can even use the technology stack choice as a recruiting tool. I’d pick Python to just to get Chris Hagner on the team or Erlang to get Rusty Klophaus even though I’ve never written a line of code in either.

Great developers - not programming languages - build great products.

Finally, if you still don’t know what language to pick, choose Ruby on Rails because it is the best. If you don’t agree, get ready for a public stoning.

Since this writing there appear to be a number of emerging quality tools such as Creately that might do a better job than Visio.

Summary

At ManyWheels we are using Microsoft Visio to reduce our market risk by rapidly, cheaply, and iteratively building clickable web demos for prospective customers using this stencil.  

Risk?  What risk?

Anyone who has been through a start-up or two knows about risks.  Financing risks, team risks, and technology risks are some of the most frequent sources of the entrepreneur’s sleepness nights.

But as technology costs have moved lower and lower one risk dwarfs all others:  market risk.  Market risk is the start-up equivalent of a bridge-to-nowhere: you build a product that nobody wants.  

I try to reduce market risks by challenging my assumptions with two key questions:  ”Am I building something that people want?  How do I know this?”

(The first question is easy to answer.  The second one is a bit tougher…)

So how can I prove to myself that I’m mitigating market risk?

Ways to Mitigate Market Risk

“What’s your problem?”

The most obvious way is to ask prospective customers about their problems.  This process works up to a point; you can get high-level needs and concerns but ultimately most people need to see something to provide specific feedback.

“Do you have 5 hours to read my spec?”

The traditional route is to “write it all down”.  How many prospective customers want to read your detailed 30-page spec?  None that I’ve been talking to.  Good luck.

HTML Mockups - the traditional approach

Another option advocated by 37 signals is “Interface First”:  build mockups in HTML before you start writing any code.  Obviously if you’re very comfortable (and fast) working directly in HTML then go for it.  Personally, I find that even HTML is still too slow because managing and organizing lots of tags can get really tedious.

What I really need

Over the past 6 months I’ve been struggling with a better way to manage this process in my prospective customer conversations.

The perfect tool for me is one that:

• I already know how to use
• is free
• allows me to export in HTML to show to other people
• allows for rapid iteration

Visio to the Rescue…

I know that professional web developers have a lot of different tools for building wireframes.  After a brief search, the option that best fit my needs is the newest version of Microsoft Visio.  It isn’t free, but you can download the trial version from Microsoft and use it for 60 days.

(If you’re ultra-cheap, you can even time the download at the beginning of the month to squeeze a few exta weeks out of the trial.)

You will need the interaction designer’s nail gun (3rd edition), a set of instructions and stencils for building web pages.  You can get an idea of the possible by checking out their demo. 

We’ve been using this tool to do our mockups of ManyWheels with prospective customers.  After a few hours we became proficient with backgrounds, foregrounds, links.  We built a few of our own stencils that allowed for rapid creation of menus, buttons, etc using our color scheme.

The real power of the tool is its ability to allow an entrepreneur to present information differently to different people.  Some people need to see a sequence diagram.  Some just want to see a page.  Others want to see blocks on screens.  All of this is a snap in Visio, plus you can hyperlink it together and publish a web site instantly.

My Experiences with ManyWheels

When we first began engaging the market on our ideas for ManyWheels we started with meetings and phone calls.  We listened.  We asked people about their problems.  We sat next to the people doing the work and asked them about their frustrations.  We tried to get a sense for the market dynamics and what type of solutions might work.  And we learned a ton about the solution we thought we needed to build.

Or so we thought.  

Once we started creating mockups and showing them to prospective customers the conversations took on laser-like focus.  People instantly rejected many of our core ideas and offered alternatives.  Some customers wanted to see high-level data flows to understand how ManyWheels would work in their business.  It took us several iterations like this to get to the point where the conversations moved from “interesting” to “when can I get it”?

(man, those are beautiful words when you’re struggling to identify a solution.)

In Conclusion

My experiences over the last 6 months have reinforced what countless others have already learned:  get a mockup in front of people as soon as you possibly can.  Nothing will focus your conversations and get specific feedback like showing people a possible solution.  Moreover, it sends a message that you’re serious, that this product is really goign to be built, and that you’re thinking critically about the problem.

Fortunately, you don’t need a web designer to do it anymore.  Spend a 1/2 day with Microsoft Visio and the stencils above and you’ll be building worakble mockups in no time.  

Just as genes propagate themselves in the gene pool by leaping from body to body … so memes propagate themselves in the meme pool by leaping from brain to brain …
-Richard Dawkins, The Selfish Gene

If you follow my blog you’ll notice that I have moved from twitter skeptic to enthusiast.  And recently I have been struggling to explain why I think twitter is a bigger evolution in human communication than facebook, myspace, or anything else in social media.

“Why should I care that someone is getting up or going to the bathroom?”, they ask, just I originally did. And, quite frankly, you shouldn’t, just as I don’t.  But I think something bigger is happening on Twitter:

Twitter is a human/machine information revolution because Tweets are memes.

By memes, I mean fundamental units of discrete information that can be rapidly evolved, shared and aggregated.

I find myself forced into information compression with Twitter.  Heck, I can even sum-up most of my blog posts with a Tweet and the overall point wouldn’t be lost on the audience just as a Haiku can convey the same point in a fraction of the words of a short story.  For instance, this blog entry in 140 characters:

Twitter= info revolution b/c tweets=MEMES: shared, evolved, aggregated like genes. Bigger/different than MySpace, Facebook..

Actually this is only 124 characters, leaving me 16 characters to spare for a URL link created by is.gd.

When I ask people whether they are on Twitter I typically hear something like the following:

• “I’m not on Twitter but I’ve heard of it and don’t really get it.  What is it?”
• “How is Twitter different from blogging/delicio.us?”

Twitter is a microblog, a quick thought, a digestible blurb that is easy to type and easy to absorb by people who are constantly context-switching.  Of course it isn’t a substitute for a blog post, a novel, a movie or a poem - and I still enjoy all of these.

Tweets represent the fundamental units of human thoughts, and as our tools get better and better for aggregating them and using them practically I predict that everyone will be touched by Twitter one way or another.

Don’t believe me?  Check out what practical things you can already do with these memes.

But this blog post is theoretical and it doesn’t explain why I invest my time and energy into building relationships on Twitter.  I do think Twitter has a very practical purpose and I’ll explain it on my next blog post.

It has lead to all types of bizarre practices including domain name squatting and odd company names based on nonsense words.  Finding a good URL is one of the most frustrating activities in launching a new company, and I was thrilled to find ManyWheels.com available 6 months ago.

The tyranny of the URL may be fading with the advent of Google Chrome search box in the same line as the URL.  I now find myself less concerned about remembering the exact URL for company since typing and searching happen in the same user experience.

It’s no accident that there’s a snapshot of Fannie Mae headquarters alongside the family photographs on the memento shelf in my office.  It warms my heart to think of the place.  The stock has been so great they ought to retire the symbol.
-Peter Lynch, Beating the Street

I can be as wrong as the next guy.
-Peter Lynch, September 2008, when asked why he held Fannie Mae stock in his own portfolio to the bitter end.

The point of this essay:  I ignore all predictions about money from ANYONE. 

I don’t care if you’re Warren Buffet, the blithering idiot on TV, some random dude in my Twitter feed, or a famous hedge fund manager. You might be able to predict where a particular stock or the market is going, but I have no way of telling if you are right or wrong so it is just easier to tune you out completely.

I’ll summarize what is explained elsewhere more eloquently in books like Fooled by Randomness:

In any large pool of investors, mere chance will result in some of them greatly outperforming the average.  Unfortunately we have no means to determine whether or not these results actually indicate whether someone is lucky or good, so putting faith (or money) in their ability to continue this winning performance can lead to disaster if they have just been lucky and return to statistically average results.

We’ve been lucky. Well, maybe it’s not 100% luck—maybe 95% luck.
-Bill Miller, on his streak of beating the S&P 500 for 15 consecutive years.

“Countrywide’s long term business value… we think is in the $40’s compared to its current price of about $14-15.”
-Bill Miller, 2 months before Bank of America bought the company for $5.5/share.

Even if you can predict the future with some degree of reliability, I sure don’t want to take your advice on one of the occasions when you happen to be wrong.

Just as an experiment, spend a day analyzing how many times people make predictions about the future movement of stocks:

“This is going to be worse than 1929″
“They are too big to fail”
“Economists predict that….” (Put anything here.  They get it wrong constantly)
“The Paulson Plan will make money for taxpayers” (You want to take the future of our country on faith?)

The constant noise of the financial media does more than cause you sleepless nights or overconfidence.  Following the herd mentality will inevitably lead you to sell during panics and buy during boom periods - a recipe for lousy returns.

As I write this in October 2008, everyone around me seems to be “moving their money into something safer” until things stabilize.  I even hear “pundits” providing this advice on TV.  Countless studies show that this strategy is extremely risky since missing even a few good days in the market can drag your returns below inflation.

Nobody knows nothin’
-Marc Andreessen, in a speech I heard a few years ago.

Amen, Marc, amen.

I ignore predictions by me and everyone else in the world.  So making investment decisions must be agonizing, right?

On the contrary, this intellectual foundation makes investing so easy that it becomes boring.  I’ll discuss why in part 3.

Follow Kevin on Twitter.

As all of us know, these events are about the people.  I find that the atmosphere at TECH cocktails attracts real entrepreneurs, angels, and people that I actually want to meet.  Plus it tends to be smaller and a bit more personal than many local networking events that mostly attract service providers (nothing against them…I just want to meet a variety of people).

In any case, I’d like to do a quick shout-out for a few of the folks I met:

GeniusRocket:    Might be able to help me build the creative foundation for my new start-up, ManyWheels.

Planypus:  Seems like a good service for organizing an un-conference or SMS mobs.

Great event and hope I can make the next one.
Follow Kevin on Twitter

If you can keep your head when all about you
Are losing theirs…
Yours is the Earth and everything that’s in it
-Rudyard Kipling, If.

My friends and family know that I’m interested in investing and that I’ve worked in the financial services industry. So they have been asking me the same question lately:

What do you think will happen with the current financial meltdown and what are you doing about it?

The answer is simple but not very reassuring: I have no idea what will happen, and nothing different.

Actually the real answer is more complicated and, I think, more interesting. Not only do I not know what will happen, I know that I don’t know.

This point forms my investing strategy foundation.  I don’t know the future and I’m fine with it.

Last week I didn’t know what was going to happen this week. Five years ago I didn’t know what was going to happen today, and I sure don’t know what will happen tomorrow. The Dow could stage a massive recovery tomorrow. Or it could plunge another 700 points.

The ambiguity in investing seems to give most people angst: they feel like they should know what is going to happen. For if they could put parameters around they future they would be in a better position to deal with it.

Do I want to know what is going to happen?  Of course! One look at the 2008 S&P500 Chart will convince anyone that a few good moves could make them rich. But confidently guessing wrong is the fastest path to financial ruin, and missing just a few days in a bull market from trying to guess the recovery date can ruin your returns.

In 2004 I undertook the painful exercise of calculating the net return of all of my investment decisions since 1997. After reading all of the books, doing all of the research, and making my own decisions I matched the S&P500 returns. And when taxes and transaction costs were considered I had actually performed worse than an S&P500 Index Fund. After some painful reflections and a few stiff drinks I accepted reality that I’m no better than average at making investment decisions. So I decided to read some different books.

I read Fooled by Randomness and The Black Swan by Taleb. I read almost every essay written by William Bernstein. I started learning about logic from podcasts like Point of Inquiry and the basic mistakes we make in thinking. I read about the history of Long-Term Capital Management. I studied the scientific method.

I realized that I don’t know what is going to happen in financial markets. Far from causing me despair, this knowledge has made it much easier for me to sleep at night. Better still, it arms me with a powerful tool for “keeping my head about me”.

(Flip on the financial news media tomorrow and you’ll see plenty of people who have lost theirs.)

I decided that I couldn’t see a good reason why we could not have another Great Depression that is twice as severe and twice as long as that of 1929. I also decided that technology could propel the world into a new era of economic efficiency with financial returns as good as or better than those of any other time in history.

So in 2004 I started anew with an investing approach that took into consideration the possibility of these future events in the context of my life. And every time I’m faced with a decision, a new piece of information, or a new event, I remind myself that I can’t guess the future. I try to make decisions dispassionately. This isn’t easy and it takes a lot of self-coaching.

“The market dropped today, maybe it is a good time to buy!”
“Oil has really gone up this year, it is a bad time to diversify into commodities.”
“The US will NEVER let a nuclear-capable Russian economy fail.”
“Buy land. They’re not making any more of it.”

Underlying each of these points is a belief about the near future. And each time I find my mind wandering in this direction I try to coach myself back to calmer waters.

Of course I can make some reasonable bets about very long term trends that guide my investment decisions. I can develop an approach that allows me to not only remain calm through the 2008 market madness but actually profit from it.  I can use my professed ignorance about the future to my advantage.
But that is a topic for the third essay.

You all know security is mortals’ chiefest enemy
-Macbeth III;6

P.S. Just for fun, count how many predictions you and and others make about the market tomorrow.  Then reflect for a second on whether there is any solid basis for these opinions. In part 2 of this series I explain why I don’t believe any of them.
Follow Kevin on Twitter

In-Q-Tel

In July I left In-Q-Tel, the strategic investing arm of the CIA and US Intelligence Community.  It was a happy parting and one of my best career experiences.  In-Q-Tel is a national treasure and I would recommend it to anyone, both as an employer and a source of innovation solutions for the US government.  A highlight was working with the Intellipedia team  (If you meet Steve, Sean, or Don at a social media event, be sure to thank them for their dedication).

But after 3 years of the investing side … time for another start-up.

ManyWheels, Inc. - Look out, world!

Through a rather unique set of circumstances I began exploring challenges in the automobile transportation space.  Ever drive past a half-empty truck hauling cars and wonder why the truck isn’t full?  Every wonder why getting a car shipped is a harrowing experience for most people?  Me too.

After due diligence with a large company in this space I applied to the National Science Foundation for a grant to develop technology to improve automotive transport efficiency.  More on this in a few weeks.

For the past few months I’ve been trying to follow the advice I give to entrepreneurs:  focus on the market.  We’ve been vetting the opportunity with prospective customers and partners for the past few months, doing dozens of site visits, interviews, etc.  We now understand the major problems, have a vision for the solution, and just last week incorporated ManyWheels.

The Motley Fool

I also returned to the Motley Fool this Summer to do some consulting on a couple of fun projects.  It felt like homecoming, seeing many great friends that I missed.  The company has done an incredible job keeping its culture intact while becoming a world-class business.  I have no doubt it will become a premiere institution in the DC area.

(shameless recruiting plug:  The Fool is an awesome place to work!)

So there you have it, my work life.  In the last few months I’ve been working in the financial services, automotive, and intelligence sectors and volunteering with the most aggressive biotechnology initiative in world history.

You’re probably wondering about the common thread of all of this.  Me too.

But in the meantime, I’m working like a maniac and having an absolute blast!

Follow Kevin on Twitter

Consumers want the ability to consume data and use services everywhere online and sites will have to buckle to this pressure.  Yahoo’s announcement is clearly a reaction to Facebook’s move towards becoming a development platform.

Historically, sites have built financial models around attracting consumers to a destination, keeping them there as long as possible, and maximizing financial return from this activity.

In the near future all sites will be forced to identify the value-added services they provide consumers and give them the tools to use these services anywhere.

-
Follow Kevin on Twitter

I minimizee the break, coasted where possible, kept distance between cars in front of me, accelerated slowly, and turned off the car at long red lights.  I wasn’t religious about it and on several trips reverted to my “normal” style.

The result?  20% increase in MPG (about $200 a year).  I didn’t notice a duration difference and felt much more relaxed.

I also found myself paying more attention to the road ahead and anticipating upcoming events.  I have no doubt that it is a safer driving practice.

I can’t say that I found a downside to hypermiling, and even if I arrived a few minutes late it is an easy tradeoff for safer, cheaper, more relaxing driving.

Man, I am getting old…
–
Follow Kevin on Twitter

Some quick advice for my fellow Twitterers:

1. Tweet less.  Seriously.  I am starting to unsubscribe from Twitter feeds for people who simply Twitter too much.  If I log into my Twitter home page and see your icon 5 times on the screen you are unfortunately a candidate for me to stop following.  And even if I don’t unsubscribe from your feed I’ll unconsciously tune-out your truly relevant points when the are drowned out in “…is eating breakfast” Tweets.  I’m guilty of this too sometimes…
2. Think of me when you Tweet.  I follow people on Twitter because I want to learn new things, keep track of the INTERESTING parts of my friends and colleagues daily lives, and laugh a little.  What do I really like?  Hearing where you are.  Links to interesting pieces.  Interesting blurbs and thoughts from conferences that I cannot attend.  Events in your life.  Requests for help.  I understand that people use Twitter for different reasons: some people just have fun with it and (almost obsessively) post social notes; others have very specific discussions with a small work group of people.  I understand why they use Twitter for these purposes…I just don’t want to follow it.
3. THINK ABOUT WHO WILL READ WHAT YOU WRITE.  I cannot believe how much people (even those my age) will mix the personal with professional on Twitter.  I have had co-workers post truly juvenile, obnoxious things on their Twitter feed.  I often read these Tweets while I’m sitting at work.  If you want to make comments about your social adventures, consider making a personal Twitter feed that is unconnected to your professional profile.  Not doing so really says volumes about your judgment.
4. Use Twitter Search (fka Summize) to track the RSS feed of responses to your tweets.  For instance, I have an RSS feed for “@kevindewalt”.  Thus I will catch replies to my tweets that I would otherwise miss.
5. Introduce me to new people on Twitter.  I’ve done this a few times quite successfully and I’m surprised that it isn’t a more popular practice.  Find a good feed?  Know of someone I should meet?  Feel free to drop a “@kevindewalt meet @MadamX.  You guys both…”

Hopefully I’m not giving folks the impression that I’m not excited about their Tweets.  Indeed, it makes a nice break in the daily routine to hear from bucchere, 8of12 and some of the other people I follow regularly.

But a little “consider the audience” goes a long way in Web 2.0 just as it has in the rest of human discourse.

In a nutshell, GTD is a fluid personal management process that operates closer to the way most of us work. Most of us deal with a constant influx of new tasks, dozens of disparate projects at home and at work, and changing deadlines. GTD provides a framework for us to deal with this onslaught.

I doubt that I will ever implement all of Allen’s ideas. For one thing, much of the book focuses on dealing with paper. I don’t handle much paper at home or at work. I typically carry a notebook to meetings and use it to scribble down some hieroglyphics ostensibly posing as English that even I cannot read. So I don’t imagine that I’ll be creating tickler files.

But ultimately I come out of these meetings with “to-dos” for myself that need to be tracked and managed. GTD provides the framework for managing and tracking everything.

I also don’t quite see the point of keeping my email inbox empty. I need to review (in one form or another) email as it arrives. But with desktop search I don’t need to categorize everything into folders. I don’t write down everything everyone says in meetings and I don’t see why I need to categorize every email.

But I can understand why GTD has a cult-like following among techies. It provides a practical structure for organizing our hectic lives into the ways we actually work.

So I’m going to give it a shot.