A Designer, Developer and Writer Walk into a Bar.
Or what makes Teamweek Product Team special.
I joined Teamweek’s marketing team 3 years ago. After realising that it wasn’t really a job for me, I was offered the position in User Onboarding which was at that time still a part of the overall Growth Team. Now, after transitioning to the Product Team, I can finally say I’ve found my professional home.
Here’s why.
A Remote Setting
Teamweek has always been a remote company. Set up by the founders of Toggl as an online team planner for their own needs, Teamweek also became a testing ground. Our team took on new programming languages, experimented in making apps and become the first remote team in the company.
5 years later, we’re a separate, profitable company of 14 people, working from different corners of the world. In a remote setting, especially in a small boot-strapped team, everyone needs to be hands-on, able to wear many hats, have opinions, an ability to take initiative as well as to follow through.
We also need to be extra good at communication and patient enough to explain things a number of times: since most of our dialogue is written, some additional explanations are almost always due.
Three People Running Product
So this is an unusual setup: remote boot-strapped setting. Additionally, we have three people who have a say in the future of the product.
Serge is our former tech lead and understands the technical side better than anybody else. He’s also our CEO, which means he knows exactly where he wants to take that product and can therefore keep an eye on the goals.
Jozef is our design lead and product designer. He’s the one who decides on how Teamweek should look and feel like, although he does listen to others and takes on any articulated suggestions.
And then there’s me. I make sure we communicate each feature based on the value it provides, talk to support team to understand what users are currently struggling with and take care of the product’s tone of voice.
I feel the diversity of our experience gives us a uniquely wide perspective as well and increases empathy. Thanks to knowledge in engineering, we understand exactly what we’re asking from our developers, what our “small requests” might mean and I don’t believe any one of us has ever said those famous 5 words: how hard could it be? Thanks to competence in design, we have systemised thinking, understanding in what could feel good in terms of user experience and an inclination towards prototyping and testing. Thanks to a background in marketing and talking to users, we can now make sure our users’ needs are put first whenever we make product decisions and that users and other departments get informed.
User Onboarding as a Part of the Product Team
Having user onboarding behind the table where product decisions happen not only makes sure every product feature is communicated based on the problems it solves and the value it provides, it also means the same value is being set as a basis in all future features.
We’ve recently woken up to the fact that our retention sucks, meaning we don’t seem to offer enough value for them to stick, and made this a company-wide strategical goal. One of the tactics supporting this strategy is a move towards a framework that would help us make decisions about the product’s future: the Jobs to be Done.
In fact, this could play an important role in all of our endeavours, from product to marketing to support. But as it’s still the early days (we’re about 8 user interviews in), it’s too soon to tell.
