An Honest Discussion About Windows of Opportunity

I originally wrote this post in May of 2009.  We couldn’t post it then and risk revealing the launch plans of some of our clients.  Our end of year projects helped validate the post so we decided to publish it now.

We were seeing a new wave of companies ramping up to release in the fall as with previous years.  This was just one of many signs that we felt the US economy was turning around.  Money was flowing, new projects were getting some funding, and development teams were being staffed.

As usual, most companies targeted October listing a window of opportunity as the driving factor.  I first referred to this phenomenon in my post about the 2-month launch.

We have had many customers successfully hit October.  One company launched and closed an impressive round of funding shortly thereafter.  Another signed up a Fortune 500 company before the end of the year.  We are very proud of what these budding enterprises achieved.  What’s the one thing that has not happened?

Not a single one has seen any validation that a window of opportunity really existed.

Opportunity?  Yes, definitely.  A window?  One that might close soon?  In my opinion, absolutely not.  The opportunity available to these companies is no better or worse before or after their launch.  The proverbial window remains open for everyone even to this day.

Defining a market window is like trying to predict when the recession you are in began.  Was the Internet search market opened by the invention of the Web or the rise of Yahoo?  If Google closed that window, how do you explain bing? The iPod entered a crowded MP3 market.  facebook is clobbering myspace who left friendster in the dust.  The list goes on and on.

I was reading an essay by William Gates Sr. about his son Bill.  He said Bill left Harvard before graduating to create software for the Altair 8088 because, and I quote, “to take advantage of a window of opportunity he believed would be long gone by the time he graduated”.  This is like seeing a Model T and thinking if you don’t get into the car business soon you’ll miss out.  Laughable now, but I am sure those early companies felt this way just as Gates did and most start-ups do.

I am not saying that windows of opportunity are a complete myth.  Did everyone think Twitter would become this huge or that there was a market for really short messages?  One of our start-ups truly has a unique opportunity.  They can point to market factors, new legislation and a host of other factors converging on what truly looks like a new opportunity.

Hitting a specific window of opportunity is not the dominant factor that determines who survives in my opinion.  New opportunities open up all the time.  Eventually markets become crowded and finding success becomes more difficult.  Companies need to focus more on obtaining an impenetrable position instead of nailing the start or end of a window.

What do I conclude from all of this?

1) Running a start-up successfully is a marathon not a sprint.  Having the early lead in a marathon doesn’t matter that much. Just ask Yahoo or friendster.  You still could easily lose to runners managing their race better if you don’t do the same.

2) Windows of opportunity are very real, yet they don’t exist just because you want to launch in October.  Base your launch time on smart planning and not only on hoping to capture the big spending months before the holidays.

3) If the TechCrunch post about you lists competitors already up and running, then your product is probably not going to create a new window.  Your first mover advantage is already gone.  Learn as much as you can from your competitors.  Most importantly, don’t assume they are standing still.

Here are some different launch goals to consider along with the date of your launch:

Considering launching off-season.  This allows you to fine tune your offering and your infrastructure.  When you expect your most explosive growth, would you rather have a new product that you are still vetting or a proven solution supported by well-trained people?  Maybe ask potential customers this question?

Consider launching based on milestones instead of dates.  For example, launch after you have 500 active beta customers on the system for 2 months or more. Do you think potential investors will care about October if you can show your product is “sticky” for users?  Maybe ask potential investors this question?

Consider launching based on your financial goals.  Your product must be in the market generating revenue at a certain rate to hit your break even target.  Managing to cash flow positive is something many companies may have to do in this changed economy if you believe our predictions back in 2009. Maybe ask your executive staff this question?

I realize that windows of opportunity are one of the many motivators that drive teams to achieve the insane.  Gates may have been wrong about the market for Altair software, but his drive on that opportunity and all the ones that followed ultimately lead to his success.   Believe me, whatever the reason, you must have this drive.  Just remember that while October may seem important, surviving long beyond October is definitely important.

An Honest Discussion About Adding Features Late

Let’s have a good honest discussion about adding in features late.  I don’t mean late like the schedule is already set and this may or may not have impacts.  I mean late like the release is just around the corner and are you crazy!  If you work at a start-up, then yes, you might actually be crazy.

The problem with adding features late is that there never is a guarantee the feature will work out.  A last minute change could make the release and get you on TechCrunch.  Or you could put in something that doesn’t matter only to find you broke something that does.  Release management is a guessing game simply because companies never have enough time and resources to test everything a user might do.

Repeat after me.  It’s always a judgment call.  It’s always a judgment call.

We use software development processes to manage decisions like this.  Two of the most dominant development philosophies in use today are Agile Development and SCRUM though some people incorrectly think they are one in the same.  In fact, there is even a book called “Agile Development with SCRUM”.  However, there is one interesting difference in the foundation of these two approaches that illustrates my point:

SCRUM by definition:

During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. (a sprint is typically a 30 day period)

From the principles behind the Agile Manifesto:

Welcome changing requirements, even late in development.  Agile processes harness change for the customer’s competitive advantage.

SCRUM manages the risk by locking things down at some point and avoiding the conversation.  After all, the next release opportunity is only 30 days away.  Yet Agile foundations encourage a certain amount of flexibility and consideration. Being customer focused means sometimes taking the risk.

