Category Archives: Work

SSP 133 with Sailesh Ramasray of BizFusion

Bob and I released Show #133 of the Startup Success Podcast yesterday, featuring an interview with Sailesh Ramasray of BizFusion, a full-featured accounting system for small businesses.

My favorite insight from the interview is that most businesses should internationalize but do so by taking advantage of English as a common language. It’s not that difficult to add new markets, so you should probably look into it.

Sailesh’s approach to BizFusion reminds me somewhat of Michael Sliwinski’s approach to Nozbe. I’m going to have to figure out how to describe what makes them similar to me <stroking chin> …

Bad ideas

The most common obstacle (excuse?) I hear for someone not creating a startup is, “I don’t have a good idea.” Well … so what? Maybe you should work on a bad idea instead.

Jason Cohen suggests your idea probably is bad, even if you think it’s good – but hey, you have to start somewhere, so you should probably go ahead and pursue it.

I’m beginning to think that it’s better to pursue an idea that you KNOW is bad than to pursue nothing at all. After all, if the goal of Lean Startup is to validate that your idea is good, couldn’t there also be value in validating that your idea is bad? There is a certain amount of learning how to measure that goes into creating a startup these days, and you can learn a lot by proving that your idea doesn’t meet the measurement thresholds you required for a success (most importantly, that revenue > costs). In some ways, your emotional skepticism about your bad idea will help you learn more about the process – it will help you stay objective. I suppose there’s always the possibility that your idea turns out to be good, but it’s more likely that you’ll spot a good idea right next to your bad idea.

If you have no idea at all, then just pick a space you like and start exploring. I’m interested in scheduling, email productivity, educational phone apps, “personal relationship management,” and a lot of other spaces. Pick a space at that scope, then talk to friends about possible ideas. Just pick the first specific idea that comes to mind. Do some basic customer development by talking to customers in that space or follow the process that Rob Walling recommends for a more self-serve product. The process itself should open your mind to more ideas – and as you evaluate them, one of them is bound to be a good one.

What money can buy

A while back, I mentioned Jacob Needleman’s Money and the Meaning of Life. One of the points Needleman makes is that for almost any problem in life there is a very specific amount of money that will solve it.

If you are building a software company and have figured out how to scale, there is usually a specific amount of money that will help you execute your plan. This is what VC’s provide.

If you have an incredible idea but no time to build it, a specific amount of money will allow you to quit your job to focus on your startup. An angel investor might provide this.

If you are sick of hosting your own blog, there is a specific amount of money that will help you remove that problem from your life.

If you want your son to be a racecar driver when he grows up, there is a specific amount of money you can expect to invest in that goal.

If you want to impress your sweetie on Valentine’s Day, you can think of a specific budget to lavish her with gifts, flowers, and a dinner at a fancy restaurant.

BUT … there are some problems that can’t be solved entirely with money – it’s important to know the difference.

Happy Valentine’s Day – spend some time today appreciating the things that money can’t buy.

Learning git

I’m working on some startup-oriented content with teammates around the country. It’s mostly text, not code, but there are a healthy amount of code snippets mixed in.

For any other project like this I’ve worked on at Microsoft, we have collaborated using SharePoint or (gasp!) email. But the guys leading this project are very comfortable with git, and since this content is aimed at developers who would likely use git, it makes sense to collaborate on github.

Instead of working directly in PowerPoint, we’re building the content primarily in readme.md files, which are text files with simple markup that make them look good on github.

Even though I was familiar with git, I had never actually used it on a real project (I had never gone past hello world). It took a couple of hours, but I’m starting to get it – I’m beginning to understand why so many developers (especially startup developers) are so fond of it. Once you get going, it’s pretty darn easy and efficient to collaborate with people around the world.

It’s going to be interesting to see if we meet the tone of our intended audience with this content, and I’m curious to see how much the tools we use affect that. Regardless, it’s always fun to learn and actually use a new tool.

Envision then do

You have to know exactly how you want the music to sound in your head, hear exactly how it actually sounds in the room, then bring the two as close together as possible.

That’s paraphrasing a knighted British conductor – I read the quote at school more than twenty years ago and since then haven’t been able to find who actually said it. If you know, please tell me.

When you get pretty good at something, you can start doing it without thinking. Perhaps you can get up in front of people without having to prepare or write without having anything to say. Maybe you can start hacking away on a software project before you really know what you want it to do.

In some ways that’s good. If you want to improve your craft, you have to do it. Sometimes it’s best just to dive in and see what happens.

