Archive for the ‘Work’ Category

Bob and I had a true luminary on our podcast this week – Steve Blank, the founder of the principles of Customer Development. I was a little star struck! Prof. Blank is one of the most important entrepreneurial thinkers of our time … I felt so lucky to have the opportunity to speak with him.

While reviewing his first book and talking with him, I came up with a summary of the most important lesson for a software developer like me who wants to be an entrepreneur – focus on WHO, not WHAT.

I just had dinner with some other programmer/entrepreneur friends, and I saw the same impulse in them … it’s so exciting to focus on the product – the WHAT – that it’s hard to focus on the customer – the WHO. It’s not enough to build a cool product. You have to be able to find the person who will buy it. It’s all about the WHO.

The real pleasure of getting to meet my heroes like Steve Blank is just getting the sense of who they are as people. My impression of Steve Blank is that he is very kind. He really cares about helping entrepreneurs learn and succeed.

I hope you listen to the show. It’s one of my favorites that we’ve done. Also be sure to buy Prof. Blank’s just released book, The Startup Owner’s Manual.

Read Full Post »

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> …

Read Full Post »

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.

Read Full Post »

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.

Read Full Post »

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.

Read Full Post »

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.

Read Full Post »

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.

Read Full Post »

Older Posts »