Simplify Your Pitch (Keep the Details for Later)

When I was an entrepreneur raising money I tended to make a classic mistake: trying to convey all the amazing things we were doing in great detail. This is a terrible strategy. Why? Because too much detail buries the story of your business and also makes your business seem, well, complex. And investors are afraid of complexity.

Imagine for a moment a pitch that describes in great technical detail creating a custom processor, a custom operating system, a new relationship between hardware producer and distributor, and so on. Now contrast this with Steve Jobs introducing the first iPhone. It tells a story that anyone can follow with essentially zero technical knowledge. Now ask yourself which pitch you would invest in.

Does that mean you shouldn’t be prepared to talk about technical details? Not at all. But you want them pulled from you by the audience instead of pushing them. By the way this is just another example of the less is more principle which applies incredibly broadly to communication and in particular when you are selling something. Whether it is a pitch to VCs, an idea for the team or a sale to a customer: tell a simple story that will get attention, then provide detail when it is asked for.

Toward a Better Patent System

Another topic that I have written a lot about here on Continuations are patents and in particular software patents. While there is a lot of reform that I would love to see I have also come to appreciate that sometimes the only way to get there is in small steps. One relatively meaningful step was just introduced by Senator Schumer. The basic idea is to allow for a much fast tracked review of many of the suspect business process patents used by patent trolls to sue startups and larger tech companies. Because of changes in the interpretation of patent law many of these fast track reviews have a good shot at invalidating the patents. For a more detailed comment on this proposal, please read Nick Grossman’s post over at USV.

Privacy: Sorry, You Can’t Have it Both Ways

There is so much happening with privacy right now that it is enough to make my head spin. What is clear though is that individuals, companies and government all want it both ways.

Some parts of government want private enterprise to do a better job of protecting individuals’ information from other individuals and companies. At the same time other parts of government are looking for wholesale access to individual data bypassing any and all privacy policies and constitutional rights. Sorry, you can’t have it both ways.

Similarly individuals want to be able to share information with more than 500 of their best friends on Facebook and yet have it be private. Sorry, you can’t have it both ways.

Companies want to gather tons of information about their customers but not disclose much or anything about their own activities or have third parties collect that information. Sorry, you can’t have it both ways.

We are entering unchartered territory here because of our amazing information gathering and sharing capabilities. As I have said before we need to start with a discussion of values first. I don’t believe that privacy is a value in and of itself. If you want to see my own grappling with this complicated topic, here are all my past posts on privacy.

Tech Tuesday: Remote Engineers

I have been writing the last couple of Tech Tuesdays about hiring and retaining engineers. One of the questions that comes up a lot in that context is what to do about people who are in other locations. Is it a good idea to have remote engineers? There are people who seem to have near religious believes about this ranging from it can never work to it being the only thing to get anything done.

In practice I have found that pretty much anything can work if you support it with the right culture and systems. I have seen both success and failure with entirely distributed teams (everyone is remote) and with entirely centralized teams. So what do you need to do if you have some remote engineers? Much of the following applies to whether they work individually from home or from a satellite office.

You need to invest heavily in communication. Having some kind of realtime channel seems to help a lot and IRC still appears to be the best way to do that. But in addition to realtime you also need to spend time on communicating company strategy, goals, values.

Having people come and visit so that they can meet in person at least once in a while also makes a big difference. There is some sense of being connected that comes from having met someone in person that is still quite difficult to establish purely online. 

It is very difficult to handle remote engineers (or remote employees of any kind for that matter) if you have a face time culture where being in the office for long hours is how performance is judged. In order to make remote work you have to have good systems for tracking progress and measuring individual productivity.

The one thing to be super careful about is to avoid any us vs. them mentality emerging. If there is any sign of that whether between two offices or between office and remote employees you need to get to the bottom of it immediately. That can become very corrosive quickly and hard to recover from if it goes on for some time.

Finally, not everyone is good at working remotely. Some people need the structure of an office environment. Others need the in person social interactions. So if you recruit someone to work remotely make sure there are some indications in their personality or history that this will be a good fit for them. 

I would love to hear from readers what has worked or not for them in having remote engineers or a second office.

PS Speaking of hiring engineers, Ziggeo is also looking for engineering summer interns.

Summer Internships at Ziggeo

It’s not too late to find a summer internship! In fact, my wife Susan and her co-founder Oliver over at Ziggeo are looking for marketing and sales interns for the summer. So if you know of any students who are looking, please send them their way.  Thanks!

Is the Stock Market High?

The stock market indices are above their pre financial crisis highs. One interpretation of this is that the financial crisis was just that: a crisis of the financial sector that left the rest of the economy largely untouched. Another interpretation is that we are simply looking at the results of way too much cheap money provided by the Fed. The latter is supported by a chart that I saw yesterday for the first time which shows the Dow divided by the price of gold. That chart is essentially flat since the crisis. In other words the stock market has not risen at all when denominated in gold.

Does that comparison even make any sense? It does if you believe that the price of gold is essentially an indicator of there being too much cheap money. If you think the price of gold is driven entirely by a (potentially irrational) fear of future inflation you can pick another comparison that has a similar effect: interest rates. I haven’t tried to do this but I am pretty sure that if you normalize the stock market for interest rates you will get a similar picture to gold.

With the risk free rate being near zero, future cash flows count for a lot more than with higher interest rates. So when you look at stock prices through from a DCF perspective you would expect them to go up a lot as interest rates go close to zero, especially for companies that are deemed to be low risk. Apple just borrowed $17 billion at rates as low as 0.45% for 3 years. Even if you add quite a bit of risk for equity you are still likely to come up with historically low discount rates.

