It’s funny how you can build products every day of the week for clients, but when it comes to applying those same skills to your own side projects, you find yourself falling into every possible trap. That’s unquestionably what happened when we tried our hand at side-projects last year.
We set ourselves a specific goal
We’re not naive—we weren’t looking to start a super amazing trendy startup that’d allow us to quit our day jobs and spend the rest of the year on the beach. We had more modest goals: to find ways to improve our content marketing by putting out small side projects which won us maximum publicity relative to the time investment we put in.
Blogging has worked out really well for us in the last 2 years, but this was a slightly different approach that promised a different type of exposure. Teams like Crew (this is a great blogpost, by the way), Teleport and Buffer have shown that it can be done really well and the recipe sounds pretty simple:
- Pick a nice, focused project that’s aligned with your core audience.
- Carve out the time for a little sprint to build it.
- Ship and reap the benefits!
We even decided that on our team meetup in Croatia in August, we’d devote 3 days to splitting into 2 teams and creating a side project apiece. It’d be a mini hack-sprint that’d be fun for everyone involved and also deliver more value than spending 2 days blogging. Hey, I can’t think of a better way for a remote team to do a meetup than to sit in a room blogging away, with occasional breaks for an intense game of Exploding Kittens.
It clearly didn’t work out as planned
We know we can do this stuff. We’ve built a frontend prototyping framework and use it all the time to crank out websites for clients (often in just a few days or a week or two). We run design thinking sprints where we come up with a whole business plan, product strategy and new product concept and prototype in a week.
We do that again and again and again and we’re good at it. I don’t mind admitting that: if we weren’t, we just wouldn’t be in business.
But when we worked on our own side projects, without the limitations of client budget and deadlines, it became way too easy to fail to ship, or to get so bogged down in things that we ended up losing all the passion and momentum that we had for the product in the first place.
Hits and misses: here are the side projects we worked on in 2015
We scratched an itch, ran a survey, charted all the responses and built a little marketing campaign to promote the site.
- Input was about 10 days from 2 people to launch.
- It got us some good exposure and about 30,000 unique visitors landing on the project, and we added 700 subscribers to a newsletter in a couple of days. We got in touch with some cool UX designers off the back of the project but there were no other big business wins that came from it.
- Conclusion: decent for exposure and our brand, but we hoped for more and should probably have tried to do more with converting these visitors to Twitter followers or subscribers to our main newsletter.
Croatia Project #1: A manifesto for social good
- Input: 3 days of work during our hackathon, plus a load of extra time spent re-writing the content (you can’t just make huge changes to a manifesto once a bunch of people have signed it). Then, user testing sessions and cleanup and extra changes… time dragged on.
- Results: Well, none, because we didn’t end up shipping yet. We do intend to do this, but we’ve not pulled the trigger because we got a bunch of (useful) user feedback that suggests that we need to make some structural changes before shipping. We really should do that and force ourselves to ship..
Croatia Project #2: An environmental awareness project aligned with our environmental mission
- Input: 3 days during the hackathon, plus at least a week or so of refinements, user tests and tweaks. Crucially, we decided that we wanted to polish and refine the UI to give a better indication of our design capabilities—that took us a lot more time.
- Results; Again, we’ve not shipped it yet! This was in development for a little while and we then realised that it would be the wrong time to ship it because of certain client commitments and short-term conflicts of interest. So that one is on pause for a while.
Croatia Project #3: A mini-app to get people to buy less stuff
- Input: This one was ridiculous. We actually stumbled across the idea while we were working on the social manifesto and built this second little project at the same time (why not, hey?!). So input so far has been just a couple of hours to get a little MEAN stack app running.
- Results: Familiar story: we didn’t ship, so there’s been no measurable output yet, We still think it’s a great little idea and most of it is built, but we told ourselves “sure, we can come back to this in a few weeks” and never actually shipped it.
What will we do next time around?
A lot of our failings, while totally explainable, come from not sticking with things we do every day when we’re working with clients. But these are valuable lessons to re-learn:
- Build smaller, motivated teams and don’t let other people stick their heads in. Control the influence that other shipmates who are not working on the project can have. Make sure that if feedback is opened up to the wider team, it’s given very careful guidance and context. If you’re talking about an MVP, a bigger team won’t necessarily help you ship faster: 2 or 3 people, as we do on client projects, is the magic number.
- Get better at prioritising feedback. It might be solid feedback but unless it’s an absolute show stopper, we should be more prepared to make mistakes and ship, rather than allowing feedback to derail us. “Helpful feedback” can totally kill momentum.
- Maybe, just maybe, do a little less user testing before launching an MVP. We’re massive proponents of user testing, for good reason. I think it’d be madness to not do it on a product you’re building. But if you’re struggling to ship, maybe it’s better to put yourself under pressure like that and do deeper user testing after you’ve forced yourself to hit that shipping deadline? After all, “if you are not embarrassed by the first version of your product, you’ve launched too late.”
- Set firmer shipping deadlines. As much as it can be frustrating to work on a client sprint with a tough deadline and only a limited number of days available, there’s something about the way it focuses the mind. When we don’t have a deadline, things just… expand. It’s easy to be tempted to push things back a little in the name of getting a bigger win when launching. We can’t allow ourselves to budge on shipping deadlines—we should set hard ones and make something public gets shipped. Better to ship, then pivot, than it is to keep endlessly pivoting internally.
- Set lower visual goals. Don’t beat ourselves up about having strong visuals on MVP side projects, even if it would be nice if they looked so slick that clients would be stunned by their gorgeous UI and UX and start banging on our door to work with us. Visual polish feels incompatible with shipping fast and efficient side projects. When we find ourself talking about a side-project as a way to demonstrate that we can produce slick UI, we need to be very concerned. We should force ourselves to treat UI as secondary and should be part of a dedicated “polish” sprint after shipping, if we feel that’s important. We’re not producing a brochure for our UI design skills: side-products are ways to demonstrate our skills at building effective products.
- Avoid ‘big publicity reveal’ launch strategies. Having a launch strategy is good, but we know from experience that it is a rubbish strategy for clients. Still, that temptation is incredibly hard to fight. We shouldn’t neglect launch promotion strategies, but we should probably favour projects which can be slow burners, rather than event-based ones which depend heavily on creating one-time impact and heavy publicity around launch.
Overall, the whole experience from 2015 might be bad news for our side-project aspirations, but there’s some positive news for our main business. It shows exactly why clients need us sometimes, and why there’s so much value we can bring to product builds, even in tight sprints.
Let’s make mistakes more often and fail publicly, rather than endlessly pivot internally. We know all of this already, but it’s funny how building your own mini projects can really force you to re-learn the lessons you try to teach to other people all day long.
And hey, building and shipping our next side-project in a 2-day weekend hackathon is a good place to start!