Eliminating waste is one of the core principles behind Lean software development, and certainly no environment is less forgiving of waste than a startup company, where money is tight and disaster lurks around every corner. A startup company focused on productivity issues would thus seem doubly suited as a role model for agile teams striving to eliminate waste within their organizations.
8aweek is a startup company which produces a service that monitors users' online habits and enables them to limit access to distracting websites, providing feedback by way of "productivity report cards". InfoQ recently had the opportunity to ask 8aweek co-founders Dave Fowler and Zachary Garbow some questions about how they connect with users, prioritize work, and get things done.
InfoQ: What is 8aweek, and what can it do for the average developer?
8aweek: A recent study by salary.com found that the average employee wastes over 8 paid hours a week, mostly online. Self-employed people and students waste just as much time, and the problem is worse among younger workers. 8aweek is a browser toolbar that aims to reclaim those hours by helping you control distractions while you're working on your computer. You can specify which sites you waste too much time on and let 8aweek limit the amount of time you're allowed on those sites before it outright blocks you.
InfoQ: How did 8aweek come about? Did you initially build it for yourselves? If not, what was the motivation?
8aweek: We're both highly motivated people and noticed that the Internet was a huge time suck and prevented us from getting things done. For a couple of years I had edited my hosts file to keep out the distractions. It was a cumbersome hack and had no good controls or interface. But when I used it I was at least 2x more productive because I lost that impulse to check Facebook every 5 minutes. I shared the hack with Zack who expanded the idea greatly and we decided to make a tool to give the functionality to everyone in an easy to use and helpful package.
InfoQ: What sorts of development processes (if any) do you use internally to develop 8aweek?
8aweek: Our development process is similar to Feature Driven Development. Based on user feedback we identify which features will make the most people happy and create a schedule and plan for integrating those features.
InfoQ: How do you identify what new features to create? And how do you go about prioritizing things?
8aweek: At first we made a very simple prototype that just blocked access to websites based on a user-defined list. After experimenting with this limited prototype we easily came up with a huge list of features it needed to be more robust. We initially focused on which features would provide the greatest impact for a quick beta launch so that we could iterate from there based on user feedback.
About a day before we launched we added an almost obnoxious feedback and response system. We put the feedback input box right into the toolbar for easy access. Every day people report bugs, send encouraging messages and request new features. We've been launched for just 2 months and have received and responded to 1600 pieces of feedback.
Having such a close connection to our users has been incredibly valuable. It lets us know what parts are on the right track, what features are most important to users, and which bugs are the biggest pains. It's also incredibly motivating and makes the whole project that much more personal. It's what gets us up in the mornings... err afternoons, and keeps us working into the early morning.
InfoQ: How do you decide that something is "done" enough to release into the wild?
8aweek: We focus on rapid iteration based on user feedback. So as soon as a feature is bug free, we release it and let our users tell us if we did it right or need to improve some aspect of it. We could simply guess at what users want, but in the end it's much better to let them tell us themselves!
However there is a danger of taking user feedback too literally. Sometimes users don't know exactly what they want, so it's important for us to look at the root cause of a user's request and infer the intent of that request itself. We can then determine the best approach to solving the problem. Then when we release a feature it becomes pretty clear whether we hit the mark based on how our users respond.
8aweek is a startup company which produces a service that monitors users' online habits and enables them to limit access to distracting websites, providing feedback by way of "productivity report cards". InfoQ recently had the opportunity to ask 8aweek co-founders Dave Fowler and Zachary Garbow some questions about how they connect with users, prioritize work, and get things done.
InfoQ: What is 8aweek, and what can it do for the average developer?
8aweek: A recent study by salary.com found that the average employee wastes over 8 paid hours a week, mostly online. Self-employed people and students waste just as much time, and the problem is worse among younger workers. 8aweek is a browser toolbar that aims to reclaim those hours by helping you control distractions while you're working on your computer. You can specify which sites you waste too much time on and let 8aweek limit the amount of time you're allowed on those sites before it outright blocks you.
InfoQ: How did 8aweek come about? Did you initially build it for yourselves? If not, what was the motivation?
8aweek: We're both highly motivated people and noticed that the Internet was a huge time suck and prevented us from getting things done. For a couple of years I had edited my hosts file to keep out the distractions. It was a cumbersome hack and had no good controls or interface. But when I used it I was at least 2x more productive because I lost that impulse to check Facebook every 5 minutes. I shared the hack with Zack who expanded the idea greatly and we decided to make a tool to give the functionality to everyone in an easy to use and helpful package.
InfoQ: What sorts of development processes (if any) do you use internally to develop 8aweek?
8aweek: Our development process is similar to Feature Driven Development. Based on user feedback we identify which features will make the most people happy and create a schedule and plan for integrating those features.
InfoQ: How do you identify what new features to create? And how do you go about prioritizing things?
8aweek: At first we made a very simple prototype that just blocked access to websites based on a user-defined list. After experimenting with this limited prototype we easily came up with a huge list of features it needed to be more robust. We initially focused on which features would provide the greatest impact for a quick beta launch so that we could iterate from there based on user feedback.
About a day before we launched we added an almost obnoxious feedback and response system. We put the feedback input box right into the toolbar for easy access. Every day people report bugs, send encouraging messages and request new features. We've been launched for just 2 months and have received and responded to 1600 pieces of feedback.
Having such a close connection to our users has been incredibly valuable. It lets us know what parts are on the right track, what features are most important to users, and which bugs are the biggest pains. It's also incredibly motivating and makes the whole project that much more personal. It's what gets us up in the mornings... err afternoons, and keeps us working into the early morning.
InfoQ: How do you decide that something is "done" enough to release into the wild?
8aweek: We focus on rapid iteration based on user feedback. So as soon as a feature is bug free, we release it and let our users tell us if we did it right or need to improve some aspect of it. We could simply guess at what users want, but in the end it's much better to let them tell us themselves!
However there is a danger of taking user feedback too literally. Sometimes users don't know exactly what they want, so it's important for us to look at the root cause of a user's request and infer the intent of that request itself. We can then determine the best approach to solving the problem. Then when we release a feature it becomes pretty clear whether we hit the mark based on how our users respond.
