In my last post about innovation at Fog Creek, I introduced Creek Weeks. They’re a week away from your normal activities with a colleague, focused on figuring out if a product idea will work or not. They’re also a starting point in getting from that idea to a real, viable product.
In this post, I wanted to run through a couple of example Creek Week projects so that you can see how they progress from a Creek Week project to a final product that has a compelling value proposition. After all, if a Creek Week is to be more than navel gazing, it needs to identify problems worth solving and propose valuable solutions. At their core, Creek Weeks are trying to discover possible avenues to deliver value to individual users and teams of people.
Two projects that exemplify that are HyperWeb and FogHorn. They’re both real projects. HyperWeb was looking to remove the obstacles to quickly building full-stack web apps. And FogHorn was looking at a System Administration tool for small companies.
Getting to Two
From the outset, it’s important that you know what you’re wanting to achieve with your innovation efforts. This will help define the kinds of ideas you’re looking for. For us, we were looking for the next big thing. We didn’t have specific numbers in terms of revenue or customers, but it had to be something that could rival Stack Overflow and Trello in terms of impact on the tools that makes our code better and our systems efficient. This immediately ruled out a number of ideas, but we ended up running 8 Creek Week projects exploring ideas that we thought fit the bill. After evaluating the results of those Creek Weeks, we felt that 5 still had that kind of potential.
To whittle those 5 projects down further, we involved the rest of the company. Each project team produced a one-pager detailing the problem and proposed solution. And then at our monthly all-hands Townhall meeting, they gave a demo or presentation about their idea. The sessions were interactive, so we all merrily asked questions. At the end, we all voted on the projects we thought had the most potential. Think of it like Shark Tank, but sparing all the melodrama, and sadly, with fewer Dancing Dogs than America’s Got Talent.
However, this isn’t a democratic process. In the same way that design by committee doesn’t work, in our experience, neither does picking products. Not everyone has all the required context they need to make a choice in the best interest of the company. So whilst the votes were a factor in the ultimate decision of which projects we should double-down on, it was just one important factor amongst many. It is, however, a great way of seeing which ideas can stand up to some unbiased scrutiny.
“In the same way that design by committee doesn’t work, in our experience, neither does picking products”
From that, we got down to 3. Each of those project teams got together in New York for another week of heads-down work. We decided to not progress with another one of those projects by the end of the week, so now we had two.
At each stage the criteria to continue on was the same as with the Creek Week itself – do they deliver on what we are looking for? what are the major issues with the idea and do we think they’re solvable? But, from here on out we were looking to actually start solving those problems.
Doubling-down and Solving Problems
At this stage, each project added an extra team member, and then we left them to work all summer long on their projects.
FogHorn was trying to make system administration easier for small companies. Over the course of the summer, they went through three different iterations. The first one focused on the idea of creating a network graph that showed how all your systems connect and the traffic between. Then when things fail, it’ll be obvious where the fault is. As usual, the problem with this wasn’t a technical one. But simply, as they researched the market they realized that whilst this was a problem for smaller companies, there were a lot of large, existing players making a lot of money from Enterprises. We probably couldn’t move fast enough to sell this to smaller companies without our larger competitors just coming in and eating our lunch.
So the idea progressed from a different angle. We tried implementing a Slack bot, where all debugging was done in Slack and you could leverage that conversational interface and say, ‘Hey, show me a graph of the processor on this machine,’ and it would pop one into Slack. The idea was to facilitate collaborative debugging. But, this time after playing around with it, we could never get the solution to feel right. It was always clunky, and you’d end up with just one person driving and everybody else sitting there, watching, occasionally offering a suggestion. It didn’t really solve the problem, it just moved it to a different tool.
“You can think of it like an exit ramp. These are a blameless, systematic way to reconsider the path you’re on”
So they then tried to give superpowers to a Command Line tool, in an attempt to bring the debugging information to the place where you solve the actual problem. Sadly, that too ended up not being quite the right solution either. And ultimately, we weren’t able to figure out how to make System Administration significantly easier for smaller companies, but we think the problem remains. So at the end of Summer, the team decided to wrap-up the project.
The progressions and final demise of the project were guided by the review structure we have around our innovation projects. To keep them on track, we have fortnightly check-ins between each team and the founders. This helps to provide input from those who are away from the day-to-day issues of the project. This was an influence in how the idea progressed between the different solutions. Then finally, the decision to halt the project came from the team itself, as part of our quarterly reviews re-evaluating the projects against their goals. You can think of it like an exit ramp. These are a blameless, systematic way to reconsider the path you’re on against the definition of success that you started with.
Progressing to Launch
HyperWeb, however, continued to pass these checks. The potential for impact was there, with a total addressable market of more than 40M people, and opportunity for consumer and business use. Our internal and user-testing showed the approach solved a real problem. That of the high barrier to getting started developing new products in terms of knowledge and time spent on things other than coding (something I’ve come up against myself a number of times!) And so after the Summer, we added further resource to the project with support for System Administration, Project Management, and Marketing. The team continued to progress and refine the product through feedback from one-on-one user-testing and a closed beta program before the eventual beta launch of the product that would become Glitch.
The Creek Week model proved to be a lightweight way of dedicating time to identify and research the potential of ideas, whilst our regular check-ins and quarterly evaluations kept things on track.