Sometimes it’s not so good. You can spend an afternoon or a week or a year building something that nobody wants.

So it makes sense to balance doing with envisioning. Before you sit down to practice your craft, ask yourself the simple question, “What am I trying to accomplish?” Picture the outcome in your head. What does it look like? How do I get there?

Got it in your mind? Good. Now sit down and make it happen …

BUT – as that conductor pointed out, the “music” you envision in your head never sounds exactly the same as the music in the room.

On the way to building the software you envisioned, you found shortcuts or obstacles or serendipitous detours. Sometimes you have to plow past these to realize your vision – but sometimes you have to alter your vision to take advantage of what your software and your customers tell you. Building software is an ongoing negotiation between what’s desirable and what’s possible.

Whether you’re creating software, making music, writing a blog, or sculpting, the goal is to maintain a lofty vision while bringing your vision and your reality as close together as possible.

The wisdom of low quality

There are some things in life where it’s important to do a great job. For example, the difference between being an OK musician and a great musician is an enormous amount of work … but it’s worth it, both to the musician and the audience.

Surprisingly, there are things where it’s NOT important to do a great job – it’s only important to do it. And trying to do a great job where you shouldn’t can actually prevent you from doing a great job where you should.

I thought about this yesterday while shoveling snow. The difference between shoveling and not shoveling is huge – you can’t get your car out of the driveway if you don’t clear a path. But the difference between shoveling and shoveling perfectly is insignificant. Does it really matter if there are little strips of snow between shovel strokes? Does it really matter if the sidewalk has perfectly square edges? No. It’s snow – it’s going to melt eventually anyway. Just push the snow around to clear a path for your car and clear a path for pedestrians as quickly as possible – time saved doing a mediocre job shoveling is time that can be spent doing something more worthwhile.

So what about building a startup – is there anything like shoveling snow in a startup, something that’s more important to DO than to DO WELL?

One thing that comes to mind is managing email. Fred Wilson spoke about email the other day – he gives it an hour in the morning, an hour at night, and maybe an hour in the middle. He does what he can during that time, but he’s not willing to invest more in the overall process. For him, “doing email” seems to be like my shoveling the driveway – just get as much of it done as possible, but it can never be perfect.

I’ve never emailed Fred Wilson, but I have corresponded with Brad Feld and Seth Godin, two other famous startup people who receive a shocking amount of email yet respond personally to any reasonable request, usually within 24 hours (in fact usually within 5 minutes). How do they do it?

For starters, their emails (at least to me) are very short. They trust that I will be thrilled to get a reply from them, so they don’t bother setting me up with useless niceties like “It’s very nice to meet you, Patrick …” It’s more likely to be a reply like “thanks” or “yes” or “not at this time.” Seth once gave me very quick feedback that I wrote something “generous,” which meant a lot to me, coming from him. I once asked Brad for an interview, and he simply replied back, including his assistant, saying “+1 [assistant’s name] please schedule.”

I want to be the kind of person who replies back to every email I receive and doesn’t leave loose ends. I am not that person yet – not even close. To get there, I’m pretty sure I need to learn what Brad and Seth (and probably Fred) were forced to learn a long time ago – it’s better to get email done than to get it done perfectly. If I don’t have an answer for a request, I’ve got to learn to reply back with something like “I have forwarded your message to a colleague, and I will let you know when I hear back” or even “I don’t know, but I will let you know if I find out.” That’s better than what I do now, which is stroke my chin, put it in a “tickler” folder that gets buried worse than my inbox, and never get back to it.

I want to answer every email with a wonderful nugget of helpfulness, but I simply can’t. Too often, that reality ends up burying me, which gets me down. And that feeling of defeat impacts my ability to do the rest of my job well.

The fancy word for this is satisficing: “a decision-making strategy that attempts to meet criteria for adequacy, rather than to identify an optimal solution.” Every email requires a decision. If you attempt to maximize every one of those decisions, you will never “finish” your email. That leaves you with a stack of unmade decisions which is worse than a stack of adequate – but completed – decisions.

Email is never going away. I just need to learn how to do each one a little bit more poorly – it’s better than not doing it at all. It’s counterintuitive, but the end result is actually “doing email” better.

User expectations

I had work in Chicago yesterday and today (I’m taking the Amtrak home at the moment). I stayed at the Swissotel. It’s a nice hotel – great bedding, good bathroom, and one of the best views I’ve ever enjoyed in a hotel room.

WP_000168

