I wrote recently about transitioning my web development agency into a SaaS products company. This is a follow-up article on a related subject, encouraging innovation and developing a workable launch cycle, that I have been giving some thought to lately.
Here’s the issue. There’s an inherent challenge in transitioning from one thing to another. Often, the mindset required for the thing you’re moving from, to the thing you're moving towards, can vary. If you don’t manage that psychological challenge correctly, you will find it hard to succeed as effectively as you otherwise might have been able to do.
The transition I’m currently spearheading (that of a move from a service company to a product company) is no different in this regard. Servicing clients requires a different set of skills, focus and attitude compared to those needed when dreaming up, building, iterating and finally launching your own products. It is this ‘shift’ in the thinking required from each member of my team, that needs to be encouraged as we work through the wider transition at hand.
A team separated from the product launch cycle for too long, can be a dangerous thing
Products can easily fall into a rut simply because the wider team isn’t involved in the product launch cycle. Silo team members too precisely, without any exposure to the real job at hand (launching / selling / hustling - insert your chosen verb here!) and you will most likely find that that person will be good at that one thing, but pretty poor at the other. For a small team like ours, having people out of the loop and not ‘caring’ about the wider role their code plays in the underlying business can be a recipe for disaster.
Of course, I’m using the word ‘caring’ rather flippantly. Not to suggest that a person literally doesn't care, but to highlight that they might as well not as there is no clear return for them in seeing their code making a measurable difference for users.
At this moment in time I am spending close to 100% of my time on new product development (i.e. where our business is transitioning toward). In contrast, my developers are 90% focused on servicing existing clients (i.e. where our business is transitioning away from). Of course, at some point we will all be focused on products as opposed to clients. Until that time is reached, there is a danger that the divide between the two groups will grow rather than shrink.
Perhaps more crucially though, the longer this divide is allowed to exist, the greater the chance that my team’s outlook on the ideation process and the wider product → launch cycle will be severely affected.
We want to be pirates, but no one should be left behind!
Back when Steve Jobs set about building the first Macintosh, he and his team ended up working in relative isolation. They became fanatical and obsessed with their work. They were seen as outsiders and mavericks. They in turn saw themselves as pirates.
At this stage in the transition, it is important that we create a similar sense of camaraderie and shared obsession towards a single purpose. But only if we are all in it together. We are simply too small to allow factions to exist within the company. To allow a divide between the two areas of the business, will be to have failed.
Google’s 20% time to the rescue?
In looking for a way to encourage and stimulate a particular way of thinking, I was reminded of Google’s 20% time. A strategy devised to encourage fresh and independent thinking on a weekly basis. The idea focused around an allocated section of time that would be free from the shackles of day-to-day work remits and potentially even skill-sets. For 20% of a person’s time, they are encouraged to work on their own projects. Gmail was born through such an initiative. For Google, where they are able to mobilize large teams around promising new ideas born through this scheme, it clearly works.
By contrast, my company finds itself in a considerably different situation. We’re much, much smaller for one. To say that a new idea could have a meaningfully sized team allocated to it at the drop of a hat is quite frankly unrealistic. Imagine someone in my team stumbled upon a good idea during their lunch break or on a random Friday afternoon. That idea now needs to be turned into a reality. It needs a development and launch strategy. If your business isn’t already setup to deal with new, fairly frequent product launches then chances are you’ll find it incredibly tough carving out a meaningful schedule in which to properly focus on and then launch said idea.
For this reason, the whole 20% time irks me somewhat. It feels annoyingly idealistic and not practical or focused enough, especially for small teams. Small teams that stumble upon an exciting nucleus of a product, still need to have a strategy and resources in place to develop and launch them.
To prevent such problems and create an environment where new ideas can flourish and, most importantly see the light of day, a structured product launch cycle needs to be embedded into the very DNA of the company.
What a product launch cycle should aim to achieve
- It should be something that the entire team experiences and benefits from, as opposed to an insular activity undertaken by a single team member.
- The cycle should be made up of two key parts. 1) Business as usual. 2) Building and launching
- Time allocated to the ‘business as usual’ part of the cycle should be greater than that of the ‘building and launching’ part. The reason for this is two fold. 1) The team should be encouraged to become expert at launching under compressed conditions and 2) Allocating less than half the time to ‘business as usual’ will, well - end up not being business as usual and before long your core business or product will suffer.
- As well as placing an emphasis on the ‘launch’ part of the cycle, there should be an equal emphasis placed on what the team does when they are not in launch mode. For us, this means our core business is client work and managing our existing SaaS products. Thus, the non launch part of the cycle should provide us with enough structure and time to focus on these aspects. For your business, the focus might be different.
- During the launch part of the cycle (whether that is 1 week, 2 weeks or a month), the most important objective is that a product should be launched at the end of the exercise and either sold to early adopters or at the very least released as a beta to receive feedback. I.e. there should be a specific end-point; not just an exercise for exercise's sake.
Ultimately, this is all about creating a discipline around how teams approach and execute product launches. We don’t want the ideation process to become lazy within a company, or feature-sets on MPV’s to become too bloated.
In essence, it shouldn’t be exclusively about experimentation (although that is certainly a part of it) but instead about the discipline of bringing a team together for a single purpose. In addition, since this cycle should be periodically repeated, a wider aim for the team should be to become nothing short of expert at building and launching products. Each launch cycle should see lessons learnt from previous cycles implemented and improved upon.
The more fluffy, but still valid objective, one could argue, is that by focusing on inclusion, we embed excitement and focus across the entire team.
My proposal for a 6/1 launch cycle
Here’s a simple solution. Every 6 weeks our team will unite over one common purpose, for an entire week. For some, it could be a brand new feature within their existing product. For us, since we are focused on launching multiple products, it will provide us with a carved out, intentional block of time to build and launch a brand new product every 6 weeks.
For that week, we will each have focused jobs to complete. We will probably stay in the office late and yet we’ll feel united and determined. Pizza will be consumed, ping-pong matches will be fought over. A product will be launched.
Pizzas and ping-pong matches aside, perhaps the most compelling part of this strategy is that the whole team will have to start thinking more like a startup. Minimum Viable Products (MVP’s) will be a necessity, and what better way to develop them by devoting all your focus. Streamlined, efficient and focused development and design practices will be essential to not only develop excellent products, but to ensure the creative and adaptable processes stay fresh. In short, my team will start to develop an affinity with the product side of the business even though the majority of their time will still be client/service focused.
In my view, a 6/1 cycle will produce a compelling opportunity to enhance a team’s understanding and ability to build and launch. Of course, there’s also the nice by-product that we will also see new products launched with frequency and regularity. With some inevitably failing and other succeeding - but that’s beside the point.
I’d love to know what you, the kind reader that has managed to reach the end of this article, think of such an approach? Can it be improved upon? Can you see any potential flaws?
Follow me on Twitter to keep up to date on the journey as it unfolds.