Our 6 week product cycles

Building and growing products until they become sustainable businesses on their own is a cornerstone of our culture. We’ve been doing that since the early days with Qold, Unplugg and other products that born from side projects like Soundy, Hawkpost or SlackerNews.

We learned a lot about all of these experiences and with the work done on our clients’ projects. Right now it feels like we’re in a point when we clearly need to step up our game if we want to fulfil the vision of making Whitesmith a hub of great products that are helpful and that people will be thrilled to use. In order to achieve this, we implemented a framework that we believe will lead us to solid products with a good market fit and with enough size to grow on their own. So how does it work?

First, we need to disclaim that our process is heavily based on what the great folks at Basecamp do. We took their feature centric approach and made the necessary changes so it can fit the needs of product development. The big picture here is to organise all the work necessary to build a product in small teams and work cycles of six weeks. Here are some details on the main parts that compose the process.

Pitch

Every product cycle starts with the pitch. Everyone can propose products if they believe it’s a good fit but it has to be done accordingly to some rules. Every pitch has its own trello card and a written document that allows everyone to discuss and improve the original proposition.

The pitch serves three main purposes:

1. explain the problem that the product will solve
2. state the validation gathered for that solution
3. point the direction that should be followed to turn the product into a business. It also needs to specify the team that will be involved in the development process and the roadmap for the first six weeks.

Teams

Each team should have three people maximum. Along the way, the major challenges that the team will face are design, engineering and the hustle of getting the product into (preferential paid) users hands. Knowing this, we still don’t force teams to be composed by a designer, an engineer and a hustler but everyone should be committed to those needs as the product grows.

Keeping in mind that specialisation is an important thing to the work that we do, with this approach we want everyone to worry about things that are normally outside their comfort zone. Product development is a problem that concerns the entire team and everyone should share that responsibility and know what it takes to do it well.

Validation

This one is very important. For every product, there must be concrete data that validates the proposed solution. This forces people to find ways of knowing if that problem is worthy of six weeks of work. Teams are strongly encouraged to seek validation outside the traditional comfort groups like friends, family and colleagues. We need real world validation, see if there’s someone out there with the problem that we’ll solve and, more important if they are willing to pay for the solution that we’ll build.

Teams can achieve this using the strategies that suit them best: discussions on online communities, ad-hoc calls, rough prototypes, landing pages or knocking on doors. It doesn’t really matter as long as we end up being certain that we are going to build something that people will actually need, use and pay. Blind guesses are not allowed.

6 weeks

We rely on the idea patent on Basecamp’s post: six weeks is a reasonable amount of time to build something well. After having a decent picture of what is going to be done and how teams have six weeks to pull it off. They should start with the roadmap presented on the pitch but if anything changes, the team should be able to adapt and change the product’s course as needed. The one thing that doesn’t change is the deadline, after six weeks the work stops.

Teams must be autonomous during this period but there are some mentoring always going on. We believe that an outside view can be very helpful, especially when a team is so focused on a particular problem like this.

Retrospective

When the six week period is done we look back in retrospective. The metrics that the team defined in the early stage of the development will be useful now to evaluate the work done. From there we decide if the project should be dropped or if it should go for a new spin and, if that’s the case, a new pitch must be prepared with the same rules that the first one had. Teams should take the current state of the product and pitch it again, performing the changes that it needs.

What’s next?

We are pretty much using this approach to accelerate our learning process. By immersing ourselves on this loop, we hope to learn much faster as a company since we’ll need to get our hands dirty much more times. With some necessary fine tuning along the way, this will hopefully lead us to not only great products but will also prepare our team to deal with the challenges that developing products bring.

We are currently using this framework on a handful of products. Stay tuned for future news, we’ll definitely be sharing more on this in a near future. This is how we do it for ourselves, when working with a client we try to adapt our experience to their needs. Get in touch.