That’s why you play the game!

I just finished watching the Giants beat the Patriots in the Superbowl. I had not actually intended to watch the game, because I really had little interest in who won. Then I figured, no matter who won, a certain amount of sports history would be made.

Going into this game, no one (myself included) gave the Giants much chance of winning. Up until a few weeks ago, no one would have guessed that they would even be playing. That brings me to the point of this post – the fact that stats really are irrelevant. On any given day, any team can win. That is why they play the game.

This carries over into the “real” world. Whenever you are starting something new – whether it is a business, or a new innovation, or anything else you can think of – there will always be lots of people telling you not to play in certain games because there is no chance of winning. The fact is, there is almost always some chance. It may be slim – but what it comes down is whether you execute better than the other players on game day (only in the real world, everyday is game day).

So do not always run away from the game because there are players out there with better records and better stats. All you have to do is go out and play better.

Easy, right?

GigaOM Web Innovators Group: Boston Startups Come Out & Present «

I noticed this over on GigaOM GigaOM Web Innovators Group: Boston Startups Come Out & Present «. I noticed that a company called frevvo. This company was founded by a gorup of people I have worked with in the past. They have some cool technology that is worth checking out (I would describe it, but hey, go look for yourself!)

Am I getting too old for this?

So it is the weekend, and my brain is tired from being on vacation all week (I read even more when I am on vacation than when I am at work – that is why I take vacation, to catch up on my reading!). Looking at a lot of stuff I am following lately, much of it relates to social networking, web 2.0, mashable content, etc. – much the same as everyone else in this business I guess.

There is also a significant amount of press related to age, and this being a young person’s game.

You know, the idea that no one who is not in their 20s or younger should be starting a Web 2.0 business, and people in their 40s are completely out of it.

Now, I personally do not buy this for a minute (probably because I am in my 40s). I do start wondering, however, whether I really grasp all of this stuff. I get a lot of it, but some of it is just beyond me. I have already talked about Second Life, and I still am not convinced that it is meaningful. There are Twitter and Pownce. These I just do not get. I do not need to know that much about anything anyone is doing. Mashups I get, and I wholeheartedly agree with the idea, but I do not think I get them on that deeply intuitive level.

So, I ask the question. Am I getting too old for this?

Someone Already Thought of My Idea – Now What?

This post Someone Already Thought of My Idea – Now What? is a few months old, but I just came across it tonight. it makes some very good points about a problem I think many of us have – we want to come up with that brand new, perfect idea, that no one else has ever even dreamed of.

Well, it is probably not going to happen. No matter how smart you are, there are many many people out there as smart or smarter (unless you are that one person out there who actually IS smarter than everybody else – it is not me, so I am not going to worry about it), and it is highly likely that at least one of them will have thought up an idea very similar to yours.

So, what do you do about it? Well, you do not give up for one thing. Just because someone has the same idea you have, does not mean they have the same business you have. There are so many variables, and so many opportunities to innovate every aspect of your approach, that you absolutely can do it better than someone else.

Ultimately, it comes down to execution. Given two people/organizations with the same idea, the one that executes better has a much higher likelihood to win. Note that no matter how good your execution or anything else, there are no guarantees – you can do everything right, make no mistakes, and still lose (I think Picard said that on STNG – kind of sad that I am quoting Star Trek wisdom!).

I will make an analogy with football (I frequently do – and I mean American football, not soccer). Both teams in a football game have the same objectives, often have very similar levels of talent, are on the same field with the same playing conditions, and really have pretty much all the same tools and strategies available to them. More often than not, the team that wins is the team that executes the best on game day – executes on the fundamentals, and does not do things to hurt themselves.

Much the same holds true in starting a business, and when you find out someone else has had the same idea as you, you only have two choices: execute better than them, or leave the field and find a new game.

BREAKTHRU – New Brunswick’s Business Plan Competition

The New Brunswick Innovation Foundation (NBIF) is running a search for “the next generation of New Brunswick entrepreneurs”. So, all of you would be entrepreneurs should definitely check it out: BREAKTHRU – New Brunswick’s Business Plan Competition

(I know, this was announced 2 months ago – I can be a little slow posting things!)

Computing Infrastructure as a Utility

Just read Nirvanix To Challenge Amazon S3. I have been playing with Amazon’s web services for a number of months now, and I am impressed with some of what is there, and Nirvanix looks to be in a positions to challenge the same space. I find it interesting to look at some of the “success stories” on Amazon’s web site, reflecting to the potential for web startups to avoid large initial investments in infrastructure. Even in a well funded startup, it would make sense to focus resources on core IP, as opposed to buying infrastructure.

In my opinion, this is a more fundamental shift than many trends receiving a great deal more hype. Previous ASP hosted models, and more current SaaS models are less fundamental than this. To have a computing infrastructure that performs like a utility opens up many new possibilities.

Now I just have to figure out what they are 🙂

Hiring Programmers – the Good, the Bad, and the Ugly

I had a read through this A Guide to Hiring Programmers: The High Cost of Low Quality today, and found it very interesting. At a high level, I agree with the article, concerning the relative value of hiring the best, versus hiring whatever you can find. On the other hand, I have my own distinct opinions on this, and cannot resist sharing them 🙂

