How we build our SaaS product in 1-week sprints — Raw Product Ep. 2

How we split our week at GreenShoot Labs and how that connects to our long-term goals and initiatives alongside some personal thoughts on the pros and cons of short 1-week sprints.

In the last instalment of Raw Product we talked about our experience launching on the Slack store and some of the learnings from that. In this episode I share how we organize our week to try and combine long-term goals with more short-terms reactions in a hybrid Scrum/Kanban method.

The usual disclaimers apply. This is just how we do it — not THE way to do it and it works for our current team size (a small, focussed, distributed team of 6). I find reading how other teams approach these issues very useful so hopefully this is a way of paying forward for the knowledge and experience sharing that I gained from.

The big picture — Goals and Initiatives

Before diving into a single week it’s worth looking at the slightly bigger picture. Beyond our strategic vision we set ourselves monthly and quarterly goals with measurable outcomes. These then translate into specific initiatives (larger, coherent pieces of work) and an understanding of how much time we want to dedicate to any initiative.

For example, one of our current goals is to make the SaaS app buyable!

Yes, I know that is a pretty basic thing for a SaaS tool. We launched early and didn’t worry too much about how people would pay us. We threw together some somewhat reasonable prices, used Laravel Spark and Stripe so we can accept payments but hardly touched any of the out-of-the-box settings. Now that we know people are actually interested in the tool and that they are even willing to go through the very basic payment process we are ready to invest the time to make that payment process enjoyable, more relevant and something that inspires confidence in our service. This means proper modelling of alternative price plans and implementation of the tech to support those plans, design that is in line with our current brand, and generally a process that reassures (it also means properly figuring out the joys of charging for VAT — sales tax — across the EU). These points also roughly translate into the initiatives that will support the overall goal of making the application buyable.

As a sidenote we have recently moved our planning into Aha!. We find it a very comprehensive (even if somewhat complicated) tool and right now it fits very well with our approach. So much so that we have directly adopted from it a lot of its product terminology (things like goals, initiatives, ideas, features, etc).

Ok — with the big picture mostly in place lets look at how a single week shapes up.

Monday

Release, analyse, re-plan (if needed)

We try and release as often as possible but Monday is the “official” release day. Anything not released during the previous week that has passed all the code review, testing and QA phases will get released on Monday. The person responsible for the release has this as the main task for the day while others are available to jump in if issues arise — otherwise people get started with their sprint tasks. We hope one day to automate many more of these aspects so that release is not something someone has to be responsible for but we are not there yet.

Monday is also the day we analyse feedback from the previous week in a focussed way, and turn it into actions. We use tools like Google Analytics, Hotjar, New Relic and our own metrics on app engagement.

With data at hand, we then review our initiatives and decide whether any course correction is required. We ask ourselves questions such as:

1. Are we seeing the expected outcomes from features that were released previously?
2. Is there any new data / understanding that points to different features to develop or a change in goals or initiatives?
3. Are there any infrastructure, security issues that require explicit attention?
4. From a technical and UX perspective, do any of the bigger pieces of work require re-thinking now that they are further along the way?

Key to this being an effective process is that we are all very open and willing to accept that what we thought last week to be the absolutely best course of action may simply no longer be that.

Strong opinions loosely held is definitely emerging as a defining aspect of GreenShoot Labs culture.

Tuesday and Wednesday

Develop, design, mockup, discuss, plan

Tuesday and Wednesday are getting stuff done days. It is a combination of deep, uninterrupted creating and collaboration where appropriate. That means coders code, designers design, UXers mockup, planners plan, and we all share ideas and support each other to get stuff done.

By Wednesday afternoon we would have ideally released a couple of new features, have mockups for new features, and have a plan for the week after next in terms of specific tasks to do.

Thursday

Feedback

By Thursday we aim to have enough done so that others can feedback on it. We can discuss technical challenges of features, and provide feedback on mockups. While not easy, our aim is to do this for the work for the week after next so that the thinking can have its time to brew in our individual brains.

Friday

Wrap up, review, retrospective and plan next week

By Friday we are wrapping up our sprint. We review work done, what we are going to release, what remains on the board, and what new items move into the board based on availability. We run a retrospective of the week, identify what went well, what didn’t and what we will aim to improve.

The good, the bad and the ugly

The weekly map I describe is a somewhat idealised version. We try to stick to it as closely as possible but we don’t beat ourselves up if it doesn’t always go like that. We are a small team and we need to deal with whatever issues come up. In general, here are some thoughts I have about the process:

1. 1-week sprints saved us multiple times. We are a small team, we communicate frequently. Still we’ve found that things can go off course. Had we not had 1-week sprints those deviations would have been actually costly. 1-week sprints force all the units of work and planning into far more maneageable pieces.
2. I am not sure how it would scale to bigger teams. Before GreenShoot Labs I almost exclusively worked in 2 or 3 week sprints. Also a lot of the work was from within an agency for customers. I dread to think of having to run at this pace with a large team with multiple stakeholders. Having said that I would very reluctantly go back to bigger sprints.
3. The pace is exhausting and fantastic. The running joke is that by the time we hit the end of the week someone will invariable pop-up and say “I can’t believe it is Friday already”. I love that.
4. Balance with the rest of life is crucial. To be able to keep up the pace we need to … pace ourselves. A few months back I went through a few weeks of much more intense work in order to get stuff built but quickly scaled back. It was not sustainable.

My (obvious but not so easy to implement) learning:

Building a SaaS company (especially a bootstrapped one) is a marathon. Perseverance and continuity is far more important than burning out in a ball of fire.

That’s our week. Would love to hear your thoughts, suggestions and if you have a similar post please add it to the comments.

GreenShoot Labs builds products that use automation, data and conversational interfaces to make teams happier and more productive.

Our first product is live on the Slack App Directory — TeamChecklist makes working through common, repeatable processes and tasks better for your team with automated notifications and reporting.

How we build our SaaS product in 1-week sprints — Raw Product Ep. 2 was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.