Whoever designed the hotel apparently wanted it to be kinda hip, so they did a couple of things a bit differently …

First, the elevators don’t have any buttons in them. Seriously. Before you get on the elevator, you type your floor into a keypad, and then it tells you which elevator to get on (A through F). That elevator is going to your floor.

Second, the light switch in the bathroom doesn’t just go up and down. No sir, this one goes up (full on), middle (off), and down (half on). Clever.

I’m sure both inventors were confident they’d found a better way of solving a problem. Perhaps the elevator mechanism is more efficient in some scenarios. I’m pretty sure that dividing 30 people evenly across 6 floors is WAY more efficient with this mechanism than with the standard one. Many people would arrive at their destination faster and the total mission would be accomplished sooner.

And the light switch is neat – two on settings in one switch! Surely that’s better than 2 separate switches. But I only discovered it because I’m apparently a heavy off-flicker of lights.

Here’s the thing … the old way was FINE. I don’t want to re-learn how to use an elevator, especially not for a short stay at a hotel. I could MAYBE see it in an office building, but even then – there are two many visitors. It’s just not worth it. The only upside is getting to watch a random usability test every time someone new checks in.

As for the light – it was actually kind of irritating the second and third time I tried to turn off the light and only made it halfway off. Not the feeling of delight I assume the designer was going for.

As a user, I have pretty ingrained expectations of the way these things work. The inventors might think their ways were better, but I am confident that a survey would show few other people prefer these specific inventions over the “norm.” If you’re going to change something where users have ingrained expectations, you better make it a slam dunk. It better be a LOT better. Some examples:

  • Josh Linkner just talked about a new thermostat that users seem to like a lot better
  • Digital photography is a LOT better than film for most applications. Even though it had a couple of negatives at the beginning (slow response, lower quality images), the pluses were so much better that film is essentially dead
  • I’m biased, but I think the live tiles on my Windows Phone are WAY better than a grid of apps (join me people!)
  • Remember when the little red squiggly line replaced the old spell checker in Word 2.0? SLAM DUNK BETTER

The point is, when users have an expectation, you can’t just change it to a way that YOU think is better. You have to change it to a way that MOST users think is better – preferably a LOT better. Otherwise, you might as well just meet users’ expectations.

While we’re on the subject of hotels, here is what I DO want: I want an easily accessible plug right by my bed. I use my phone’s alarm clock, and I recharge my phone over night. I need a plug near my bed to meet both of those needs at once. And please – give me a clock in my room with a dimmable light or no light at all. I don’t like big LED’s shining into my eyes. Often, I have to pull out the nightstand and unplug the clock to dim the light and have access to a plug. Dusty. Low rent.

But you know what – the Swissotel had both of these things! Perfectly dimmable clock and a classy plug on the lamp. Combined with great bedding and a great view, it made me quite fond of this hotel.

One more thing I want in a hotel – a bathroom nightlight that’s on by default but that doesn’t shine so bright it’s annoying from bed. Would eliminate a lot of bruises and cursing.

What do you think – am I wrong (about user expectations or hotels)?

Node.js on Windows Azure

Last week, I wrote about getting a node.js hello world app running on my local machine in 10 minutes. But what if you want to run node.js on Windows Azure? Turns out that takes about 10 minutes to get running as well – and you can do it from Windows or Mac … in fact, any machine that runs Chrome (or Firefox or Safari … any major browser except IE, the market leader that gets no love Winking smile).

While you can create a local environment for node.js development on Azure, the Cloud9 IDE runs in a browser. That’s a very low-friction way to get started. Eventually, you still might want to get the Visual Studio environment working, because the remote debugging features are pretty outstanding, and they require VS. But for now, just follow these instructions for creating a node.js hello world on Windows Azure.

I considered writing up a separate set of instructions, but I don’t think I could improve on these. If you have any trouble as you are following along, don’t hesitate to contact me. Remember that you can get a 90-day free trial easily, and if you are a startup you have access to a LOT of free Azure through your MSDN subscription (in fact, if you have an MSDN subscription from any source, it includes Azure benefits).

The experience is awesome – I’ve been excited about the possibility of a browser-based development environment for some time, and node.js on Cloud9 to Azure delivers. I could see building a fairly sophisticated app purely in this environment (although again, I’d probably want to take advantage of remote Visual Studio’s debugging or unit tests at some point).

The only thing I found to be slightly janky in the example is creating a new deployment … if you choose to create a new one on this screen:

create a new deployment

Then make sure you overwrite the existing deployment name that shows up on the next screen:

