Early stage companies have to be nimble and disciplined when creating and releasing product. One of the important decisions a startup can make is how it chooses to manage its product releases. In a software company a product release affects everyone. A mistimed release can severely impact sales, cash flow, and the company. We had a thorough discussion in a board meeting this week on this very topic. I have to admit I was quite pleased with our new VP Engineering as she put forth her methodology and process, shared below.
There are a couple of different ways to manage engineering releases. One engineering release is date driven, the other is content driven. In a date driven release, the team knows when the next release is out but does not know exactly what will be in it. The release runs like a train schedule, whoever makes it to the station on time is part of the release. The other release is content driven; the team knows what is in the next release, but does not know the exact ship date. The release runs more like an airplane shuttle, it takes off only when full.
While I may be oversimplifying the issue, the one that I like my companies to subscribe to is the date driven one. Of course, just because it is date driven does not mean that there isn’t a highly focused theme. It just forces the team to clarify the absolute minimum requirements necessary to deliver the right product for the market. It also discourages feature creep and encourages highly disciplined prioritization. Most importantly, having a date driven release can get everyone at the company aligned. Everyone knows the ship date and sets their schedule accordingly to ensure that all pistons are running as GA hits. This means marketing has to have its collateral ready, upgrade program in place, and product launch schedule set. Sales knows when it can start telling prospects about the new product and time it appropriately so it can get customers lined up for the next quarter without delaying sales in the existing one. Engineering, of course, needs to deliver product and not get distracted. While all of this discussion on product releases sounds great, none of it really matters if you do not have the experienced team that can manage them and instill the discipline. So as you think about your next product release, think long and hard about whether you want the trains to run on schedule or the airplane shuttle to be full. You know where I stand on the issue.
One of the wonderful things about delivering “software as a service” is that scheduling “releases” is purely a marketing event…new features can be seamlessly deployed as soon as the code to support them meets our quality and stability thresholds. This eliminates the tension between date-driven and feature-driven approaches, as the better choice will generally be obvious once we have an answer to the question of why we feel the need to announce a new release.
(We generally announce new releases to promote new features we’ve incorporated recently that we think will help build sales, so they tend to be feature-driven…but I can see how a different kind of firm would prefer a date-driven focus.)
“Engineering, of course, needs to deliver product and not get distracted.”
Well said. But I do have the firm belief that the only people who can deliver on this are engineers with a bit of business savvy. Non-technical managers almost always fail at this. Not because they’re incompetent, but because it’s harder than it looks, and you need to have a feel for what’s possible and what isn’t. No amount of “discipline” enforcing 80 hours weeks is going to change the laws of physics. Just take a look at the backgrounds of the leadership of Microsoft, Oracle, SAP, etc. All engineers who went native 🙂
You can’t make money flying an empty plane. In other words, are you releasing a product to meet a date, or are you releasing a product to meet a market need? Perhaps the discipline of meeting a date is important for a young company but my experience is that you don’t want to go through the expense of a release unless you’re sure customer needs will be met.
Steve-totally agree with your comment.
As you see in my post, I mention that “Of course, just because it is date driven does not mean that there isn’t a highly focused theme. It just forces the team to clarify the absolute minimum requirements necessary to deliver the right product for the market.”
I am just saying that too often companies get obsessed with filling the plane with too many features and requirements without doing the hard prioritization and analysis of what is most importantly going to make customers happy and drive new sales.
Richard also has a great post on how schedules don’t make the trains run on time but people do. So it also requires having the right management and experience to balance the priorities to deliver the right product on time.
This also implies a commuter train that has various times when the train is not full depending on time of day. It runs on a schedule and therefore may not be filled to an efficient capacity or overly filled during rush hour. So what is the balance of the amount of content versus releasing for the sake of a release?
It seems the balance of the two is what should be considered.