First off, despite the great content of the referenced post, the fact that it is buried in “Perl is the ultimate language” rhetoric is unfortunate. Whenever I hear anyone claim that any single language is the ultimate language, and that all enlightened programmers would use it if only they had the choice and the wisdom I get really worried (and frequently giggle). I am reminded of a statement I read once: “An idea is a dangerous thing when it is the only one you’ve got”. There is no such thing as a language which is perfect, let alone perfect for all applications and solutions. Over the last 25 years, I have programmed professionally using somewhere around 30 different programming languages. A fairly large number of those came with promises that they were the ultimate programming language. It was crap every time, and it still is. Give me a programmer with real world experience in many different languages (and many different domains if possible) every time. They have a higher probability of using the right tool for the right job, and can more easily learn new languages as needed.

Here are a few other comments I have on the hiring of programmers:

  1. Always hire the Best. This is, unfortunately, somewhat ambiguous. What does “best” mean? Does it mean the same things in all contexts? just because someone was the star of their last team does not guarantee that they will work out on your team, on your project. Also, time plays a big part. Can you afford to spend a year finding the perfect person (see point 4, below)? 
  2. Don’t hire programmers. Hire developers. While there are places on the team for hard core coding machines – people who live and breathe bits, people who can hold conversations in hex – I do not need a whole team of them. I need more rounded people (especially in a startup, where resources are tight and roles need to be flexible). I need people who can interact with users (i.e. paying customers), with marketing, with senior management, and who can understand the bigger picture beyond their debugger.
  3. More Education <> Better programmers. Many of the worst programmers I have met had Computer Science degrees from great schools. Many had graduate degrees. Some of the best programmers I know have little to no university education in software development. When I am looking for good programmers, or better yet, exceptional programmers, I am looking first and foremost for thinking ability. I want people who have demonstrated problem-solving ability. I am looking for people who know how to learn, and know how to explore things which are new to them without getting scared. I would rather have a competent programmer who knows how to solve real problems than a genius programmer who is all theory.
  4. You Can’t Always Get What You Want. Finding the people you need is never easy, and always risky. You always need them right now. You always need them to “hit the ground running”. Well, that’s not always the way it works out. You can spend a year trying to find just the right person, and after that year, you may still be searching. Sometimes it is better to find a smart person with the right raw materials (a smart new grad, or a smart person with a few years under their belt, but not the exact skills you want) and grow them into what you need. I have had a lot of success with this in the last 10 years.
  5. Years <> Experience (necessarily). I have seen resumes come across my desk from people who had been working for 10 years, but did not have 10 years of experience. They had 1 year of experience, 10 times over. I have seen people who had been working for 3 years who DID have 10 years of experience (not really, but you get my point).
  6. IT Analysts are not Product Developers. This is one I am shaky on, but I will throw it out there anyway. In my experience, most people who have spent their careers working in IT shops in big corporations have no hope of making as software developers in a product-oriented development team, especially not in a startup. There just seems to be some mental conditioning which makes it hard to do that transition.
  7. Never underestimate the impact of a BAD developer. We have all hired them. People who for one reason or another do not work out in our team. Maybe they are idiots. Maybe they were burnt out on their last job. Maybe they are really good, but just do not fit in with the team or the project. Whatever the reason, never underestimate the impact they are having on your project. Their productivity will suck. Their presence will bring down the productivity of those around them. They can kill the morale of your team (which can be pretty fragile to begin with). Get rid of them. Take action sooner than later. If you think you can save them, take action in that direction, but set hard deadlines for improvement. If it comes down to it – get rid of them. Ultimately, you, your team, and probably the misfit employee, will all be happier for it.

I probably have more brilliant wisdom on this subject, but hey, it is midnight and I am supposed to be on vacation!

Oh – one last thing. The comment “It is the difference between Apple and Microsoft” is a mindless generalization, and is not worthy of the rest of the post. Microsoft has many groups of very talented developers turning out great code and great products. So does Apple. I would only say that Apple seems to have a distinct advantage in design – and I suspect that comes more from an all-pervasive culture than from hiring practices.

Another Big Day for Whitehill

It was announced yesterday the we (Whitehill Technologies, Inc.) are being acquired by Skywire Software. This represents another big day in the evolution of Whitehill as a software company. It is also another great example of a successful, viable, important software company being born and grown right here in Moncton, New Brunswick, Canada. If you want to read more about the deal, you should look at the news releases – there are lots out there. I think congratulations are in order for Paul McSpurren and all the others who put this deal together. Well done.

It is an interesting time for me to look back over the last 8+ years I have been at Whitehill. At the time I joined, we were barely out of the “startup” stage, having only about 30 employees, and probably a similar number of customers, 1 product, and a lot of heart. A large number of people have stayed with us for the whole ride (this continuity I think has been a major factor in our success). It is amazing to me to see how far we have come.