create a new hosted service

In future node.js post, I’ll discuss some scenarios that are good fits for node, and I’ll review javascript itself and what’s different programming server-side javascript compared to client-side.

Startup stages

Startup America is an organization created to help startups, and it’s funded by the likes of Steve Case (AOL), The Kauffman Foundation, Michael Dell, and many other big names in entrepreneurship. They want to sign up lots of startups, so they reached out to partners like TechStars and Microsoft’s BizSpark to help recruit.

My teammate Brian Gorbett is the Microsoft startup evangelist for my part of the country (Yay Central Region!). Technically, I’m more of a not-yet-huge-software-company evangelist, but my passion is obviously with startups. Brian is the one actually responsible for making sure startups get signed up and get what they need from Microsoft resources (primarily BizSpark).

Recently, Brian started promoting Startup America – and he’s engaged in a challenge with our counterparts in the West and East to see who can do a better job spreading the word about it. If you have a startup with 2 or more people working on it, please sign up using Brian’s link. You’ll get access to some useful tools, and we’ll get to talk smack about the other regions. Win-win. To sweeten the pot, Brian is offering an hour of startup mentorship to anyone who signs up using his link. He’s a smart and helpful guy, so I think that’s a pretty good offer. I hope you take him up on it. Tell him I sent you.

The most interesting part of Startup America’s site to me is their explanation of startup stages and the way they relate it to company size:

  • Idea – you’re a single founder
  • Startup – 2 or more people … you’ve taken on at least one co-founder
  • Rampup – 6 or more people … your company now has employees
  • Speedup – 25 or more people … your company is making it big

It’s not a perfect model, but Startup America appears to be focused on startups as a job-creation engine, so it makes sense in that context. They want companies to hire, hire, hire. One implication of this is that they don’t nurture companies at the Idea stage – you have to have at least 2 people to join. I don’t have personal experience with the organization, but it looks interesting, and it doesn’t cost you anything.

If it sounds interesting to you, please sign up using Brian’s link.

Quantity begets quality

Yesterday, I tapped out a blog post using the WordPress app on my Windows Phone, quoting wisdom from Jerry Seinfeld. It was a bit self-referential, and my twitter friend Adam called me out with some good-natured ribbing – he claimed that I was cheating, that I wrote a tiny blog post merely to keep my streak alive of blogging every day. He was absolutely right … but I didn’t break the chain.

Why start a writing streak? Why start any streak? More importantly, why keep with it? Why deal with the considerable annoyance of doing something on those days when it’s enormously inconvenient – or when you just don’t feel like doing it? Surely Seinfeld’s “don’t break the chain” concept doesn’t work … I mean, what’s to be gained simply by doing something every day?

If getting good at something is important to you, then you need to do it a LOT. Especially when you’re a beginner, you need to fight through doing something poorly in order to get good. And you have to do it over and over.

I’ve mentioned it before, but I love this story about Quantity vs. Quality from the book Life is a Verb:

A college ceramics teacher decided to do an experiment with his two fall pottery classes. He told one class they would be graded solely on the quantity of work they produced that quarter and their grade depended on the number of pots they threw — so the more the better! The second class was told their grade would be determined by the quality of their work and they only needed to produce one “perfect” pot.

The better quality pieces came from the class that was graded on quantity. As they were making all those pots, they were getting better and better at pot-making. Instruction, knowledge, effort – they’re all useful for getting better at something, but NOTHING replaces doing it over and over … quantity leads to quality.

Writing is important to me, and I want to get good at it. There are all kinds of ways I can learn more about it, but nothing can teach me as much as doing it over and over. By deciding that I’m going to blog every day, it forces me to ask myself how important writing really is. I was very busy yesterday – we had a birthday party for Gus (9!), and afterward, I took him to a YMCA campout. Those things are obviously more important to me than some stupid blogging streak, but I could have planned ahead. The streak nagged at me, and I’m happy it did. I’m also happy to live in a world with mobile apps that let you do just about anything.

I have so many things happening in my life – I know that when I do break the chain, I’ll likely blow off writing again for days, maybe weeks. Before long it becomes one of those things that I’ll get back to it “someday,” but someday never seems to come.

For me, a streak is just a fun way to remind me that I need to do something over and over.

What are you learning that’s important to you and what are you doing to get better at it? What are you doing to make sure you do it a lot? If you’re going to get to it “someday,” how can you make that someday come now? If doing something every day isn’t your thing, consider using one of these Zig Ziglar workbooks that Seth Godin republished.