Internet vs Real Life
When we originally implemented Tasks, we designed them to be an organized way of communicating within a team. That is why they have both the conversation aspect (you can see a thread of comments) and the execution aspect (dates, assigned person, status). However, because of their simplicity, it’s easy to use them in different ways.
Many users tell me how they create personal workspaces with a project, to keep track of personal tasks. Sometimes it’s just a single-person project, sometimes it’s a couple planning their day-to-day tasks.
What makes Task Lists so useful is that they are both Tasks (actionable) and Lists (so you can basically track anything that’s a list).
I’ve been managing my personal tasks in Teambox, and I’d like to share some use cases with you today.
Choosing a new place to live in is an important process, but very complicated. Soon you find yourself with a dozen bookmarks of places you liked, scattered notes and pictures and dates to call each owner.
I managed this by creating a Task for each apartment I liked, and adding links or pictures to them. If one of them was good enough, I started calling and assigning dates for it. If any apartment wasn’t good, I would reject it. I finally managed to find a very nice apartment in Gracia, a place that Jordi Romero will envy.
You know that book you want to read someday? That movie you want to watch? That Polaroid you want to buy? I keep track of these in a personal project with tasks for each thing I want to do.
This helps me get closer to them, and not forget about things I want to do someday. Because, after all, I need to buy a book if I want to read it.. and that’s also a part of the task.
Some things in life are terribly complicated. Starting a company is one of them. Getting married is another one.
Tracking stuff in a task list can help you plan, but also keep a track of documents that you might need as attachments. You will find the conversation aspect useful for the traceability of that task, and the execution aspect to make sure you’re on time for your tasks.
If you’re like me, you don’t trust your phone company anymore. When you call to sign up for some service, you want to keep good note of the conversation and the reference ID for it, in case problems arise later.
What I do in this case is create a task for anything I need to cancel in the future, or keep track of. That way, when the moment comes, I have all the information required in a handy thread and with a date.
Are you using tasks in any original way? Share it in the comments section!
Follow me on Twitter! @micho
An important part to running a successful business is keeping your customers. They are hard to get, and you’re way better off keeping a customer than finding a new one.
Support plays an important role in this. At Teambox we drive product direction in three ways:
I personally love getting involved in support. In doing so, a few anonymous users became close friends that now help me understand what people need from our software.
I find that support tickets come from users in different phases of adoption. Let me explain with the hope of helping you understand your users and perhaps helping users understand how support operates.
New users come to your product with an idea of what it should do. This judgement is built from their experience with previous solutions and by their perception of what your app does. The more innovative your product is, the more new users will be puzzled.
Let’s say you are building a completely different image editing software for photography. Users coming from Photoshop will ask how to use your software to do things they did with Photoshop. They want to achieve the old result with the new tool, and the metaphor of “a new kind of Photoshop” is very powerful in their minds.
In this period what you want to do is user education. Provide guides, tips, example workflows. Add suggestions where the user is likely to have doubts about how something should be done.
You will often get requests saying: “We absolutely need XXX feature to use your product, it’s worthless otherwise”. You will be tempted to implement them, in an effort to please the newcomers. My advice is don’t do it. Follow your product direction, and make others buy into it. Innovating is hard.
But of course, follow your common sense. If everybody agrees that something is wrong, maybe it is wrong.
Some of your users will have a deep understanding of your tool, and they will strive to help improving it.
You will be very lucky to have them. They are fans and evangelizers that are willing to get in touch. Answer them promptly. Learn from them. They are very different from the new confused users we mentioned before. New users write you from confusion, heavy users write you from experience.
When responding to their questions, you are helping your product be more useful for heavy users. Remember they are not the majority of your userbase. Power features should be hidden from new users so they are not overwhelmed. It’s a good practice to keep them as settings or additional resources.
Yes, no matter how good you think you are you will still get these. And they will grow as you become more successful.
When dealing with an angry user we need to learn from what caused the situation. Maybe it stemmed from waiting for weeks in support. Maybe the user was transferred to different support people each time, and had to explain the whole situation for the fifth time.
If it’s related to the quality of support or service, you might want to set up metrics that allow you to act before it’s too late: Response time, activity of a user, etc.
Once a user reaches the point of wanting to leave your system, here’s a tip: Make it easy, be as helpful as possible. How many time has a phone company pissed you off by making it hard to move away? Maybe you went back with them after some time because you didn’t have better choices. Realize that you might not have the luxury of forcing your users to come back. So make leaving your service a good experience, and users might consider you again in the future.
Handling support by email and phone is possible, but when you scale to hundreds of thousands of users it just won’t cut it anymore.
You’ll want to turn individual requests into actionable data. Build communities for collective feedback and voting ideas, like Uservoice. Build support ticket systems closely tied to your users’ identities, so they don’t need to identify themselves every time they contact you.
Remember: Great support is one of the ways of keeping a vibrant and active userbase!
When I speak about Teambox, people are usually surprised to learn that it is an open source product. For many classic companies it might sound scary or crazy to distribute the source code of your main product. This is directly related to a general misconception about the market’s response to openness.
No, not really, its free as in freedom. When talking about free software, people understand it as in “working for free”. We are selling our product but we also chose to distribute the complete source code. We’re distributing our software under an open source license that is compatible with our business vision.
“Free software is a matter of liberty, not price. To understand the concept, you should think of free as in free speech, not as in free beer.”
—Richard Stallman
If you aspire to become an open source company, you’ll have to embrace openness and make it a key part of your business model.
At Teambox we chose to opt for a proven model with two lines of action:
It is similar to the World’s number one publishing platform that powers this blog, WordPress.com and their WordPress.org effort.
The reality is that people looking for open source are just… looking for open source. They are not your target consumer, they are your allies.
Yes, they will download your source code and manage it on their own, for free. It doesn’t hurt your business but the side effect is good for you. They will promote your product to some people who are on the market for a fully managed service and are ready to pay for it.
Embracing openness means that you will have to treat your open source users like potential consumers. Your product is open source, which means that you’re open mostly to contributions, but your user base will judge the offering and decide to buy if it meets their expectations as well.
Think of your open source consumers as your allies, and remember that they will work with you if have a common goal.
Even more, they are often among the best candidates to join your Team. This is exactly how I was recruited by Teambox.
This is probably the worst part about an open source product. Its really hard to lock-in your consumers, because they can just use your free version. Your only choice is to be so awesome that going with you is the best choice. Shouldn’t that be the goal of every company?
Google is one of today’s top companies, thanks to their continued efforts in building the best and fastest algorithms.
They have put together a yet-to-be-matched team of engineers, and I enjoy using their search and Google Apps every day. Even our product, Teambox, is tightly integrated with Google Docs and their offerings.
However, Google still struggles to reach consumers in many ways:
Obviously Google has been succeeding at more things that it’s failing at. My point here is not to point out the failures, but investigate what’s causing them.
Some weeks ago I got an email from a recruiter at Google. Quoting:
I’m writing to introduce myself, as I recently received your name from a current Googler who spoke very highly of your skills. I was hoping to get a few moments of your time to speak with you about the opportunities we have available at Google.
I have no intention of leaving Teambox, but having heard much about Google’s hiring process I decided to give it a try and experience it myself.
I explained my experience building Teambox and scaling the product and userbase to its current size. I pointed him to my work on our open-source repositories. I explained how yes, I’m a programmer, but my main expertise is user interaction and product design. I explained how I could contribute to Google’s current and future products with this knowledge.
I’m not posting the full reply, but essentially he..
I do code a lot of Ruby, serious JavaScript and CSS, but I replied marking everything as “I’m a product designer”, hoping they would ask about that.
That was followed by a phone call, where I had a 45 minutes talk about HTML and CSS details, and discussing the fastest algorithm to determine if a given string is a subset of another one. At no point of the conversation were product design skills or experience mentioned.
If you guessed mathematicians and back-end programmers, you’re probably right! And this might be what Google is mostly in need of: smart people to build very fast algorithms for very complicated cases.
But is this what will help Google succeed in the markets they are trying to penetrate? Read the list of failures I listed above. Those failures are not about users complaining about an algorithm being bad, or a system being slow. They are about products being poorly designed or poorly marketed. They are about hurting usability so badly that users move away from them.
You could argue that Google is looking for a large percentage of back-end engineers, while a smaller group works on design and usability. If this was the case, where were these people when the failed product lines were launched? Surely they could use some more.
Design decisions powered by A/B testing are a great way of incrementally improving your product, but trying to use them to drive the overall product direction can lead you to decisions that fly in the face of common sense.
The Goodbye Google post from one of their former designers beautifully illustrates the philosophy behind design. Design can’t be done by committee, it needs to come from the author’s unique point of view and understanding of the problem she’s solving.
Google has its right to continue looking for the people that turned it into the successful company it is today. But as they enter new markets beyond search, different skills are needed.
If Google wants to continue innovating in the consumer space, they will need to start paying more attention to what consumers value. Design and value proposition comes first; speed and scalability are consequences.
I’m @micho on Twitter. I tweet my way through the startup life at Teambox.
Stay in touch
read ourblog contact us follow us
on Twitter