What’s interesting about our methodology is that we don’t have any deadlines whatsoever, and yet we manage to ship improvements and new features at a constant steady speed, and our customers benefit from the improvements of our platform all the time.
In addition, we find that it makes us significantly more productive than if we had arbitrary deadlines put in place. We’re a small team (3 web developers and 1 mobile developer), so everything we do is geared towards making a big impact with our limited resources.
So, we have to avoid all the dumb stuff that many companies do, and ensure that we’re being smart and effective!
- Avoid burnout
- Time to think
- Doing things with the long term view in mind
What We Don’t Do.
- Track hours.
- Have Timelines / deadlines for features
- Do Daily Stand-ups
- Have User Stories or Story Points or Acceptance Criteria
- Work in “Sprints”.
- Pull all nighters or work in a rush.
- Have “expectations”. According to a survey by StackOverflow (a developer Q&A community), unrealistic expectations are the #1 challenge that developers face in their day to day work.
On Quality (And Accountability)
For any company, but especially for a startup, product (or service) quality is paramount. There are no hacks or workarounds if you have a shitty product.
So, it makes sense to have a craftsmanship approach towards building something that works well.
The great thing amount not having deadline driven development, is that it actually makes developers more accountable than having deadlines.
At first, this may seem to be a strange thing to say, as if you don’t put deadlines in place for work, then what’s to stop someone from slacking off and taking lots of time to do something?
Well, it depends on the way you view accountability. What we have done is shift accountability from timelines to quality.
Without timelines, a developer is fully accountable to the quality of the part of the product that he is shipping. There is nothing else to measure.
Work / Life Balance.
If one accepts that fact that real value is only really developed in the long term, then it makes sense to work in a way that’s sustainable for the long term. So that’s marathon pace, not a sprint.
The other thing to realize is that we’re not making widgets in a factory. The difference in output and results between a great software developer who’s working well, and a mediocre one who’s working okay, is not a 20% improvement.
It’s a 10x or 20x improvement.
With that in mind, it doesn’t really matter if someone is working 35 hours a week or 40 hours a week, or even 28 hours a week. What matters is output.
Where do product ideas come from?
- Customer feedback
- Customer Interviews
- Things in our backlog that are already planned
- Team ideas (we are our own customers)
Product Feature Evaluation.
The key idea behind shipping any new feature or improvement at Bloo is as follows:
- Will this feature extend the number of use cases of Bloo? This is important because the more varied use cases that are possible with our platform, the wider our potential target audience, and also the more value existing customers can receive from our platform.
- Is the feature usable? Is it something that we see ourselves using every day or week?
- Is it simple to use? We don’t ship complex things for our customers, we prefer to do the hard thinking behind the scenes to give a delightful and simple interface that just works.
- Are we solving a customer pain point?
Quarterly Planning Meeting.
Once every three months, we get together and discuss the current state of the platform. Except for some lunches together, this is our only real team meeting.
We brainstorm ideas for the product, and everyone can post up ideas on the wall with a sticky note. Many of these ideas will have already lived in our backlog for some time, while others are completely new.
We use the NAPS+100 framework for this:
- No Judgement
- All Ideas are Welcome
- Piggy Back
- Silly Crazy
- +100 = Quantity.
However, we only want ideas that people think will fit this question:
What would be stupid for us NOT to do next?
Each person spends around 10-15 seconds explaining each of their ideas so everyone is aligned on what a particular sticky note actually means.
Once that’s done, everyone leaves except the CEO and Engineering Lead, who then estimate the number of weeks required for each sticky note, with a safety margin attached as well. We write this with a board marker on each sticky note. If we really don’t know how long it will take, we simply place a question mark.
Note, these estimates are not so we can then plan out exactly how much time someone will need to work on a particular feature and then hold them to it. We actually just use it for budgeting and prioritizing.
In addition, we always have Refactoring/Bug Fixing as a sticky note, as we like to account that required work within our product planning. It often gets ignored or placed in a secondary level of importance, but let’s remember that Quality (yes, with a capital “Q”) is a feature in itself!
Then, we take 36 small circular stickers, one for each developer week (12 weeks in a quarter and 3 developers on web) and we use these circular stickers to “fund’ the various product ideas, including refactoring and debugging time.
At this stage, we are considering the various dependencies between the proposed features, customer feedback we’ve received lately, and also our preference and needs as being daily users of our own software.
Once we’re done, we will have list of features that we will want to work on, and a list of features than we are going to not do, even though someone thought it would be stupid NOT to do it next. We add those to our ideas list for future reference.
What’s funny, is that often those ideas do not then reappear in the next quarter’s product planning meeting!
We then spin up a new list in our Product Board with that particular quarter (i.e. “Q1”) and add/move all the fully funded ideas into that list.
We also immediately update our public roadmap on our website, so our customers know what’s coming next at a high level.
The features that require in-depth design and specifications will then go through that process, and the ones that can start right away will be moved to “In Progress”.
We made a choice early on that we were going to use existing design frameworks as much as possible, as this simplifies the maintenance of the front-end and gives a unified approach for all new product features.
Another benefit is that our customers will already be familiar with the design frameworks because they will have used them on over websites. We use Google Material Design for both our web platform and Android App, and Apple’s Human Interface Guidelines for our iOS App.
This means that we can often get away with low-fidelity designs with tools such as Balsamiq and prototypes as the developers can “drop in” the design into the framework and it will look at least 80% there.
We used to use Sketch, we’ve now migrated to Figma as it’s easier to collaborate, and the customer success team can export screenshots of the latest version of the design without bugging the design team, which results in less communication required...and that’s a good thing!
We use Vuetify as our front-end framework on top of VueJS, and we emphasize long-term maintainability vs custom design components, so we try often to build an interface with available components that we know are stable and will work well in the long-term vs building our own.
Depending on the feature, we may build out the front-end first to fully understand the UX/UI required, and then build the backend and mockup data, or we may build the backend first if the feature is quite clear, as we wait for the design to be completed.
Our specs are quite simple, we normally make sure we cover the main UX, plus ensure that we’re written copy for things like notifications, Effects on Company/Project activity, and so on. We will use the Checklists feature in Bloo to make each point of the spec into a checklist than can be tested and then marked as complete.
Built For Quality, Not For Deadlines.
What’s interesting is what happens next. We assign those features to developers based on personal interest and familiarity with that particular part of the product, and then they start to work. We completely ignore that estimated number of weeks on the sticky note. In fact, that information is not even transferred across to our Product Board.
So, we aim to build to a specific quality, not a particular timeline or time block. We’re also wary of trying to build too much. We prefer to ship a smaller version of a feature first and provide value to customers, and then make a v2 or v3 later on with additional features, instead of spending months working on one thing.
In regards to getting a feature from idea/design to actual working software that a customer can use, we use several versions of Bloo for this.
- Localhost - This version lives on the developer’s computer and has the absolute latest version of Bloo. It often breaks and has half-finished work :)
- Dev - This is our internal playground for new features and ideas. Has dummy data, with lots of strange comments as the team tests things it and tries to break new features! 😆
- Beta - This is where we ship new features to test them with production data, and also gain feedback from existing customers who regularly use the Beta site to access new features before they are “officially” launched.
- Production - This is what most of our customers use, and so it’s important than only high-quality code ends up here.
We have regular, informal product demos for all features and we course-correct along the way.