Make sure you check at the Agile Manifesto.  I would have given anything to be a fly on the wall during that discussion!

How late is too late?

We can certainly agree that if the software is going live tomorrow, responsibly we should only fix critical issues that render the product not releasable or worse yet that might corrupt customer data, right?  Other than that, there isn’t enough time to re-test everything and even the best guys make simple mistakes.  But what about embarrassing spelling errors or showing a login name with a poster’s comment?  The team can fix something as easy as that, can’t they?

Assuming the feature truly is important enough to consider, here’s what you should ask yourself:

  1. Is there enough time to do the change and test the change?
  2. Do we have someone we can free that we trust?
  3. Is the impact of not having it worse than the impact a mistake could have?

If you can get a yes to all 3 of these, then the risk is worth it.  If not, then you are pitting customer satisfaction against customer confidence if you make the wrong call.  Technical leaders in general would not proceed.  Individual changes are rarely that important in their eyes.  Product managers and execs almost always say go for it under the guise of “we can’t afford to wait.”

Breaking this problem down might not be as hard as you think. Put your late feature decisions into one of these buckets:

No brainer in – Yes, yes, yes to all three questions above.  We can get it done and tested and we have a guy we can free up.  It’s safe so let’s go for it.

No brainer out – The answer to most questions above is no.  There isn’t enough time, no one is available or the risk of mistake is far greater than the benefit to the business.  Don’t forget that customers often don’t miss what they don’t know about.

Hard calls – The answer to at least one of the 3 questions above is no.

The only bucket to keep you up at night is the hard call.  For me, the decision almost always comes down to the code base and the team.  Is the code base solid enough where I can take risks?  Is the team good enough where I can trust them with this risk?  I have been at companies where the leadership doesn’t understand why we don’t go for it.  The blocker is often that we are managing some level of legacy code that can’t be rushed.

I think that’s the hardest part.  Leadership and investors want companies that can release every two weeks.  Even with our own product hinventory.com we are following a release frequently strategy and it is working well. But if the product or team is not set up for quick releases, then I am sorry the answer is probably no…

…for the hard calls anyways…

…we can put the change into the very next sprint…

…are you crazy…

…do you really think that feature matters that much to risk the release…

…we’ll keep the change isolated and release it a few days after…

…maybe we can go for it but if we see any adverse effects we are reversing the change…

…it’s in the product but we’re going to keep testing after release and stay ready with a hot fix…

…see you all Saturday, at least the company is buying dinner…

I did say it would be an honest discussion.

Understanding Web Development Resources

You have a great new idea.  It’s a Web site or a product or some technology that can become the foundation of other solutions.  What kind of team do you need?

Outsourcing removed the interview process from setting up your team.  For many start-ups, that change normalized the resource pool as many outsource providers simply assign a team to the project.  In reality, there is a big difference between a developer who knows how to build an online Web store versus someone who can make Twitter scale or conceive of Ruby on Rails.

Let us help explain the difference between these types of resources.  First, we need a pyramid!

Companies have different levels or terms for engineers.  Here’s how I define them:

Web developer — A Web developer is good at creating sophisticated Web sites that have limited back end functionality.  His tools of choice are HTML/CSS/Javascript or Flash.  He loves walks in the park and open source CMS’s.

Software engineer — Software engineers are comfortable building more complex functionality that includes objects and business logic.  Ruby on Rails is the language Du jour for the hip and trendy alternative scene.  PHP is the blue collar worker’s hammer.  Java is the choice of old school guys who think the country has gone to the dogs.

Software developer — We don’t use objects, we are objects.  Pearl Jam is the new Grateful Dead.  If you haven’t modified a Unix kernal or developed in native C, then you are a poser!

Software architect — The architect is smarter than most of us, and you should avoid the ones who know it.  He spends his weekends looking for quasars or trying to eliminate a contradictory systemic anomaly from what is otherwise a harmony of mathematical precision.

For most of your projects, your team will likely be a collection of software engineers and web developers.  The more complex the project, the more you will need developers or possibly a seasoned architect.  The pay scale rises with qualifications obviously so we tend to look for one or two smart senior guys and then back fill with a cost effective pool of highly motivated individuals.

We took a look at our some of our projects from last year and charted them against the pyramid.

Understanding the type of project you have will help when selecting your team*:

Website or application – A Web site project in this case is a project that is mostly user interface with either little or standard back end functionality.  The site might have e-commerce, user sign-ups and dynamic content.  Back end functionality is supported by existing open source tools or by integration with other sites.

Product – Product development generally includes sophisticated back end functionality along with more complex interfaces.  The project often is based on some “secret sauce” that is protected IP, under a patent or otherwise considered a market differentiator.

Framework or foundation – Framework or foundation projects are projects that create technology upon which other solutions are created.

We’re product developers and like to produce complete solutions for our clients.  Framework projects are fun and challenging though there are simply less of them.  Of course, we love a good Web site project as well.  It’s just that they tend to be shorter and require more customization work than software engineering.

Next time you start up your a new project, it might help to classify the effort within this pyramid.  You can use the classification to define what type of engineers you should be asking for.

* A complete discussion of resources should include specialists and other disciplines including designer, tester, project manager and so forth.  I am working on a follow up post to help that aspect of your resource planning.

Follow

Get every new post delivered to your Inbox.