I would like to thank everyone with whom I have worked at Whitehill all these years. Well done, everyone. It has been a wild and interesting ride to be sure, but I am proud to have been part of it, and to have worked with all of you (not that I am going anywhere – just feeling sentimental!). Everyone involved, past and present, should feel proud as well. 

I am also looking forward to the future here – and to all of the challenges and opportunities before us.

Playing to the critics

This is a follow-on post to my earlier discussion of New Product Ideas – How hard can it be?. In that post I talked a bit about what I consider to be the “fundamental” questions in coming up with a new business idea:

  1. What do you want to be (multinational, micro-ISV, etc.)?
  2. What domain do you want to work in (horizontal apps, specific vertical, specific technology, etc.)?

I also promised to discuss, in a later post, what do once you have figured out these two simple questions. Sorry it has taken so long to get back to this.

Getting Ideas

So now you know what kind of a business you want to build, and you have an idea of the space you want to be in. Where do you go from here? A quick Google found several hits with suggestions for generating new product ideas. Here are a few (I am not endorsing any of them – they are just a few from the first page of hits ):

There are a few random thoughts that I have on the subject. A big one to me is the fact that you cannot spend all of your time “playing to the critics” (hence the title of this post). In the software world, playing to the critics means, among other things, trying to do what the analysts and marketing gurus and other “experts” say you should. I am not saying you should not read and absorb as much as you can from these sources, and indeed from any source you can. However, the ideas ultimately have to come from you – they cannot be analysed into existence, and you can wait for someone else to tell you what to do.

So where do ideas come from? Well, getting ideas is like anything else. It takes practice, and the more you practice doing it, the easier it gets. Here are a few of the approaches I use:

  • Keep a notebook for ideas (I know, everyone suggests this). I personally use my Tablet PC for this, using a combination of OneNote and Mindjet. I like this because I typically have my Tablet with me all the time, and it allows me to capture ideas I get anytime and anywhere – in meetings, seminars, anywhere.
  • Set aside time for brainstorming. Whether it is daily or weekly or whatever, it is good to set aside time brainstorm. It will be hard at first, but it gets easier with time. I will admit that sometimes this is my best approach for getting ideas. Other times, ideas come at me so fast using the first method that I do not really need to set aside time for this. I try to anyway.
  • Read as much as you can. Learn new things as much as you can. Read anything. Read web sites. Read blogs. Read books. Read magazines. Read things in your area of expertise. Read things in other areas (I find many of my most novel ideas come from “cross-over” concepts that I pick up). Read, read, read, read.

Ultimately, these are approaches that work for me. You will have to find ways that work for you. Back before my Tablet PC, I used to keep several flipchart pads on the wall of my office. I would fill these with ideas, tear off the pages and tape them up all over my walls.

An important thing to remember is not to filter or judge your ideas at the same time you are generating them. Just collect them. Also remember, the best way to get good ideas is to get LOTS of ideas.

Evaluating Ideas

Speaking of this, how do you know which ideas are good ones, and which ones are, well, not?

I try to set aside a regular time every week or two to look through my accumulated ideas. When evaluating my ideas, I look at several things.

Firstly, I filter out the ideas that are just plain stupid. This is hard to do sometimes, because I do not generally like to admit to myself that I have stupid ideas. But I do! Lots of them. Sometimes I look back on ideas I came up with randomly in meetings a couple of weeks earlier, and I really have no idea what I was thinking. Do not dismiss things too easily, though, because sometimes what seems like a crazy idea just seems crazy because it is for something really original. I never throw ideas away – and sometimes ideas on the crazy list come back to life.

Secondly, I compare ideas against the “what I want to be” questions. This allows me to eliminate ideas that are just completely out of scope for what I am trying to do. Some ideas are great ideas, but just do not fit the scope of what I am trying to do. Again, I never throw them away. Maybe next year, I will have changed my mind on what I want to be. Or maybe I will come up with a way to change the scope of the idea and make it fit.

Finally, I am left with a list with a list of ideas which are not obviously crazy, and which seem to fit the model of what I want to do. What next? Well, some time back I posted on here about exactly that. It all comes back to NABC:

  • Does the idea fulfill a real need?
  • Do I have a credible approach?
  • What is the benefit versus cost of the idea?
  • Who are the competitors? What are the competing approaches?

Personally, I still find this the hardest part of the problem. Right now, the approach I use is to transfer all the “surviving” ideas to a spreadsheet, with columns for each of NABC. I start by quickly going through and filling out what I already know for each idea. For some, I understand what need I want to fill. For others, I have come up with a really great approach to filling a not very well defined need (hey – I AM a techie afterall!). This is just a way of capturing what I already know, so it does not take very long. Then I go back and try to complete the need for all of the ideas. This is always enlightening – it still surprises me how hard it is to succinctly express the need fulfilled by an idea, even when I think I know it.

Ultimately, at this stage, I am trying to identify those ideas for which I CANNOT have some answer to the four questions. This filters out a good chunk of ideas at this stage – many seemingly good ideas do not pass this gate.

So what next? Well, the ideas which survive this initial analysis are worth taking a deeper look at. And that will have to wait for another post – hey, it is 1 in the morning!