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.
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.
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:
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 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.
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.
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 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:
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.