This thing called Mooch
Strobe have just come out of — approximately — a 4-week sprint to produce a very rough social web app. Mooch (trymooch.com) matches its user’s intentions (e.g. play football today, drink a beer tomorrow) with one another, allowing them to converse and form a plan.
Below, I’ve briefly explained why we started this in the first place, what our goal was in this sprint, and also opened-up our retrospective notes from this afternoon.
Where did it come from? #
The overarching concept and reason for this kind of product comes from the early days at Strobe, where we decided that, at some point in our future, we wanted to ‘make product’. Over the months, we started to take the ideas more seriously, spending several evenings in The Mill pub in Ulverston, littering their tables with planning materials.
Then, in the spring/summer of 2013, we dropped our client capacity slightly, to make room for developing the concept further. We made a native iOS app, an API, and even our own app delivery platform. But, more importantly, we had lots of lightbulb moments. (For example: realising that plans can only be driven through conversation, rather than upfront form-filling.)
And then, in the biggest move since we started Strobe, we actually reserved some serious time in our schedules for this product. What was a vague idea in the back of our heads at the start of the year, is now booked into our schedule for a significant period of time.
The purpose of these last 4 weeks #
This was always going to be a “see what happens” kind of sprint. We didn’t want to do this in a predefined fashion; we wanted to focus on one thing: improving naturally as a product team. Our background is in freelancing for larger digital companies, and whilst we were dealing with the same technology and methodologies from these clients, it’s another ball game to practice these internally, with no one to play ‘doctor’ to but yourselves.
We feel like we did grow naturally. We’ve come a long way in the past 2 months: we’ve got our own little hideout in Manchester’s centre, and we no longer have to be around each other 24/7. Now, we disagree with each other a lot less, we rarely do head-desks, and we are hugely positive about our current position.
What it is; what it’s not #
- Mooch is a name that Chris suggested one day after coming off the Metrolink. Whether we keep it or not, that depends on brand direction in the upcoming sprints.
- We chose to make it using web technologies because it gives us what we want at this stage, but in a state were we could constantly mould it.
- It’s not a ‘big launch’. We’re going to attempt to scale-up its user impact on each sprint.
- Most importantly, this isn’t the product, but more the concept we have engrained in our heads from the past 12 months. We haven’t even fully discussed what we’ll be up to next year, because we’ve formed a common vision that we can pick ‘bits’ from and grow some products.
Our retrospective notes #
Today, we had a retrospective. We decided to give you a glimpse into our own conversations, by summarising what we want to change next time (this list was spawned from a fails/wins session.)
- We want to have more boilerplates for prototyping. One click Framer.js kind of thing.
- We want to put more product responsibility at prototyping stages, to steer away from any dictation from within a visual editor like Sketch.
- We need a new router. BT Home Hub’s don’t cut it when you’re working in a development environment with static IPs and custom DNS settings.
- We want to focus on unified setup. Make sure every maker knows one machine from another.
- We’re going to set an alarm for a ‘mini-meet’ at the end of each day. (We don’t actually stand-up or scrum because we’re too lazy.)
- On that note, we’re going to buy some bean bags, so we can get away from our desks during mini-meets.
- We want to use a ‘thought-box’ style workflow. Each maker has their own little Trello column, where they store pending thoughts, ready to be pruned at the end of each day.
- Always have the mindset creating ‘Inception’ cycles during sprints. Before each feature, check we’re doing it in the shortest method possible to achieve validation on it.
- Use a JavaScript style guide, because Chris and Joe write JS quite differently.
- We should use the app more ourselves, and talk to people who we match with to ask for feedback.
- BE MORE MICRO-SERVICE ARCHITECTURE.
- Standalone iOS web apps have some extremely curious bugs. We’ll probably opt for PhoneGap next time we want to write some web app JS.
Holiday time #
We’re off to drink wine and eat cheese on crackers. All the good stuff. In the meantime, we’ll be having a good think about our next sprint. (We’re actually doing that right now, but when it’s just after a Xmas party, things aren’t at full pelt, yet.)
Have a good Christmas everyone.