There is one other factor that has been driving the market though in addition to cheap money and that is cheap labor. I have written about the changes in employment extensively before but the flip side of that has been higher corporate profits. Apple of course is one of the firms that had record profits and it is borrowing now only to avoid paying taxes. In combination the changes in the labor market and the cheap money are the key contributors to the immense inequality we are facing.

Bottomline then is that the market is high. But it is high on cheap money and cheap labor. Neither of which is ultimately sustainable (although both are likely to go on for quite some time).

Dwolla Gets a Check (To Do Away with Checks)

Today Dwolla announced a new financing led by A16Z with Scott Weiss joining the board. The funding will go towards establishing a new office in San Francisco, an expanded presence in New York and much needed additions to the team in Des Moines starting with a lot of engineering hires.  I am of course excited about this as an investor but even more so as a user of Dwolla. It already works well for me in in paying contractors but I can’t wait for it to be more broadly available. It is 2013 after all and we have self driving cars — yet I still find myself having to scribble amounts on little pieces of paper, sign those and then put them in the mail. So: congrats to team Dwolla on the funding and now please hurry up so that I don’t need to re-order my check book! 

Tech Tuesday: Retaining Engineers

Last Tech Tuesday I wrote that the companies which do well on hiring engineers are the ones that “prioritize both hiring *and* having a great work environment.” The post went on to talk about some of the best practices in hiring. Today’s follow-up is about creating a great work environment for engineers.

There is obviously a lot that goes into creating a great work environment including overall company culture, office space, company mission etc. Instead of those more general points, here are some key dos and don’ts that are more specific to engineering

Dos

- Ship early and often - getting code into production is hugely motivating. In fact Etsy has new engineers deploy a small code change into production on their first day.

- Hold internal hack days - letting engineers work on something they really want to with some frequency will make it much easier to also get those fixes to the the backoffice systems done (or whatever else is the least exciting work in your specific case)

- Invest in training - engineers tend to want to improve their skills and knowledge so learning something new makes them both happy and also more productive (as does teaching so you can keep some of this in-house)

- Remove dependencies - this is not just about loose coupling from a technical perspective but also about having enough product management and design folks around so that engineering doesn’t have to do NOPs waiting for specs or layouts

Dont’s

- Treat engineering as order takers - engineers are not production machines or robots - they need to buy into the company’s mission and strategy and understand how what they are working on fits into that and be able to provide feedback

- Hang on to low performers - if someone is turning in sub par work again and again it becomes hugely demotivating to the rest of the team. Even if you feel resource constrained already it is better to let them go.

- Give star performers too much leeway - this one may be the hardest of all because it is easy to be afraid of pushing back for fear that someone might quit. But again if they take too many liberties eventually it becomes destructive for the cohesion and productivity of the team (I am sure someone with more familiarity with team sports could provide a great example here).

Like last Tuesday on hiring, I would love to hear from readers what Dos and Don’ts have worked well for you. And of course any and all comments on the ones that I listed above.

Synchronization As A Service

When it comes to files we are beginning to take synchronization as a given. You work on a file at work and through the magic of Dropbox or similar services the copy of that file on your personal laptop winds up reflecting the changes. Increasingly we are expecting the same for applications. For example, when you have read a Direct Message on a Twitter App and then notice that it is still shown as unread in the web applications we experience that as a bug.

This enduser expectation of data and state to be instantly synchronized across applications and/or one or more browser sessions has created a new set of demands for engineering teams. Thankfully a new set of services is emerging that make this easier. These seem to come broadly in two categories: first, realtime notification services such as Pusher and PubNub and second, data synchronization services such as Simperium and Firebase.

The former let you get messages quickly between places and you can use those to synchronize state. The latter abstract the messaging away and give you synchronized data directly. Using these services it turns out to be surprisingly easy to do things that would have taken quite a bit of work previously (and required operating one’s own servers).

For instance, I recently wrote a post on HTML5 as we have been seeing more and more activity. The weekend before, my son and I had created a simple and rather incomplete Snake game drawing on the canvas. At the time we talked about how easy or hard it would be to make it multiplayer. To my surprise, using Firebase it took me less than an hour to have a simple version for two players (player 1 and player 2).

I would love to hear from others who are working on data synchronization for apps. Are you building it yourself? Using one of the services from above or some other service? Using an open source framework (if so which one)?

Your Product Is All There Is

I love meeting with entrepreneurs because most of them are full of optimism and often driven by a big vision. It is then easy to get into a conversation about that vision and how awesome it will be. But therein lurks a great danger and one that both entrepreneurs and investors (myself included) can easily fall prey to. Outside the room nobody really knows or even cares about your grand vision. Instead, your product is all there is.

What do I mean by this? Even if you do a fair bit of marketing and evangelizing and speaking at conferences, at the end of the day for most people the product either works or it doesn’t. It either fills a need of theirs (one they may not have know they had before encountering your product) or it doesn’t. Again, the vast majority of users will neither know of nor care about your vision.

This is worth repeating over and over again: your product is all there is. For the insiders in the know it is so easy to project the vision onto the product and they will always see it. But that is not how everyone else experiences it. Always keep this in mind. This by the way is true not just for consumer products but also for B2B ones.

So what should you do? Lots and lots of enduser observation of people who know nothing about your grand plans. And product improvement based on that feedback. Rinse and repeat and good things will happen.