At Speak we’ve been building team communication products for years, but when we began down this path I don’t think that any of us knew what was ahead. We all came from different backgrounds in gaming, b2c and ecommerce but we’d never tackled anything built for teams.

We’ve come to discover that creating a successful team product has it’s own set of unique challenges…

Multi platform

Unlike one player consumer apps like games and photography tools, multi platform support is critical to the success of a team product. Whilst it’s easy to forget when living in the tech bubble, not everyone uses your OS of choice and most teams will have a mixture of operating systems in use. If your tool needs to be used by everyone then multi-platform is a must as soon as possible.

If you’re building for web then this means compatibility with all the major browsers, not just Chrome… and desktop apps need to embrace Windows with gusto!

Realtime is Hard

If you come from a background of building web experiences that rely on a page reload or short session times, moving to building real-time systems with millisecond race conditions and a client that users keep open for days or even weeks introduces a whole new set of fun challenges.

At Speak we aim to connect audio in under a second. To achieve this, 50+ messages race through websockets and through our evented system which is built to withstand misordering, mistiming and lost messages altogether. Each layer of the system has to be built with fallbacks and proper error handling to ensure that when things go awry the user experience doesn’t end up suffering.

Activation is harder

Activation is that ‘magic moment’ when you consider that a user has engaged with your product in a meaningful way. This may be sending an email, creating a post, uploading a file or in our case - having a quick audio call.

This is exponentially more difficult when you require multiple people to use your product synchronously to achieve it, so anything that can be done to give your team product a one-player experience will pay dividends as users will be more likely to keep the app open and actually still be online when their coworkers signup too…

Quality is Paramount

Early adopters playing around in their spare time are the most forgiving of users, they’re often amazingly keen to find and report bugs, put up with inconsistencies, fiddle with settings and love to be involved in helping with the product development process.

Every workplace has it’s early adopters for sure, but an entire team of them is an unlikely find! In order for your platform to be adopted in the workplace, beta quality just won’t do. A high level of polish and reliability is a must for the vast majority of teams to adopt and stick with your app.

Preferences are great

With our last product we were prone to thinking that if you design something well then options aren’t needed. In hindsight, this was a little naive, and when Slack came around this cemented that fact as the app was lauded for its customizability - not complexity.

You can almost think of a team as one user with multiple personalities, one minute they want a preference for this, and then a setting for the opposite, plus an admin control for everything. If you don’t satisfy all of the personalities at once then slowly the team will stop using the product. Clear and well organised preferences and options are the right solution!

Business != Boring

The trend of employees bringing consumer apps into business isn’t going away and the line between personal life and work continues to blur for creative professionals. Everyone would prefer to have a little fun whilst they work and one way to inject this into your day is to use tools with personality, animation and excitement!

The bar for a great business tool is continuously being raised and we’re excited to be tackling these challenges! Building something for teams yourself? I’d love to hear any thoughts you have on this subject in the comments…

Last week we launched Speak on ProductHunt, there were a few days packed full of energy - many comments of positivity and praise on the design, hundreds of teams signed up, lots of issues were reported (and quickly fixed), our servers were even briefly overloaded with traffic!

Almost two weeks later and we’re now experiencing the quiet after the storm. Every day has had a different vibe (at least, in my head) and my mood is vastly affected on an hourly basis by the feedback we receive and metrics we track… it’s hard to keep an even keel. As is often the case, Paul Graham puts it best:

“In a startup, things seem great one moment and hopeless the next. And by next, I mean a couple hours later.”

Personally I think this is one of the most difficult times in a startups formative stages, and it’s easy to lose heart. You have a few users, not enough to get excited, some retention, but not enough to be ecstatic, and requests pulling you in every direction from those that did signup and want you to solve their very specific problems.

Dan Shipper found the perfect analogy in that of a stock trader - if you constantly check how your stocks are performing then there is just as much chance of them being down as up, even if the longterm pattern is one of positivity and growth.

