The early build phases of a technology startup are exciting. We have spent time speaking to prospects, uncovered a segment we are building for and validated our solution with some rough prototypes.
In several of my early startups, I skipped all that to get into the building part. Rest assured almost all of them ended in failure other than the ones I got lucky with.
Our rebuild process is a little different from other early-stage startups where you just have 2- 3 people wearing multiple hats. Our team size is over to 10 people and includes specialists that give us the ability to go deeper faster. (This is also a big risk in the rebuild project and we may easily overbuild)
As the product owner/founder a critical decision to make is whether we choose to work in cycles or just use Kanban to ship features when ready. I don’t think there is a single right answer to this question. Listed below is what we have selected:
We are working in single week cycles
- I chose a single week cycle versus the Kanban method as I believe it provides the whole team with structure and some synchronization given our size. If we were a smaller team I may have opted for Kanban.
- A week cycle helps to bring urgency as well as reduce feature creep that can easily set in if one were to let cycles run longer. One doesn’t have time to ensure that every border-radius and shadow depth are optimal. (I have burned through many work cycles being far too critical on the design which I have learned to let go)
- We are able to discover blindspots faster. Today in one of our early iOS builds I found a broken flow that the backend was able to rectify immediately. Left unchecked we let our assumptions build up and that almost always backfires.
- We are running without any cooldown days/weeks. This drawback makes this cycle unsustainable over the long run. I plan to switch out of this cycle once the beta has shipped by the end of the Q1. Otherwise, you will be running the team way too hot and it will end up in burnout or lower quality output.
- Friday afternoons are internal demo days and most importantly a sense of progress for the entire team to see that they are working towards a set goal that is becoming a reality week after week.
I have found far more success with the above cadence. While this may be working for our team your mileage may vary. Speak to your team members, figure out what is important to you and at what stage you are in the validation and build cycle.
There are no perfect work cycles. There are several resources below that could be of some assistance in helping you find a cadence that works for you.
This books talks about cycles as well as not benchmarking your success only with output. Building features for the sake of building, rather than validating demand almost always ends in failure.
The famous 6-week cycle broken down by Ryan Singer at Basecamp. This short read goes into detail on how they effectively use this cycle length at the company. It is a great read and one I would recommend everyone who is building products.