An acute awareness of this is the biggest step to dealing with it. Talk to customers, track and celebrate the small wins and keep plugging away at building something great!

Do you remember being told as a child that your eyes were bigger than your belly? Perhaps you were piling far too much food on your plate at dinner…

As a kid I always wanted to eat too much, grow up faster, be taller. I’d look up to those in years above at school and think how much older they seemed and that I couldn’t wait to be their age with all the benefits that it would bring… I think most of us thought something along these lines, right?!

Of course now we realise how important those years are - there is no way we could simply skip to final exams without all of the learning and growth that these earlier days provide. I’ve found that in building startups, the very same temptations exist. The desire to be bigger than your boots, to grow too fast and to try and emulate those that are more grown up.

At Sqwiggle we made this classic mistake too, jumping into hiring as soon as we’d raised our seed round because that’s what you do. But really we were still in this early period of pre product market fit - we should have still been testing, experimenting and iterating towards great traction and zero churn. In hindsight an early burst of signups coupled with a successful funding round had confused us into thinking that we already had product market fit and our ambitions meant we were only too eager to grow up to the “next stage”.

Writing is always the first thing that gives, whether we’re having a bumper month or a ton of trouble with our architecture and product - it seems as though there is always an excuse not to write about it…

This was definitely the case last year, where I published a grand total of zero posts. I write as much for ‘future me’ as anyone else and I don’t want to look back on 2014 in a decades time and ask myself - “wait, what the hell happened that year?!”. In fact, a lot went on…

Sqwiggle

This deserves (and will get) a post or two for itself, needless to say it was a year far from smooth sailing and chock full of events.

I feel as though we experienced the entire startup lifecycle several times over from the post-raising hiring spree, a traction plateau and a trip through the infamous ‘valley of death’… much more to come on this.

Personal

On a personal level, 2014 was my most travelled year so far, and almost none of it planned more than a month in advance. It’s fantastic having our company set up in a way that makes this possible…

It is often perceived that the challenges in building a distributed team lie in communication over distance, however with todays incredible technology and tools the problem is really one of communication across timezones. At Sqwiggle we are currently spread across 4 timezones and it is this rather than distance that creates problems like confusion over meeting times, not enough crossover time for discussions, odd working hours and more. These are just a few of the tricks and thoughts that I’ve had on the topic:

##Keep communications in one timezone
In emails and spoken conversations try and pick one timezone and stick to it in all of your communications. This small hack makes a huge difference in stopping confusion, and you’ll always know which timezone you arranged your meeting in. Of course which timezone you pick is upto you, it could be where you are based, where most of your clients are or where your company is, just be consistent.

##Use a shared calendar
A shared calendar such as Google Calendar provides a whole bunch of benefits, for a start each participant sees the event in their own timezone and in relation to their own day - a huge confusion buster. A shared calendar also has the advantage of increasing transparency within the company

##Don’t spread your team too thin
When we began advertising our open positions we received a lot of applications from all over the world thanks to our “you must remote work” policy! This was great but we soon realised that at our size and stage of the company we would have to filter out many applications purely based on location so that we could reduce our timezone-spread.

##Split your day in two
Right now we are beginning to deal with the maker / manager transition at Sqwiggle. In my experience so far, being based in Europe with over half our team in the US affords a distinctive split in the day where the morning is quiet and great for focus on coding tasks whilst the afternoon becomes planning, discussion and other non-maker duties.

##Something’s gotta give
Even taking these thoughts into account I’ve found that when working closely with a geographically diverse team the best thing you can do is increase the amount of crossover that you have for syncronous communication. This generally means one or both parties shifting working hours to accommodate more time spent working together. Sqwiggle has proven very useful in this respect and I often stay logged in until late into the evening making me available for anyone on the team to ask quick questions that come up during their day.

Do you have any tips for working more effectively between timezones? Let me know in the comments, I’d love to give them a try